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

[Lars Doelle]

Arno,

> This is however a feature, that already existed since KDE 3 days with DCOP.

The feature was added earlier and later removed for security reasons.
I did not note it was added again and suggest to remove it.

 
> I wouldn't consider this as a (real) security issue though, since it
> requires an local user wich deliberately executes a malicious
> script/programm to do something harmful. This is the same issue for
> _every_ executable being run by the user. I don't see why it should be
> more dangerous to allow an user to send commands through a method to a
> shell, against executing execve(1) syscalls or anything else that can be
> run from a shell effectively granting the same privileges.

It allows a privilege escalation. A program running with user rights cannot
gain root rights using execve(1). A malicious program run by a user running
a root session in another konsole session can - via automation. The user
may be suspicious, but trust the OS to contain the program within his privileges.
This is not longer true with a konsole having this feature.


> Or to say it different: why should anybody care about a DBus method,
> when allowed to execute own code on the local machine anyway?

Because it is not the own code. I never compile, install or run anything outside
my distribution with root rights to contain wanted or unwanted negative effects
of software i try within the bounds of the user account.


> I agree however, there are potential issues when having local and/or
> remote sessions of shells with different privileges. But again: still
> you have to run malicious code by the user's will, and I don't think
> that we should consider this as one of konsole's problems just because
> the fact that konsole _allows_ different security contexts (which is
> essential for a shell I guess). You wouldn't either blame SSH insthead
> of the user using it, just because it _allows_ root logins?

The SSH is fine. For a root login, one needs the password. Thus a malicious
program cannot escalate its rights via ssh without knowing the password.

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

A general security assumption under Unix/Linux, etc is, that privilege escalation
is not possible without the explicit user permission. A user has all rights to trust
this assumption and it is an obligation to all programs allow a privilege escalation.


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.


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.

A terminal applications can be attacked by insert keystrokes or by eavesdropping
them. Having access to screen content is another, but at least, login is aware of
this and protects its password field.

The eavesdropping problem with the konsole is closed on the pty side to the best
of my knowledge, but the konsole can be eavesdropped from any other X client.

xterm has a 'secure keyboard' feature preventing this by exclusively claiming the
keystrokes. But I think keystroke might be injected from another X-client to any
X-terminal via XSendEvent(3). A X-client has good opportunities to identify a root
session e.g. via the process list.

So one might argue, that this scripting feature punches only another hole, but IMO
it is better to close them one by one. Right now, the only protected root terminals
are those on a linux console. It is so bitter. I always had a permanent root session
running on X until now.


So beside the automation feature, X-security is an issue, and this affects any program
within a security domain different from the user account, e.g. a konqueror session
doing on-line banking. Though protected network-wise, it can easily be compromised
via any X-client. Additionally, the X server is a root/suid program.

Right now, Linux desktop systems are too few, to be an attractive goal. Also, its users
are often pretty security aware. But if Linux continues to broaden its user base and the
use of graphical programs, this might change, and being truly helpful to users means
to provide them a secure environment, too, IMO.

For the issue of X running root/suid (plug-ins, anyone?), current works on the X/kernel
interaction will likely provide a solution, soon. Protection against privilege escalation
via X-client or X client-client interaction is not established. There was an X-SECURITY
extension, but it seems to be obsolete and superseded by XACE (X Access Control
Extension) which does not appear to be very alive, too.

-lars