[7495] in bugtraq
Re: [ NT SECURITY ALERT ] New Local GetAdmin Exploit
daemon@ATHENA.MIT.EDU (Vadim Fedukovich)
Thu Jul 30 15:49:33 1998
Date: Thu, 30 Jul 1998 08:37:43 +0000
Reply-To: Vadim Fedukovich <vf@USB.GF.UNITY.NET>
From: Vadim Fedukovich <vf@USB.GF.UNITY.NET>
X-To: marxmarv@ANTIGATES.COM
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199807290623.XAA27838@antigates.com> from "Jonathan H. Pickard"
at Jul 28, 98 11:23:17 pm
>
> On Mon, 27 Jul 1998, MJE wrote:
> >THE EXPLOIT, IN A NUTSHELL: by using existing Windows NT services, an
> >application can locate a certain API call in memory, modify the instructions
> >in a running instance, and gain debug-level access to the system, where it
> >then grants the currently logged-in user complete membership to the
> >Administrators group in the local user database.
...
> >modify the instructions in a running instance
>
> First problem: why are we allowed to modify a shared resource
> (even a local copy of it) even as mortals? WARNING: Don't put
> business logic in DLL's (and definitely do NOT export your
> "BOOL bIsALegalTransaction(...)" type functions).
Here's another one interesting target: private keys. Lots of people
asks howto compile SSLeay on NT to get DLLs. Personally I'm a fan of
SSLeay running on unixes but here will be plenty of exploits to leak
private keys if OS allows modifications like that.
> * Locates the memory address of a particular API function
> used by the DebugActiveProcess function.
>
> So WindowsNT leaves a piece of memory wide open to reading and
> writing that doesn't even contain _my_ data and then, in a context
> of privilege, starts relying on code in that data range to execute
> as designed?! Oversight or _deep_ design flaw?
I wonder, does NT allow to debug it's own crypto engine?
> --
> "Windows NT 4.0 is 16.5 million lines of code that will never be debugged."
> -Bill Joy
Vadim Fedukovich
