Re Kubuntu 64bit, several issues

Daniel Stone daniel at fooishbar.org
Mon Aug 15 15:24:49 CDT 2005


On Mon, Aug 15, 2005 at 08:31:21PM +0100, Tristan Wibberley wrote:
> Daniel Stone wrote:
> > So, if I was a Trojan, I'd still steal all your keystrokes from the X
> > session, then, once I had your root password (fairly trivial to work out
> > which keystrokes came from which window, so I could certainly piece
> > together your password for sudo from the long steady stream of typing),
> > I could just do this:
> > 	* run a program which displayed over the screen, an image of the
> > 	  windows I wanted you to see, and passed through your keystrokes
> > 	  and clicks.
> 
> I am proposing that the X server should be configurable to refuse to
> give total control over the entire screen so it will always show a
> "non-secure" icon whenever it is willing to pass keystrokes on to
> something which it doesn't know is a configured, trusted process.
> screensavers should still work as to take true control over the whole
> screen, the X server could refuse to forward any keystrokes. Yes, tough
> luck gamers - maybe control over the scroll lock can be taken away from
> applications so a flashy scroll lock could show that the computer is in
> a secure entry mode. Or a sysrq combination could force the X server to
> secure mode so games can still have the full screen until access is
> revoked. There are lots of ways this can be done with various pro's and
> con's.

And there are still downsides to this.  The problem is -- how does X
know that a client is 'secure' or genuine?  I might not be snooping your
keystrokes by either listening on the wire or just grabbing the keyboard
(although gksudo is smart enough to dodge keyboard grabs, but EvIE?
Nah.), but instead, I might just start up a program which looks like
gksudo, identifies itself as gksudo ... but isn't gksudo.

How exactly do you propose to authenticate these secure programs to
the X server?

> > 	* in the background, in a hidden window, click through to start
> > 	  gksudo, in a hidden window, and fake the keystrokes to your
> > 	  passphrase, at which point I now have root.
> 
> Again, If a hidden window has the focus, the X server could continue to
> show the *insecure entry* icon. There probably need to be other
> restrictions before the insecure icon is hidden.

Take a ARGB (A8R8G8B8) visual, and map a full-screen window with full
transparency the entire way.

Steal events by registering yourself as an EvIE manager.

> > 	* obtain a backchannel to my root shell, close down the nice
> > 	  little façade, and hope you didn't notice.
> 
> I don't understand what "backchannel" means.

Do something like fork the root shell into the background, and have
it listen on a network socket or something, so I can telnet in.  Or
whatever.

> > Actually, it can't.  If someone has access to your account, then they
> > can just do something hillarious like wrap ls through LD_PRELOAD or
> > something, and invoke a separate shell which does some very, very nasty
> > things.
> 
> I'm not talking about protecting my files or preventing files from being
> hidden in directories to which I have write permission. I acknowledge
> that a normal bash session cannot be protected and that the assurance of
> secure password entry must be made by first recognising when a
> privileged process is running.

If bash cannot be protected, how can gnome-panel?

> >>At the moment there is no way to do
> >>that (eg, PATH can be altered by the user, aliases can be set). But if
> >>the system bash (and other routes to running sudo) can be assured -
> >>which I think they can - then sudo becomes safe even in the face of a
> >>user account compromise.
> > 
> > So you're suggesting that alias and PATH support be disabled?
> 
> No, I was suggesting that bash ignore alias and path when you issue
> "sudo foo" or "su foo", but it has been shown that it cannot work
> because the running bash process can be patched to misbehave. See above
> re use of privileged process recognition instead.

And, again -- how do you propose to recognise privileged processes as
such?

> >>What would be nicer still is if terminal emulators and the X server
> >>could provide a different display when a known binary is asking for
> >>privileged information in a secure manner (a display that they cannot be
> >>asked to produce in any other way). So you can see at a glance if you
> >>are in a secure environment when you're prompted for your password.
> > 
> > So gnome-terminal and the X server[0] suddenly gain knowledge of all the
> > applications that are in this web of trust, and find some way to
> > authenticate them?
> 
> Yes, although gnome terminal shouldn't do it, but perhaps the pseudo
> terminal should be told by sudo through a mechanism only available to
> processes running as root that this requires secure entry. Then some way
> for the display of glyphs to be done by the X server (or a root owned
> process that the X server recognises).

See below -- this is easy to fake out.

> > Similarly, there is no way to know that 'su' is not trojaned.  There is
> > no way to know that there's not a hardware keylogger embedded in your
> > keyboard, because I assume that you have not considered physical
> > security.
> 
> I think this is a bit fatalist. At the risk of being rude, but with the
> intention of being clear, I'd like to paraphrase: "It is impossible to
> be one hundred percent secure, so don't even bother trying to stop the
> easy cases of zlib exploit leading to high probability of keylogging
> capability".

The lesson I would take home from that quote would be more towards
auditing zlib if everything depended on it, rather than attempting to
fundamentally redesign the way computers work, which is something not
even the SELinux people, backed by the NSA, have managed to properly and
securely achieve after years of work so far.  Oh well.

> > Put it this way: if you were running a business, and I wanted all the
> > lowdown on you because I was an unethical competitor, it would be much
> > easier to break into your house and either steal your computer (if I was
> > overt), or do something like embed a hardware keylogger in your keyboard
> > (if I was sneaky), than to somehow compromise your machine over the
> > network, and then write something that stole your X display and logged
> > the keys there.
> 
> At which point you have to do something both difficult to do, and
> difficult to not get caught doing. Using the desirable sudo mode of
> administration makes the system script-kiddie-fodder...

It's not that easy to do.  Windows are easily prised open, and if I do
it while everyone's at work, then no-one's likely to notice.

Point is, your physical security is likely to be easier to compromise
than your computer security.

> Script kiddie puts standard exploit script on web page, Dad visits
> website with unpatched firefox, son phones dad to tell him a new firefox
> is available and to patch his firefox, dad goes to synaptic to upgrade
> it, enters his password and *bang*. This could also happen with
> thunderbird, and as Linux and thunderbird become more popular, that sort
> of active attack will happen with more frequency just as it does on Windows.

At that point, you have lost, sure.

But I do not see how this thread has proposed an alternative to this.
How do you propose to securely authenticate these processes?

Look for a file you know only root can create?
Bad news, I've just wrapped open() and stat(), et al.

Store a set of MD5 and SHA1 sums in every binary that might conceivably
need to do this authentication?
Bad news, not only have I wrapped your MD5 and SHA1 generation (or
possibly just made the binary bypass it and claim success), but security
updates are now huge and infeasible.

Check that the process is running as root?
Bad news, I just faked that out too.

> Alternative...
> 
> Crowbar kiddie somehow identifies a building with computers that might
> be used for browsing by one person and banking by another, then script
> kiddie breaks in without being spotted, installs hardware keylogger and
> gets out without being spotted.
> 
> The first is relatively easy to do and relatively easy to do
> untraceably, and could catch hundreds of people before being taken down.
> The second is hard, very risky, and might get *one* computer per night.

I'm talking about a different use case.  If I was specifically targeting
you because you ran Tristan's Curtains and Blinds, and I ran Daniel's
Curtains and Blinds and wanted to get an edge, I'd break in.

If I wanted thousands of machines on cable modems to DoS some poor fool
off IRC to prove a point, I'd just trojan Firefox, yes.

> > Oh, yeah, and did I mention that you could wrap your gnome-terminal in
> > a fake libX11, libgtk, whatever, which intercepted all events before
> > it sent them over the wire fairly trivially?
> 
> See above for an alternative to trusting every gui terminal emulator.

No, that doesn't hold water.

Let's say sudo has some method (writing to a file in /etc/securitywow)
that is only available to root processes, of informing gnome-terminal
that it's doing secure things and could gnome-terminal please do secure
things now too.

Let's say I write a very small wrapper around gnome-terminal, or just
modify it in-memory when it's running, that disables this bit of code,
which I'm perfectly within my rights to do as the user that's
attempting to run this bit of code.

...

> > While I understand your concerns, I'd like to reiterate the point I've
> > made earlier -- if they have access to your account, you've already
> > lost.  You're running a fake Firefox, which reports back all information
> > entered into forms at https://olb.westpac.com.au or whatever, you're
> > running a gnome-terminal that sends me back all the keystrokes after
> > you've typed in 'sudo', you're running a gksudo that ... hey, wait, that
> > isn't quite gksudo -- you get the idea.
> 
> Yes, but I'm proposing that the *real* programs for escalating your
> privileges actively do something to ensure that the route of data from
> PS2 port to themselves is secure, with the cooperation (as necessary) of
> input driver, X server, etc. Then do something with the cooperation of
> terminal emulator (with possible privileged component) and X server to
> show you that it is secure that can't and/or won't be done if a
> non-privileged process is involved.

It's the 'something', which is being completely handwaved over, that is
the most important -- and virtually impossible to implement -- component
of this.

The paragraph here is very good: I can't disagree with it in any way,
shape or form.  What I'm suggesting is that the complete lack of any
concrete ideas from anyone about what 'something' might possibly be, is
because it's a stupendously difficult problem to solve, and that no-one
has managed to solve it yet is a reflection of the depth of the problem
space, rather than it being unpopular.



More information about the ubuntu-devel mailing list