Home page logo

bugtraq logo Bugtraq mailing list archives

Re: ... Tiny Personal Firewall ...
From: Dave Ahmad <da () securityfocus com>
Date: Mon, 4 Mar 2002 11:08:59 -0700 (MST)


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

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.



  By Date           By Thread  

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