Shared publicly  - 
 
I highly recommend to watch this great talk about X Security on the 30c3. Next week I schedule a day to look at our new xcb code under the thought "X is not trusted" (I think everything should be fine but I would consider it as fun to hack KWin). I'm also sure that our XLib usage wasn't showing the problems mentioned for XGetWindowProperty in the talk (ported away a large part recently in NETWM classes and they all had success check). The talk nicely illustrates why I don't want to have KWin as a privileged Wayland compositor as long as we talk to X (there are other reasons, too).

Anyway there is some work for +Rohan Garg and the other Kubuntu devs with KPPP mentioned (and I'm going to bug them about that).
27
4
Thorsten Leemhuis's profile photoAndreas Proschofsky's profile photogeorge oloo's profile photoDaniel Schrammel's profile photo
25 comments
 
What surprised me a bit was that after I saw him denounce KDE and Qt as buggy crap with developers who refuse to listen to him, I didn't manage to find a single bug report in either KDE's or Qt's bug tracker. Maybe he's got a really weird nick, though.
 
+Boudewijn Rempt in case he wrote to a security mailing list, it wouldn't be in the bug tracker. Personally I go with the opinion of the Qt devs: that's not an issue in the library.
 
I was hoping it gave a bit of insite on how/why any application could arbitrarily grab all the keyboard input, or any application could just turn off your monitor or set xatoms and what not, instead of just a "blunt" code review
 
+Kai Uwe b well as he says: the problems with the protocol are known for years - no point in repeating them.
 
Very interesting talk indeed. As to allowing setuid, I'd rather disallow it by default, and allow users to allow setuid if they really need it, so safer be default. It may not be the lib's responsibility, but surely some guidance cannot hurt.
 
+Boudewijn Rempt He did report the issue to qt security, and I explained to him that anyone using Qt in an suid binary was doing it wrong. He seems to think that since we're writing a library we're responsible for all ways it can be misused, which is not the case. Rather than the convoluted attack he found (which was a genuine bug, but not a security issue) there are simple ways to perform attacks. This part of his talk relies on the premise that some distros might install kppp in a configuration (suid) that hasn't been recommended for over a decade. If distros do this then that's a bug in the distro, not in Qt.

The talk is a rerun of the presentation he gave back in May which I responded to at the time http://lwn.net/Articles/552300/ there are some genuine issues in it, but sadly he chose to overhype things.
 
Hmm, I think he is right that both bugs he presents are potential security problems. I think Qt should check for instance that it does not copy more than five elements (see his first example).
 
+Wolfgang Walter right, but the question is whether that is really that valid and the code is not present in Qt 5.2 (doesn't use XLib). So if one doesn't see them as security issues, but as just bugs, it becomes not a high priority problem for Qt 4.x. If I would think it's in my code base I doubt I would fix it.
 
I think Qt4 is in much wider use than Qt5 and that will not change for some time. I can't say if and how easy this can be exploited. But developers very often underestimate these things.
 
+Wolfgang Walter the point is that rather than performing a very complicated attack that relies on a malicious X server, you can simply use a trivial attack that takes around 20 lines of code and is much easier. Frameworks like Qt, GTK etc. are not suitable for suid binaries - that's not what they're for.
 
+Richard Moore
Yes... I saw that it was a rehash of an earlier talk, but he was so vehement about the crappiness of Qt and KDE that, of course, he must have found more than one or two issues, right?

Seems he didn't, then.

Ah. And following the link to lwn, seems I wasn't impressed by the guy back then anyway. I even forgot all about it :-)
 
+Boudewijn Rempt He's using Windows, what makes him qualified talking about quality of Qt/KDE? scnr duck
 
+Richard Moore  I very much agree - there are certainly much easier attacks. And neither GTK nor Qt should be used for suid binaries, no question.
But my experience says that you can jugde the overall security of a software product rather well if you look how developers handle and fix such bugs: do they fix or discuss.
In my job e.g. we use a software where we detected (or were hinted at) several bugs. It's always an endless discussion with the developers if it is really a security relevant bug and when yes  if it can be exploited remotely. Though I'm not a hacker I succeded evey time writing such an exploit. The energy directed in that whole process is always greater than simply fixing it (especially if we sent a patch). I think it's their proud.
 
+Wolfgang Walter in some cases, that's certainly true. However since I did discuss it with him, and he agreed with me that for this to be a security issue, you had to be running suid which we don't support it's a bit rich for him to complain about it in these terms. He also didn't file a non-security bug as requested.

Anyway, I've just pushed https://codereview.qt-project.org/#change,74531 which should make it clear to everyone that this is not a supported use-case.
 
+Richard Moore I again agree (and I appreciate that change). I also appreciate van Sprundel works. (Looking at others code searching bugs is not something I want to do as I find this rather boring). He should have mentioned, though, that he already talked about it in May.

Debian, by the way, made kppp non-suid (30.6.2013) because someone filed a bug based on his talk then. But debian hasn't classified it as security issue so it is still suid in wheezy and in squeeze :-(.
 
+Richard Moore So I can't use QtCore in my suid application? If this is about GUIs, shouldn't this be tied to QApplication or QWindow rather than QCoreApplication?
 
+Aaron Seigo in the current version of the patch you can if you call setAllowSuid(true); but then it's your responsibility to clean up QT_PLUGIN_PATH etc. I''ll probably do a separate patch to close some obvious holes for you when you enable this (the plugin path and maybe some library search locations). The problem isn't just about Qt GUI though, for example there's imageio plugins to consider.
 
At one point he says something like "no one uses a X Font Server anymore". Isn't RedHat using it by default?
 
One update on this. Dfaure and I have discussed it and looked at the KPPP code and it turns out KPPP drops privs before using any Qt code so it's actually doing the suid correctly.
 
+Richard Moore This is good news - not only because of kppp itself but because it shows that the developpers got it right.
And thanks for looking at it.
Add a comment...