Re: Microsoft NT "un-removable user" Vulnerability.

[David LeBlanc <dleblanc () MINDSPRING COM>]

At 06:29 PM 9/6/00 -0700, uh Clem wrote:

> In the NT Native API, all strings are created and dealt with in unicode,
> which is not NULL terminated. In the Win32 API, all strings are dealt with
> in ANSI, which is NULL terminated.

This is incorrect. Almost all user-mode API calls come in 2 flavors - ASCII
and wide character. The ASCII calls are typically wrappers over the wide
char calls, and due to the translation and allocation are somewhat less
efficient, depending upon the call.  This is one reason why I nearly always
work in UNICODE.

You do have this almost right, in that the kernel-mode calls (and some
lower-level user-mode calls, such as Lsa*()) use a structure known as a
UNICODE_STRING that consists of 2 unsigned shorts to tell us how many
characters are used in the buffer, the maximum number of characters, and
the pointer to the buffer. These are not normally null-terminated.

> This opens up the possibility to create a named object (regkey, file,
> named pipe, probably users/groups) using the NT API that the Win32 API
> will misinterpret the name of.

Actually, what it means is that you can only create and destroy these using
the lower-level calls.  There's no misinterpreting to it - if the object's
name is foo\0bar, and you're trying to deal with it using an API call that
only allows for null-terminated strings, you obviously can't access that
object.

> This is a technique one might use to make software practically
> unremoveable (like Netscape and AOL try to do), or to hide/disguise
> files infected with trojans/virii from virus scanners.

I think that if you look in the NTBUGTRAQ archives, Greg Hoglund discussed
this very technique a couple of years ago.

> It's about time Microsoft documented and supported this basic stuff so
> that makers of security/virus scanners, etc can make use of an API that
> malicious people are probably already using.

I believe that most of what you need is documented in the NT DDK. If not,
there is an interesting book that does document these - I don't recall the
title, but Todd Sabin references it at www.razor.bindview.com. The problem
with using undocumented calls, whether for good or bad, is that they could
be changed at any time and any application using them could break across
versions or service packs.


David LeBlanc
dleblanc () mindspring com