X Server Security Disaster: "It's Worse Than It Looks"

http://www.phoronix.com/scan.php?page=news_item&px=MTU1NzA

Among the quotes used were "GLX is a horrible demotivator! 80,000 lines of sheer terror." and "In the past couple of months I've found 120 bugs there, and I'm not close to done."

More X security problems. Can't believe people are only just now starting to pick up on how shitty that codebase is for security.

 

Personally I'm still dubious about Wayland. (Do we really need to make everything OpenGL based? Will this thing work at all on my legacy hardware?) OTOH, portability is probably a nonissue at this point. Last I checked, BSD was on the decline in the server world, and it's so far behind on the desktop (in terms of graphics and hardware support) that it might as well not exist. Being stuck with X will just be another nail in the coffin. I hate to say it, but it's probably better to make a clean break, honor be damned.

No, I won't be sorry to see X go. Especially after the trouble it's given me with VIA and nVidia GPUs, and with Xen... Good riddance.

On the other hand, I wonder to what extent it would be possible to secure an X server at compile time, given a really dedicated effort. Not compiling in hardware acceleration is easy. Making it run without root privileges would probably be more difficult, but might be doable with the fbdev or modesetting driver and some hackery. I don't know - what else would need to be changed to make it reasonably safe?

Edit: I do hope someone ports Fvwm to Weyland at some point, though.

Also I'm starting to see where whitelisting fans have a point. Desktop security is broken across the board, and the NSA et. al. already have access to most everything. So far most desktop threats have been either trivial (most malware) or unavoidable (NSA hardware backdoors). Pretty much any system can be assumed compromised from the moment it comes off the assembly line; on the other hand, the bulk of ITW malware is still poorly engineered rubbish, easily defended against.

Given that, I can see why some people don't even bother participating in the arms race any more. Why spend extra time, money, and effort on maintenance, if it doesn't actually help you? Etc., etc.

I suspect this sort of thinking will eventually turn around and bite those who engage in it. But seeing as a truly secure, well engineered desktop does not yet exist, it's easy to see why people would want to believe a badly engineered one was sufficient.

 

Pretty much everything. That's the problem. Not only is the protocol insecure but the code itself is just not written with security in mind.

They're still participating, the attackers just don't care. Running AE/ whitelisting is the same security policy as running OSX. It buys you no real security, buy you just don't really 'participate' in the Windows race, you enter your own separate one that people aren't interested in. And you rely on them forever not being interested.

Do we have any definitive hardware backdoors that don't require physical access? Not that I've heard of.

I don't think the NSA is currently capable of SHA1 hash collisions. I don't think they're capable of attacking a really hardened desktop, it's just a pain to get a hardened desktop set up.

 

Ah, thanks. That is too bad.

Well yes; you know that and I know that, and so has anyone who's ever messed around with Metasploit. But for most people, a poorly engineered solution that works (for now, and for the most immediate threats) seems superior to vaporware.

They have physical access - i.e. the manufacturers' cooperation.

SHA1 hash collisions -> maybe. I wouldn't assume anything though. If Lockheed can have a quantum computer, what sort of gear do you think the NSA has?

Attacking a really hardened desktop -> sure. As I said, they have physical access via the manufacturers. They don't need to hack through your hardened kernel, because your kernel assumes that hardware and firmware are trustworthy.

You might be able to avoid being spied upon locally, if you flashed every device in your computer with custom firmware... And then you'd still have to deal with MITM attacks.

Edit: some short reading (which you're probably familiar with): http://cm.bell-labs.com/who/ken/trust.html

This applies to firmware as well as compilers. IMO we have unfortunately reached the point at which nothing programmable is trustworthy.

 

Yes but to exploit the backdoors themselves one usually needs physical access. At least in the cases I've seen for things like breaking an encrypted HDD.

I think we are probably a solid 5 to 10 years off from a SHA1 collision.

Perhaps. But that's assuming that the hardware is backdoored in a way that is remotely accessible.

And what if you limit a processes ability to interface with the kernel or with the firmware? I don't know. I think hardware backdoors are more likely to fall under bypassing encryption.

edit: I do see your point. In a direct and targeted attack you are usually screwed, no matter what. If the NSA is going at you they will likely be able to obtain physical access, and if they have backdoors it's likely game over.

But, what about government malware/ APT like Flamer and Stuxnet? Those are not run of the mill attacks, they are not crappy, they're quite advanced and interesting. A basic setup will not stop them, not in a *meaningful* way (you can trip up lots of exploits with EAF, doesn't mean EAF is "good" security).

The government is packaging a dozen 0days into a single attack. They're using hash collisions. These are advanced attacks but they are *not* using backdoors. So defending against that level of threat, to some extent, still makes sense, even if in a targeted situation as a US resident things become a bit more futile (though I do not believe impossible).

 

Because its a protocol for communicating between a compositor and the clients (window managers for example).

Wayland moves a lot of tasks that X traditionally did to the client (fonts, multimonitor support) which means there is less that needs to run as root.

AFAIK the intention is is to move from having a centralised display server and a series of defined interfaces to the kernel (we already have DRI and DRM and KMS).

 

@NGRhodes: doesn't using OpenGL as the protocol mean that emulation of a GPU will be required in the absence of hardware acceleration? i.e. no usable fallback for people with slow CPUs and unsupported graphics hardware?

 

Anything can be used for the rendering, just that Kwin and Mutter plan on using OpenGL (not heard mention of non-3d rendering for these). The reference implementation, Weston, supports both OpenGL an pixman (similar to Cairo in GTK).

 

So, just an addendum to the above discussion... The last couple days I've been working on some window manager code as a project. Which means dealing with Xlib. Which does not look to be in a good state.

e.g. one of the more noticeable things that crops up everywhere in it, is that function parameters that are never supposed to be modified must nonetheless be mutable.