[Konsole-devel] KDE 4 Konsole DBus works -- security objections, privilege escalation possible

[Arno Töll]

Lars Doelle wrote:
> It allows a privilege escalation. A program running with user rights cannot
> gain root rights using execve(1). 

To be honest, I don't care about the root login on my desktop(!)
machine. I consider my own (user accessible) private data much more
interesting. But that may not be subject of this discussion.

A malicious program run by a user running
> a root session in another konsole session can - via automation. 
[..]
> But it can escalate its rights though /without/ knowing a password when it
> is run while a root session is active in /another/ konsole session via this
> scripting feature. Practically, this means, one cannot run any root session
> securely in a konsole.
> 
> A typical attack path would indeed be some program (e.g. a make-file or install
> script of software one tries), but it can come through any other program in user
> space with a bug, which is then tricked by manipulated data, e.g. okular by a pdf
> or konqueror by some protocol.

This is true, but as every scenario by you a very particular situation.
To successfully gain an other security context an attacker may
succesfully have exploited a local security hole in any given X11
application with user permissions allowing to run arbitrary code. Beyond
that point a konsole session with special privileges may be started
already by the user. Given that, the attacker still needs pretty much
random entropy to include malicous code just for that particular shell
randomly opened by the user.

> This is bad enough since it might fully compromise the user account and
> everything within. If then a path for privilege escalation exists, the whole
> system can be compromised, too.

As I said, I don't see the root account that important on my desktop. I
can, however, live with that argument, when you do, since security is a
serious threat. But again, every "make install" or whatever package
system you do use might need root privileges, so there are lots of
easier tasks to be abused by an attacker

> Arno, i'm not arguing against automation, but only against injection of keystrokes
> from outside. The question is, what practical uses this feature would have and how
> such a use could be achieved securely, and i believe it is possible, when one looks
> closer at the use cases.

You should think about, why there is a DBus interface anyway. Its
purpose is just automation, I used the keystroke injection (based on
DCOP that days) heavily to administrate my remote shells in parallel,
e.g. run a "apt-get upgrade" on every opened tab. I found it pretty
annoying typing that dozens of times by myself.

> 
> Digging a bit deeper on this topic, btw., in fact running su, ssh in any X-terminal
> is a security hole. This comes from the fact, that the designers of X were likely
> unaware about the problem of programs run by a user within different right domains
> as the designers of the konsole automation feature, and provided no means for
> protection.

Partially agreed.

> So one might argue, that this scripting feature punches only another hole, but IMO
> it is better to close them one by one. 

I would argue instead: why are we opening a security hole just by
allowing a terminal to send keystrokes, as you already acknowledged,
that removing that particular method is not more than security by
obscurity, since every given X11 application may send pure X11 events -
e.g. XSendEvent(3). as you said (requiring the same random entropy as I
explained before) .