That is truly a great example of how to deliver a stern reproval, while still being polite and professional. From Theo, no less. I wish more project leaders would follow that style.
A lot of people were saying they didn’t want linus to change because he would be less effective but this is a perfect example of an effective email without using insults.
From someone that has spent 20k+ hours digging around in these layers – there is a number of things going on that warrants a much longer breakdown, but again - and this is true in OpenBSD as well - root is a misdirect as soon as you are dealing with graphic ‘UI’s since around the advent of DRI2, possibly earlier. About the time that the very idea of a framebuffer died a thousand deaths.
If you rely, in any way shape or form, of protecting yourself against local privilege escalation from a client that has the ability to allocate or access graphic resources, in the context of letting untrusted code run - your threat model won’t help you if targeted. If in the general populace just don’t run a web browser (or games, but jeesh) on anything you care about. Shove it to separate hardware, access remotely, reset often. Don’t run untrusted GPU accessing code on your machine, or don’t keep anything valuable on the same machine, end of story. There are so many ways of deceiving and tricking you, your computer or the layers in between to give away the last steps to ‘root’ that it is not worth considering.
We barely can get system graphics to behave pixels-to-the-screen OK (not even performing to hardware capability mind you) with a single user perspective. Absolutely no-one are testing more adversarial scenarios. It’s a machine running on fumes and any ‘Wayland solves this’ nonsense is just a sign of collective scientology-like religious sci-fi group thing and the person behind it is full of crap. It is a student level exercise to see that it actually gets worse. Read the security section in their documentation. It is a very quick read.
Absolutely no-one are testing more adversarial scenarios.
High-security community has been. They had a few systems designed for that. One that’s still maintained via Genode project is Nitpicker GUI. Here’s an early one Epstein did to reduce attack surface of X Windows in 1996. The work just keeps getting ignored like most stuff from that sub-field.
Glad some of you are still trying to get the mess under control.
Sure if we dig into the ‘non-dominant’ stack there are quite a few of them. I’d say the GenodeOS design and writeup, starting with the Ph.D thesis here(PDF) is one of the more thorough and thoughtful.
In my little tirade I was thinking specifically about the core components underlying accelerated graphics access (Mesa/Drm/Kms/Gbm/Gem/…) there are many semi-finished, accessible discarded features and ideas still floating around in there. Follow the path on how a client gets a GL context setup against X, how it allocates buffers etc. for some real nightmare fuel – and in the end, OpenGL is like 400 different words for memcpy where you are not quite sure of what src, dst or size is, or what happens to data in transit.
X on OpenBSD runs with privilege separation, but has code that runs as root.
The patch fixing this exploit is in ddxProcessArgument (called from ProcessCommandLine), which is executed before privileges are dropped in OsVendorInit (called from OsInit). Hence the exploit is in code running as root.
It doesn’t. The most modern parts still requires continuous root-only (DrmMaster) access to sensitive resources. Linux uses a broker that is equivalent to immediately setuid-drop (session managers, logind and other kinds of perpetual bullshit), it helps here but it’s a layer where security is a tertiary concern at best.
The last paragraph feels like a real non-sequitur to me:
That is the first localhost root hole in quite a long time.
This vulnerability existed for however long it’d been since it was introduced, regardless of when OpenBSD found out or shipped a fix. If the complaint is that they didn’t find out soon enough, it’s important to acknowledge that finding out sooner would not have changed the fact of the vulnerability existing.
I am coming out of Lobsters retirement to say this…
“Only two remote holes in the default install, in a heck of a long time!” is the tagline front and center of the OpenBSD website. This new line is too similar to not be an attempt at a “cute” homage and nothing more.
it’s important to acknowledge that finding out sooner would not have changed the fact of the vulnerability existing.
I think it’s less important to point out obvious facts, than it is to highlight that the existence of this vulnerability may have led to undetected, and still active exploits of it. In other words, the severity of a root hole should not be understated.
I think it is a reference to OpenBSD’s slogan “Only two remote holes in the default install, in a heck of a long time!”, probably it shouldn’t be taken at face value.
That is truly a great example of how to deliver a stern reproval, while still being polite and professional. From Theo, no less. I wish more project leaders would follow that style.
A lot of people were saying they didn’t want linus to change because he would be less effective but this is a perfect example of an effective email without using insults.
A root, by any other name …
From someone that has spent 20k+ hours digging around in these layers – there is a number of things going on that warrants a much longer breakdown, but again - and this is true in OpenBSD as well - root is a misdirect as soon as you are dealing with graphic ‘UI’s since around the advent of DRI2, possibly earlier. About the time that the very idea of a framebuffer died a thousand deaths.
If you rely, in any way shape or form, of protecting yourself against local privilege escalation from a client that has the ability to allocate or access graphic resources, in the context of letting untrusted code run - your threat model won’t help you if targeted. If in the general populace just don’t run a web browser (or games, but jeesh) on anything you care about. Shove it to separate hardware, access remotely, reset often. Don’t run untrusted GPU accessing code on your machine, or don’t keep anything valuable on the same machine, end of story. There are so many ways of deceiving and tricking you, your computer or the layers in between to give away the last steps to ‘root’ that it is not worth considering.
We barely can get system graphics to behave pixels-to-the-screen OK (not even performing to hardware capability mind you) with a single user perspective. Absolutely no-one are testing more adversarial scenarios. It’s a machine running on fumes and any ‘Wayland solves this’ nonsense is just a sign of collective scientology-like religious sci-fi group thing and the person behind it is full of crap. It is a student level exercise to see that it actually gets worse. Read the security section in their documentation. It is a very quick read.
High-security community has been. They had a few systems designed for that. One that’s still maintained via Genode project is Nitpicker GUI. Here’s an early one Epstein did to reduce attack surface of X Windows in 1996. The work just keeps getting ignored like most stuff from that sub-field.
Glad some of you are still trying to get the mess under control.
Sure if we dig into the ‘non-dominant’ stack there are quite a few of them. I’d say the GenodeOS design and writeup, starting with the Ph.D thesis here(PDF) is one of the more thorough and thoughtful.
In my little tirade I was thinking specifically about the core components underlying accelerated graphics access (Mesa/Drm/Kms/Gbm/Gem/…) there are many semi-finished, accessible discarded features and ideas still floating around in there. Follow the path on how a client gets a GL context setup against X, how it allocates buffers etc. for some real nightmare fuel – and in the end, OpenGL is like 400 different words for memcpy where you are not quite sure of what src, dst or size is, or what happens to data in transit.
Oh yeah, the legacy stuff is a nightmare. No argument from me. Glad you’ve been looking at the alternative designs. :)
for those who missed what’s going on here is a summary and further links on The Register https://www.theregister.co.uk/2018/10/25/x_org_server_vulnerability/
CVE-2018-14665
Wait, doesn’t OpenBSD run Xorg as non-root? How is that a root hole on OpenBSD?
X on OpenBSD runs with privilege separation, but has code that runs as root.
The patch fixing this exploit is in ddxProcessArgument (called from ProcessCommandLine), which is executed before privileges are dropped in OsVendorInit (called from OsInit). Hence the exploit is in code running as root.
Apparently, it depends on what kind of drivers are used:
It doesn’t. The most modern parts still requires continuous root-only (DrmMaster) access to sensitive resources. Linux uses a broker that is equivalent to immediately setuid-drop (session managers, logind and other kinds of perpetual bullshit), it helps here but it’s a layer where security is a tertiary concern at best.
The last paragraph feels like a real non-sequitur to me:
This vulnerability existed for however long it’d been since it was introduced, regardless of when OpenBSD found out or shipped a fix. If the complaint is that they didn’t find out soon enough, it’s important to acknowledge that finding out sooner would not have changed the fact of the vulnerability existing.
I am coming out of Lobsters retirement to say this…
“Only two remote holes in the default install, in a heck of a long time!” is the tagline front and center of the OpenBSD website. This new line is too similar to not be an attempt at a “cute” homage and nothing more.
I think it’s less important to point out obvious facts, than it is to highlight that the existence of this vulnerability may have led to undetected, and still active exploits of it. In other words, the severity of a root hole should not be understated.
I was wondering where you went. Missed your comments. Feel free rejoin any time and otherwise enjoy your retirement. :)
I think it is a reference to OpenBSD’s slogan “Only two remote holes in the default install, in a heck of a long time!”, probably it shouldn’t be taken at face value.
I’m confused too. Wouldn’t it have affected 6.3?
It does.