|lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
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