Technically, when an NT workstation is locked, the screen displayed is on
a different GINA controlled desktop than the users desktop.
The same when screensavers, etc, are running. This security model is
explicitly supposed to stop a users processes affecting the locked
desktop.
Winlogin and GINA interact via several command sequences (WlxIsLockOk,
WlxDisplayLockedNotice, and WlxDisplaySASNotice in particular) over three
desktops:
- Application desktop (user can write)
- Winlogin desktop (login UI/locked workstation) - only the winlogin
system process should be able to write to this.
- Screensaver desktop (insecure, but designed to 'flip' to the winlogin
desktop upon an unauthorised termination of the screensaver process)
Theoretically, a system-level process could override the Winlogin desktop,
as could something running in the kernel. A new GINA dll could also export
trojaned functions.
In any circumstance, a program that hooks in and deliberatly writes a
dialog to the Winlogin desktop is a mess waiting to happen - by operating
over multiple desktops it creates a set of conditions that would be fairly
easy to exploit to unlock the station.
This is taken to another extreme with XP, where (besides the three core
desktops instanced by the Window Station) even more desktops are created
to cope with multiple users.
Regards, | It's always bad news in computing.. and beware
| of anything claming to be good news - because
| its probably a virus. - Salmon Days
Ender |
(James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org]
On Mon, 4 Mar 2002, Dave Ahmad wrote:
> Date: Mon, 4 Mar 2002 11:08:59 -0700 (MST)
> From: Dave Ahmad <daat_private>
> To: Scott Nursten <scottnat_private>
> Cc: bugtraqat_private
> Subject: Re: ... Tiny Personal Firewall ...
>
> Scott,
>
> It must be the responsibility of the OS to prevent console users
> interacting with applications when the desktop is locked. No user process
> should ever be able to bypass the lock mechanism.
>
> The reason why it is unclear if this is a Windows problem or not is
> because Tiny Personal Firewall most likely operates at the kernel level.
> To do what it does it has to.
>
> It may be that Tiny Personal Firewall creates the dialog from within
> the kernel (not sure if that is even possible) when prompting the console
> user, despite the console being locked. If this is what is going on, then
> it's really not an OS problem. Windows is doing it's job by preventing
> console access to user applications and the desktop.
>
> Kernel-level code can do anything on the system, it's the responsibility
> of the product developers to design their software carefully.
>
> If there are low-level dialog functions in the kernel, it might be a good idea to
> add some checks to determine if the console is locked (of course malicious
> kernel-level code could write directly to video memory, so this is a
> safety net for code that follows the rules).
>
> Anyone familiar with the Win kernel care to comment ?
>
> Dave Ahmad
> SecurityFocus
> www.securityfocus.com
>
> On Fri, 1 Mar 2002, Scott Nursten wrote:
>
> > Not being au fiat with Windows programming etc., I was wondering if this was
> > standard practice? Surely if the workstation is locked it's supposed to stop
> > all I/O?
> >
> > Isn't this also an OS related bug? No flames please, it's just a question.
> > :)
> >
> > Regards,
> >
> > Scott
> > --
>
This archive was generated by hypermail 2b30 : Wed Mar 06 2002 - 20:14:01 PST