Re Kubuntu 64bit, several issues

Tristan Wibberley maihem at maihem.org
Mon Aug 15 14:31:21 CDT 2005


Daniel Stone wrote:
> On Sun, Aug 14, 2005 at 08:54:52PM +0100, Tristan Wibberley wrote:
> 
>>That's what I was asking for in my original post, protection against
>>that. The X server is started from a known place and I'd like to be able
>>to force gnome-session or KDE from a known place, which will only start
>>gnome-panel from a known place, which will only start gksu from a known
>>place.
> 
> 
> 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.

> 	* 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.

> 	* 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.

> 
>>And similarly for login starting bash and bash starting sudo. If
>>that path can be secured, then the whole path to escalation of
>>priviledges for administrative tasks can be secured (or at least a
>>couple of secure routes provided).
> 
> 
> 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.

>>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.

> 
>>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).

> 
>>>It is a tradeoff; if you prefer to administer your system this way, simply
>>>set a root password and remove yourself from the admins group.
>>
>>I'd prefer to do it with sudo, but it currently isn't safe to browse the
>>internet from the same user account since there is no way to know that
>>you are giving your password to sudo or an attacker. I was posting to
>>see if there is a way to secure it (which I think there is - that is to
>>provide a way to know that you are not running a trojan).
> 
> 
> 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".

> 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...

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.

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.

> 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.

> 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.

-- 
Tristan Wibberley

Opinions expressed are my own and do not necessarily coincide with those
of my employer, etc.




More information about the ubuntu-devel mailing list