OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 3rd quarter (Jul-Sep) 1998: Re: [ NT SECURITY ALERT ] New Local GetAdmin Exploit

Re: [ NT SECURITY ALERT ] New Local GetAdmin Exploit

Vadim Fedukovich (vfUSB.GF.UNITY.NET)
Thu, 30 Jul 1998 08:37:43 +0000 

>
> 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