Message-ID: <45AE054F.6090908@aim.com>
Date: Wed, 17 Jan 2007 06:15:27 -0500
From: Rage Coder <ragecoder@....com>
To: bugtraq@...urityfocus.com
Subject: Windows logoff bug possible security vulnerability and exploit.

Date: January 17, 2007
Tested systems: Windows XP, Windows Server 2003
Topic: User profile unload failure at logoff may expose system to 
security vulnerability.

I believe that it is the purpose of the OS to provide the appropriate 
security and the purpose of a program to do it's task and not implement 
the security of the OS.  A program does not manually check what 
permissions it has on a file, it just tried to open the file and the OS 
checks the permissions, allowing or denying the program to open it.  
Similarly, a program does not check to make sure it is displayed only on 
the desktop that is is run on, or that a system tray icon is only 
created on the system tray of the desktop the program was launched from, 
it just creates the window or tray icon and shows it.  The OS should 
make certain that the window is displayed on the correct desktop.  A 
program running in a Remote Desktop session appears only on that desktop 
and not on the main desktop, and vice versa.  Some programs are designed 
so that only a single instance should run, and running another instance 
simply pulls up the current instance.  Others are designed to use a 
system tray icon, and if the shell crashes, add the icon back so that it 
can still be accessed.  However, such programs can run under a Remote 
Desktop session and under the 'real' desktop without interfere with each 
other or without one user being able to access the application running 
by the other.

When a user logs into a computer does his or her work and then logs 
out.  He or she expects that any running programs to close and that the 
next logged on user can not take over his or her files and more.  At the 
same time, a simple program should not be responsible for checking it's 
own permissions, making sure it is on the right desktop and accessible 
only by the right user.  The OS should do this, while the program should 
focus on it's job.

The security problem I'm discussing occurs when a user profile fails to 
unload during logoff.  The event viewer show a profile unload error as a 
UserEnv application event, ID 1517 and 1524 on Server 2003.  At times, 
if the system is under heavy use and the registry is still being 
accessed, the user profile (registry, etc) will not unload and the 
programs launched by that user will continue to run. This is evident 
from task manager, which reveals that the old 'explorer.exe' and other 
processes of a previous login are still running. I have also tested this 
with the UPHClean utility and the same results have appeared, even 
though the registry gets remapped.  If another user logs on while these 
programs are running, the user may be able to access the programs, and 
with it the permissions of the user that ran the programs.  Some 
programs are more easy to access than others if they continue to run, 
such as those programs that only allow one instance or programs that 
reinsert themselves into the system tray.  I still do not think it is 
the responsibility of the program to make sure it is on the right 
desktop, but the OS should make sure the program does not 'bounce' from 
on user's login session to another.

I have tested this with several programs, to make sure it is not just a 
'bug' in the program, including EssentialPIM, GetRight, KeePass, and a 
few others.  For each program, if the program was running while I logged 
off, and during the logoff the profile could not unload, the program 
continued to run.  When logging on as another user, the program appeared 
in the system tray.  Some programs did not appear in the tray right 
away, but when the program was launched, instead of creating a new 
instance, the older instance launched by the other user was shown.  
Using this, I can browse the files of the user and do more.  If the 
user.was an administrative user, I can do even more, intentionally or not.

I do not believe this problem presents a network security leak, but 
locally it can be exploited under the right conditions.  One workaround 
is to manually shut down any desired processes before logging off.

One solution would be for Windows to forcefully terminate the programs 
that it would normally terminate under a logon session even if a profile 
unload fails, and not to allow another 'local' logon except by 
administrators until the processes are closed.  This way, another user 
can not access the process of a previous user, because it is not 
running.  Another solution would be to encapsulate each local logon the 
same way that a local logon and remote desktop logon are encapsulated 
from each other.  This way, each process session ID would match the 
session ID of the desktop it is shown on.  A different logon, or fast 
user switch, would be a different session ID, so a process from a 
previous logon would not be shown on the next logon, even if a profile 
fails to unload.

P.S.

Sometimes the profile does successfully unload even when the problem 
occurs.  It seems to do that when I wait a while before logging in 
again. But if another user (my brother), logs in just a few minutes 
after I log out, he can access the programs that were running when I 
logged off.

Powered by blists - more mailing lists