User Logout Bug <long> (fwd)

[Luke Kenneth Casson Leighton]

AAAAAAAAAAGH!  and we thought it was a problem with samba AAAAAGH!

<a href="mailto:lkcl at samba.anu.edu.au" > Luke Kenneth Casson Leighton  </a>
<a href="http://mailhost.cb1.com/~lkcl"> Samba and Network Development </a>
<a href="http://www.samba.co.uk"       > Samba and Network Consultancy </a>

---------- Forwarded message ----------
Date: Wed, 25 Nov 1998 09:40:55 -0600
From: Craig Huckabee <huck at cs.wisc.edu>
To: NTBUGTRAQ at LISTSERV.NTBUGTRAQ.COM
Subject: User Logout Bug <long>

   Hi,

     This may or may not be a serious bug - it affects us and it may be
     affecting some of you and you just don't know it.

     It seems there is a bug in either userenv.dll or lsasrv.dll where a
     user's NT token is not closed when they logout.   The tech I spoke
     with at Microsoft never let me know which module was responsible
     for closing the token, but I'm guessing it is one of those two,
     with my money on userenv.dll.

     The result , the one we noticed anyway, is that sometimes calls to
     NetWkstaUserEnum, and possibly any other calls in that family,
     will result in bogus information.  That call is supposed to return
     the name of the currently logged in user.  What you get is a list
     of every non-admin user who has logged in since the last reboot.

     For example, User A logs in and logs out.  User B logs in and runs
     a tool that uses NetWkstaUserEnum to determine who is logged in.
     The list returned will contain User A and User B.  The only exception
     we have seen is the local administrator account - his token gets
     closed properly and he only shows up while he's actually logged in.
     This may be primarily because he doesn't have a roaming profile
     in our current setup - the upload of the profile seems to be the
     point where the bug occurs but I'm not positive.

     Microsoft has confirmed that this is a bug and that it will be fixed
     "sometime".  I wanted to post this in case anyone else has been
     puzzled by odd behavior that could be related to old NT user tokens
     laying around in the kernel.

     Here's why I speculate that the tokens could still be valid and that
     this could be a security problem :

     In another project here at the UW, we were looking for a way to 'su'
     from one account to another *after* the original user had logged out
     (so we could start processes as a given user while no one is logged
     on interactively to the machine - to use spare CPU cycles).  The
     way to do this, as described by Microsoft, was to store the handle
     to the user token you have (either from a LogonUser() or DuplicateToken()
     call) in some structure in memory.  As long as you didn't close the
     handle *or* reboot the machine (as the token itself was stored in
     a kernel structure) you could use that token for impersonation.

     So, I'm thinking that this bug is essentially userenv.dll not closing
     the handle to the valid token stored in the kernel.

     Can you actually get to those tokens ?  I dunno.  I would imagine that
     if a simple non-privilaged call like the one we were using could see
     the tokens that there might also be ways to establish a handle to
     them.

     As I mentioned before, this may only be affecting a small group of
     people out there.  We have a real custom environment here : a
     custom GINA, AFS for file service, etc., and that's why we stumbled
     across the problem.  We had to install a bare bones, stock NT machine
     and see if we could reproduce the problem there, which we could, and
     then document how to reproduce it for the MS Tech so he could try it.

     Below is the list of steps we used.  The Netwksta util just calls
     NetWkstaUserEnum and prints out the user(s) that are currently logged
     in - I can post a copy of that as well if anybody else wants to try
     reproducing it.

 ----------------------------------------------------------------------
     You'll need 1 computer, not in a domain, runnning SP3 + hotfixes.

     1)  Create a user.  Make sure that user is in only the "Users" group.
        The profile path should be set to an invalid profile path, like
        Z:\foo.

     2)  Login as this user.  Ignore the error message.  Logout.

     3)  Change the user profile path to be blank (the default) or to a
     valid location.

     4)  Login as the user again.  Run the netwksta utility.
     You'll see that it says there are 2 users logged in.
 ------------------------------------------------------------------------

     --Craig


 Craig Huckabee                                 E-Mail : huck at cs.wisc.edu
 Computer Systems Lab, Computer Sciences Department
 University of Wisconsin-Madison
 http://www.cs.wisc.edu/~huck/