Everhart,Glenn
From:	David LeBlanc [dleblanc@MINDSPRING.COM]
Sent:	Thursday, April 30, 1998 10:03 AM
To:	NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject:	Re: name of built-in administrator
At 12:40 PM 4/30/98 +0000, Luke Kenneth Casson Leighton wrote:
>On Tue, 28 Apr 1998, David LeBlanc wrote:

>> At this time, there is no fix for this, except to filter connections to
>> port 139.  I've tried a couple of things I thought would fix it, but found
>> that it caused severe problems. So, at the moment, if you can get a null
>> session, you can dump all the users, groups, and machine accounts.  You can
>> also cause some other problems, but they are a little arcane, and MS has
>> been advised (I only found it this morning, trying to make a fix for this).
>>  There isn't anything you can do to stop the other problems, except filter
>> 139, so...

>> IMHO, we should be able to control whether or not NT accepts null sessions.

>the reason that null sessions [to IPC$] are allowed is so that
>non-critical information can be made available (such as browsing
>information).

I understand this.  I think we should be able to decide whether we're going
to provide anything at all to a null session.  Ideally, we should also be
able to turn on and off anything which is provided to a null session.

>there are info levels to all IPC$ (and dce/rpc \PIPE\some_service calls).
>certain levels require no user/pass/domain identification (usually info
>levels 0 and 1 or 100 and 101) which implies that an anonymous (null
>session) connection is accepted; some levels require user/pass/domain
>identification (levels around 1-2, or 101 to 102); some require
>administrator rights (usually levels 3, 103 and above and 1001 and above).

These correspond to the level argument of all the NetXXX() calls.

>unfortunately, something went wrong somewhere with the permissions for the
>above accounts.  i therefore suspect this to be another manifestation of
>the "red button" bug, which means that it would be useful for someone to
>confirm this by setting the "RestrictAnonymous" registry entry.

No, this is documented behavior.  The LookupAccountXXX() calls are
documented to work across a null session.  It must pose some relatively
sticky problem to disallow this.

>> It is possible they are doing something about this in SP4 - they didn't
>> tell me whether, how or when they planned to fix it.

>obviously, setting "RestrictAnonymous" doesn't help you against malicious
>users with an account: that would require something like "RestrictUser",
>but at what point do you draw the line?  do you cover the
>SamrQueryDisplayInfo call (which is another security hole as far as
>malicious users are concerned), too?

No - all of this can come across a null session, not an authenticated user
session.  The NetQueryDisplayInfo() call won't return users if
RestrictAnonymous has been set - I haven't tried the other two ways to call
it.

>i think microsoft have their work cut out on this one...

Agreed.


David LeBlanc
dleblanc@mindspring.com