When the computer is idle for the set time period (user definable) Winlogon.exe starts the screensaver. The screen saver process is selectable by the user. Winlogon.exe uses the CreateProcessAPI call to start the screen saver and immediately suspends it. At this point the screen saver is running with the security context of Winlogon.exe (system). Winlogon obtains the process handle, changes the primary security token of the screen saver to match the current user, and resumes the screen saver. Winlogon never verifies that the token change was successful. Therefore, a user could create an executable, set it as the screen saver, and should the security change fail it will run with full system-level privileges.
This exploit and description provided by Cybermedia Software Private Limited.
The simulation consists of one 32-bit application say BEADMIN.EXE and one MS-DOS based application, say SCRNSAVE.EXE. The BEADMIN.EXE when started does the following Creates one event in â??not-signalâ??ed state Sets up the screen saver. The screen saver executable is specified as SCRNSAVE.EXE and the timeout is set to minimum. . BEADMIN.EXE now waits on the event. After some time, the screen saver is triggered. This results in Winlogon.Exe spawning SCRNSAVE.EXE. Since the CreateProcess call returns junk handle to Winlogon.Exe, the setting of primary token fails. Hence the SCRNSAVE.EXE application (NTVDM.EXE) runs in System Context. This SCRNSAVE.EXE again spawns BEADMIN.EXE application. Now this second copy of BEADMIN.EXE inherits the security context of NTVDM which is System Context. This application adds the logged in user to admin group and signals the event on which first instance of BEADMIN.EXE is waiting. In response to this the first copy of BEADMIN.EXE resets back the Screen Saver settings and quits. The logged in user name is passed between the first and second copy of BEADMIN.EXE using shared section.