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

[Robert Knight]

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

Why are you not using parallel SSH or the "Copy Input To..." feature?

Regards,
Robert.


2009/5/5 Arno Töll <lists at toell.net>:
> 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) .
>
> From the other mail:
>> To leave the general consideration, what are the intended uses of the feature?
>> When the feature was removed earlier, it was limited to send a 'cd Dir' (where
>> Dir is a proper path name) to allow konqueror to control an embedded konsole,
>> which clearly is much harder to abuse.
>
> which is pretty useless though. A "cd DIR" is a pretty particular
> demand, which may be done much nicer by giving konsole session a
> specified working directory, e.g. in a profile or by giving "--workdir".
>
> It still is a bad idea to whitelist just particular, what about a "cd
> foo; rm -rf " for example or any given shell meta character? I still
> don't think it should be konsole's responsibility to declare what are
> "good" and "bad" commands for the underlying shell. Think about KDE on
> Windows for example.
>
> I think, in general there are very good reasons to allow DBus to send
> keystrokes. We could, however, add an additional security layer, which
> simply would ask the user if he wants to allow the sender to send
> keystrokes. For example with a profile based user given whitelist, that way:
>
> - Caller sends keystroke "apt-get upgrade"
> - konsole asks the user "Caller wants to send 'apt-get upgrade' to your
> terminal in window X. Allow that?
>  [edit whitelist, e.g. specify wildcards]
>  ( ) Yes, in that session only
>  ( ) Yes (remember this setting)
>  ( ) No (Don't ask again)
>
> I think, Robert will be happily accept this patch, but I'd very unhappy
> when removing that method. Of course this patch is just a solution for
> that konsole problem, not resolving the (ab)use case for an attacker by
> doing the almost the very same on the underlying X architecture.
> _______________________________________________
> konsole-devel mailing list
> konsole-devel at kde.org
> https://mail.kde.org/mailman/listinfo/konsole-devel
>