Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: ... Tiny Personal Firewall ...
From: "J.Brown (Ender/Amigo)" <ender () enderboi com>
Date: Tue, 5 Mar 2002 15:33:21 +0800 (WST)

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 <da () securityfocus com>
To: Scott Nursten <scottn () s2s ltd uk>
Cc: bugtraq () securityfocus com
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
--



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]