Message-ID: <45AF6109.3030607@aim.com>
Date: Thu, 18 Jan 2007 06:59:05 -0500
From: Rage Coder <ragecoder@....com>
To: 3APA3A <3APA3A@...URITY.NNOV.RU>
Cc: bugtraq@...urityfocus.com
Subject: Re: Windows logoff bug possible security vulnerability and exploit.

The problem only occurs at times.  To reproduce the problem, I just use 
the computer normally, and at each logon check the event viewer and 
running processes to see if a profile unload failed.  I don't have any 
special terminal software or other logon software installed.

I find that if I wait for a little bit after logging off before logging 
on again, no running programs from the previous logon are present, but 
if I log on just after logging off, they will be if the profile unload 
fails.  That still shouldn't be the case.  My brother frequently goes on 
his account right after I go off; there shouldn't be a time limit to 
wait in order to prevent this.

I noticed an interesting thing about XP and fast user switching which 
would likely stop this problem.  When logging on, the first logged on 
user is given session ID 0, as shown in task manager, but if I 'switch' 
to another user, the user is given a different session ID.  It seems 
that no two users are given the same session ID when using fast user 
switching. But when logging off all users and then back on, it is back 
to session 0.  And if I just log on as a user, log off, and then on as 
another user without using the 'switch user', they both are session ID 0.

The same thing happens when using classic logon and on 2003.  All logons 
are given session ID 0.  I did some reading in the platform SDK and some 
sites about stuff, and it seems that these sessions literally create an 
isolation.  Messages sent from a process in one session ID are not 
visible to processes in another, windows created only appear on the 
desktop associated with that session of the process that created the 
window, etc.

Ideally, running classic logon always as session 0 'should' work because 
ideally when logging of, the processes ran 'should' close, so the next 
user to log on would have nothing to access.  But this does not appear 
to be the case at all times.

A few moments ago I logged in as administrator to do some minor changes, 
and I ran EPIM to take some notes of things.  When I logged of and back 
on as a regular using, 'explorer.exe', 'essentialpim.exe', 
'seamonkey.exe' were still running as Administrator, event viewer showed 
the usual UserEnv messages, and EPIM appeared on the system tray.  My 
guess is something like this happens:

Logon Administrator : Session ID 0
Run EssentialPIM : Session ID 0
Do some stuff
Logoff Administrator : Profile unload fails, a few programs continue running
Logon Normal User : Session ID 0
Explorer runs, and at startup broadcasts 'TaskbarCreated' message
All processes in session 0 get this message, EPIM adds system tray icon 
like it is supposed to

If each logon, even in classic mode, is given a separate session ID as 
is done in fast user switching, this would not happen, even if the 
profile unload fails and the programs continue to run waiting for the 
profile to unload:

Logon Administrator : Session ID 0
Run EssentialPIM : Session ID 0
Do some stuff
Logoff Administrator : Profile unload fails, a few programs continue running
Logon Normal User : Session ID 1
Explorer runs, and at startup broadcasts 'TaskbarCreated' message
All processes in session 1 get this message
Programs that may continue to run in session 0 are isolated

If I log on as administrator again, it would be ok to reuse session 0, 
but for a given boot, no two users should be assigned the same logon 
session ID.  I.E.  if I log on as Normal User again, it would be session 
1,  etc.

This would not prevent a profile from failing to unload, and would not 
prevent the processes from continuing to run, but it will prevent a user 
from a later logon from accessing the processes in the current logon.

3APA3A@...URITY.NNOV.RU wrote:
> Dear Rage Coder,
>
>  I've seen unloaded profiles for many times, but I never saw application
>  still  running  after  logoff.  Profile  itself doesn't create security
>  vulnerability, since it can not be accessed by another user.
>
>  What do you use to reproduce this vulnerability?
>
>  Are  you  sure  you  do  not  use some different software which affects
>  logon/logoff process, e.g. 3rd party terminal software or some security
>  enhancement?
>
>   

Powered by blists - more mailing lists