Comment by johnchristopher | Hacker News Reader

Comment by johnchristopher | Hacker News Reader

johnchristopher

I can't find it on his website at the moment but he has an excellent explanation of why gnome-screensaver is inherently insecure. If I remember correctly it boils down to something like: `nobody can guarantee that gnome-screensaver is secure because it relies on GTK which nobody can prove or guarantee that it's 100% secure because there's too much code to check.`.

edit: found it:

I am as close to certain as I can be that there is no action a user can take on their input devices that will cause the current Xlib-based lock dialog in xscreensaver to unlock. That's because it's a small amount of code that I have stared at and tested for a very long time. It is a small enough piece of code that I (believe I) know every possible path through it.

Introduce N layers of widget library, general text field handling, compose processing, input methods, I18N... and all bets are off. Who knows what bugs wait lurking in there; who knows which particular combinations of which libraries are a security-bug timebomb.

Let me put that another way:

The GTK and GNOME libraries have never been security-audited to the extent that their maintainers would be willing to make the claim, "under no circumstances will this library ever crash."

One can, within a reasonable doubt, make that claim about libc, or even about Xlib, but not about anything the size of GTK. It's just too big to be sure. This is not a criticism of GTK or GNOME or their authors: it's simply a truth about any piece of software of that size.

But why can he vouch that libX11 is any more secure? The library that runs complex input method code on every key-press, that has had CVEs in it? [0] [1]

[0] https://cgit.freedesktop.org/xorg/lib/libX11/tree/modules/im... [1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-20...

Not to mention that I can still write a keylogger that bypasses jwz's xscreensaver. [2]

[2] https://github.com/magcius/keylog

I believe this blog post http://blog.martin-graesslin.com/blog/2015/01/why-screen-loc... is relevant to the conversation and the key logger part (but I am out of my league to comment about it).

> But why can he vouch that libX11 is any more secure? The library that runs complex input method code on every key-press, that has had CVEs in it? [0] [1]

GTK (at least the 2.x series, I don't know if that's changed in 3.x) uses libx11. There's a good chance that, if there's a major flaw in libx11 which can be exploited, a GTK-based program is vulnerable to it. GTK is pretty massive, so it likely introduces issues of its own.

E.g. this bug: https://bugzilla.gnome.org/show_bug.cgi?id=722106 in GTK triggered this problem: https://bugzilla.redhat.com/show_bug.cgi?id=1064695 .

> Not to mention that I can still write a keylogger that bypasses jwz's xscreensaver. [2]

You can write a keylogger that bypasses pretty much anything that's X-based.

To, uh, to put it bluntly, ditching X11 for something saner would be the correct approach. Stacking stuff on top of X11 makes the problem worse; not stacking anything leaves it pretty bad. I'm not overly optimistic about Wayland, but I guess we'll have to wait and see :-).

Didn't know that screen locks were supposed to defeat keyloggers. I thought they existed to stop people walking up to an unattended computer and mess around.

Anyways, if i am reading the CVE right it is about how X11 can be provoked into maxing out its stack. Possibly annoying for those trying to use X11, but not something that leaks data.

The more i see "security" discussed on HN, the more i feel that there needs to be a ranking system. All to often it seems like people are operating with a binary definition of security, putting anything with a CVE in the insecure bin.

Then again he got egg on his face recently because the xscreensaver lock screen would crash if the display output was switched (or some such).

Was that a security issue or just a crash?

It would lead to the screen becoming unlocked, iirc.

Edit: Just to add a bit more detail. xscreensaver locks the screen by putting a window across it that grabs ownership of input devices. Thus if it crashes, the window goes away and the inputs released.

I think that's basically how all the X11 screenlockers work, sadly.

Yes. But xscreensaver only use straight xlib to paint any UI elements. JWZ's argument is that this reduce the chance of bugs vs using the likes of GTK or Qt to draw password prompts etc.

I don't think he meant to say it was flawless, but I'm sure you agree it reduces the attack surface by a great deal.

Looking at bug tracker activity so far would suggest that it does, but of course, the stats might be skewed by far more people using a Gnome/Unity/Cinnamon/whatever-ified version of xscreensaver than the vanilla one.

I read about that bug a while ago. It was due to mishandling a strange X11-specific cornercase; to be fair, that's the kind of stuff that is certainly more aptly handled (in the X11 world) in a toolkit (X11-specific cornercases are like 30% of the reason why, as soon as alternatives to Xlib were available, everyone embraced them and cried tears of joy), which would suggest that not relying on toolkits opens xscreensaver's locker to other issues that are more aptly handled in a toolkit.

However, if you look over the bugs that Gnome, Cinnamon or Unity's wrappers had... I'm inclined to think that there are a lot more trivial problems (like the one I linked in my other comment, here : https://news.ycombinator.com/item?id=11412688 ) in Gnome's a thousand and one libraries than there are cornercases in X11.

Reply on news.ycombinator.com