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.