[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Open Xlock as root



[Sorry for the weird From: line, smartlist made me do it...]

Hi all,

first let me remark on the xlock/root password thing. There are
really two issues here:

 1.	The requirement to give an application or helper program
	special privilege in order to test a password.

	I find it an utterly abominable idea to make an application setuid
	or setgid anything if it's linked against Xlib (or, heaven forbid,
	high-level gooey libraries such as Motif, KDE, GDK, etc in it). So
	obviously helper apps are the way to go.

 2.	Decoys that look like the real thing and make people enter
	their passwords where they shouldn't.

On Sun, Dec 05, 1999 at 10:28:12AM +0100, Ivan Popov wrote:
> There is something fundamentally broken in supplying a password to a
> program. Even an alphanumeric console login prompt may be easily spoofed
> by a malicious user.

Right. This is why we have the Secure Attention Key at the console.

The same thing in an X Windows context is called Ctrl-Alt-Backspace,
which solves the xlock problem quite nicely (you can also try SAK on
an X session, but this made my Linux box freeze on the next attempt to
switch to another VC).

However, C-A-B doesn't work as nicely at the xdm login (this is just a
variation on the decoy login prompt issue Ivan alludes to).

Attack scenario: write your own xdm and make it run "Xwrapper :1"
(you'll probably need to start it from a console login, not sure).
This will start an _additional_ X server. You can now make your
rogue xdm display a login window etc. Then the security-conscious admin
walks up to it and presses C-A-D. The X server you started dies, and
you promptly start another one. Security-conscious admin thinks all's
fine and enters password.

Can this be solved? Possibly, e.g. by not making Xwrapper setuid root.

The problem with things like a decoy login is that for in order to be
sure you're talking to the real login/xdm/etc is that the application
must demonstrate to you that it runs with system privilege by doing
something that requires system privilege. Usually, the ability to
open the video or mouse device is such a requirement. But there are
several ways, at least on Linux, to make something appear to be a
normal xdm prompt:

 1.	start a failsafe session (usually has a single xterm only).
	Create a single window the size of the screen, without borders,
	and run Xnest in it.

 2.	write your own xdm and make it run "Xwrapper :1"
	(you'll probably need to start it from a console login, not sure).
	This will start an _additional_ X server. You can now make your
	rogue xdm display a login window etc.

In both scenarios, an unwary user will type in his/her credentails.
In the second example, a security-conscious admin may even press
C-A-Backspace.  The X server you started dies, and your fake xdm promptly
starts another one. Security-conscious admin thinks all's fine and
enters password.

> Ideally privileged users should not login on utrusted computers, except
> by means of one-time passwords or, say, public keys.

Even that won't help against a password snatcher. Once he's got your
credentials he can use them, regardless of what mechanism you use.

Olaf
-- 
Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de    +-------------------- Why Not?! -----------------------
         UNIX, n.: Spanish manufacturer of fire extinguishers.            



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []