10 ms·

The X hole

167 points by bjpbakker 8y ago

based2 8y ago
https://lobste.rs/s/ebmcvk/x_hole https://lobste.rs/s/ebmcvk/x_hole
krackers 8y ago
Which CVE is this referencing?
- jvreeland 8y ago
  This I assume: https://lists.x.org/archives/xorg-announce/2018-October/002927.html https://lists.x.org/archives/xorg-announce/2018-October/0029...
  - romed 8y ago
    This is much more interesting than all of this soap opera about Theo. What we see in this commit, regression, and vuln is that the X server is an enormous setuid program with tons of code and zero tests. The "fix" also does not contain any tests that could have detected the problem, so it's just a continuation of what is now a quarter-century of bad software engineering practices.
    - slededit 8y ago
      X was built on false assumptions of what the future would look like (dumb terminals). The whole thing is a massive hack around its server/client architecture - which does not work well with modern graphics hardware. It’s no small part of why Linux has failed on the desktop. In short, lack of tests are the least of its problems.
      - romed 8y ago
        The design defects of X11 do not necessitate the implementation defects of Xorg.
JshWright 8y ago
Given OpenBSD's pre-embargo leak of KRACK, I'm not sure why they feel entitled early access...
- wahern 8y ago
  Except they didn't. This has already been debunked: https://news.ycombinator.com/item?id=16440826 https://news.ycombinator.com/item?id=16440826
  - dx87 8y ago
    The only reason the researcher gave permission was because the OpenBSD devs said that they were going to release on the original embargo date instead of extending out to 90 days like everyone else agreed to. They even say on their mailing list that they probably announced too much with their errata when they "silently" patched it. They techincally didn't break the embargo, but only because they refused to go along with what the rest of the community was doing.
    - anjbe 8y ago
      > The only reason the researcher gave permission was because the OpenBSD devs said that they were going to release on the original embargo date instead of extending out to 90 days like everyone else agreed to. “Said that they were going to”? More “expressed a desire to.” And that was a reasonable desire—so reasonable that the researcher willingly agreed, if reluctantly. https://marc.info/?l=openbsd-tech&m=152909822107104&w=2 https://marc.info/?l=openbsd-tech&m=152909822107104&w=2 Do you think it unreasonable for one project to strongly push back against a 180 day embargo? How about a year embargo? Two years? Is there any point where a project can say, “We believe extending the embargo beyond what we’ve agreed to is going to keep our users unpatched, and won’t succeed at keeping the bug secret, so we’d like your permission to release according to the schedule we agreed to,” or is that verboten since it’s not “going along with the rest of the community”?
- tech-no-logical 8y ago
  as I read it, it seems openbsd's X maintainer, matthieu herrb, knew about it but didn't tell theo or the other openbsd devs. that seems strange, and not really related to early access.
deleted 8y ago
[deleted]
protomyth 8y ago
Well, it looks like they have a patch [syspatch64-001_xserver] not sure which fix they chose. [edit] a tweet for @OpenBSD said: We're currently preparing errata and a security advisory for today's Xorg issue that allows arbitrary overwriting of files as a non-root user. You can run "chmod u-s /usr/X11R6/bin/Xorg" as a temporary workaround until the fixes are out.
cperciva 8y ago
OpenBSD doesn't keep secrets. The X.org team had to keep this secret, so they couldn't tell OpenBSD. If OpenBSD starts participating in embargoes, they'll get advance notice of vulnerabilities. It's as simple as that.
- deleted 8y ago
  [deleted]
  - deleted 8y ago
    [deleted]
- tedunangst 8y ago
  Come on, you know better than that.
  - cperciva 8y ago
    Maybe I should have said Theo rather than OpenBSD? But seriously, look at the Lazy FPU thing -- someone leaked it to Theo, and his immediate response wasn't "gee, this sounds serious, I should work together with other vendors to make sure that we can all get this fixed"; it was "let's publicly disclose the vulnerability at the soonest opportunity". I'm not saying that he has agreed to embargoes and then broken them. I'm saying that he has made it clear that he isn't interested in acting as a productive member of the community.
    - tedunangst 8y ago
      I think you've been cut out of enough embargoes to understand the openbsd position. Embargoes hurt users. The decision to not work together on lazy FPU was made before Theo got involved. What Theo and others, including myself, have made clear is that embargoes suck, and we will complain about them as is our right, but we will attempt to honor them if that's how it going to be.
      - cperciva 8y ago
fizwhiz 8y ago
For some of us who aren't OS enthusiasts: can anyone provide an ELI5 or deeper context links?
- Lazare 8y ago
  There's a serious bug that impacts a number of operating systems, including OpenBSD. In order to coordinate a release, some vendors were made aware of the bug before it was publically disclosed, but OpenBSD was not one of them, probably because OpenBSD has a reputation (fairly or not) as being very anti-secrecy, not being cooperative in situations like this, and not providing other vendors advance notice of issues they find. OpenBSD is, understandably, upset that they ended up shipping a bug when they could easily have delayed the release had they been made aware of it. Whether that's a legitimate complaint, or simply their just deserts given their past behaviour, or somewhere in between is something I'm not remotely qualified to answer. In any case, if people won't trust you to follow embargoes, you'll end up shipping bugs, and angrily complaining on public mailing lists that people don't trust you won't make people start trusting you. (For one thing, notably absent from the linked post was a "we would have course adhered to the embargo if we'd been asked", which leaves the question open of whether not trusting them, in this specific case, may not have been correct. In any case, this will be resolved, if it's resolved, in private between concerned individuals.)
  - owenmarshall 8y ago
    To add a wrinkle that may be missed from a quick read of Theo’s post: OpenBSD’s X maintainer is on the X.org security team - that’s the Matthieu referenced. So it’s possible that an entirely human set of mistakes occurred that lead to this happening; it’s also possible that embargoed bugs came in to play.
    - Lazare 8y ago
      Yes. Simple oversight is possible. Alternatively, if it is a trust issue, the fact that it's not just "the X.org security team doesn't trust the OpenBSD maintainer team" but "the OpenBSD X maintainer doesn't trust the rest of the OpenBSD maintainer team" adds several extra levels of politics to this, which I suspect is what Theo was alluding to with his "abdication of the duty of care" comment. I assume Matthieu acted (if that is indeed what he did) in his role as a member of the X security team, but I imagine Theo would say that in doing so he failed to act appropriately in his role as a member of the OpenBSD maintenance team. It all makes me quite interested to know what his reasoning was.
DonHopkins 8y ago
Excerpt from the "Official Dangerous Virus Notice" Distributed at the X-Windows Conference: >This is what happens when software with good intentions goes bad. It victimizes innocent users by distorting their perception of what is and what is not good software. This malignant window system must be destroyed. >Ultimately DEC and MIT must be held accountable for this heinous software crime, brought to justice, and made to pay for a software cleanup. Until DEC and MIT answer to these charges, they both should be assumed to be protecting dangerous software criminals. >Don’t be fooled! Just say no to X. >X-Windows: …A mistake carried out to perfection. X-Windows: …Dissatisfaction guaranteed. X-Windows: …Don’t get frustrated without it. X-Windows: …Even your dog won’t like it. X-Windows: …Flaky and built to stay that way. X-Windows: …Complex non-solutions to simple non-problems. X-Windows: …Flawed beyond belief. X-Windows: …Form follows malfunction. X-Windows: …Garbage at your fingertips. X-Windows: …Ignorance is our most important resource. X-Windows: …It could be worse, but it’ll take time. X-Windows: …It could happen to you. X-Windows: …Japan’s secret weapon. X-Windows: …Let it get in your way. X-Windows: …Live the nightmare. X-Windows: …More than enough rope. X-Windows: …Never had it, never will. X-Windows: …No hardware is safe. X-Windows: …Power tools for power fools. X-Windows: …Putting new limits on productivity. X-Windows: …Simplicity made complex. X-Windows: …The cutting edge of obsolescence. X-Windows: …The art of incompetence. X-Windows: …The defacto substandard. X-Windows: …The first fully modular software disaster. X-Windows: …The joke that kills. X-Windows: …The problem for your problem. X-Windows: …There’s got to be a better way. X-Windows: …Warn your friends about it. X-Windows: …You’d better sit down. X-Windows: …You’ll envy the dead. https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
newnewpdro 8y ago
TIL OpenBSD still installs Xorg setuid root, yikes.
- bitwize 8y ago
  IKR? OpenBSD should really use systemd-logind and Wayland, the way modern desktops do.
  - newnewpdro 8y ago
    Or just get a drm equivalent implementation that doesn't require root privileges for the modesetting Xorg driver to function.
    - anjbe 8y ago
      OpenBSD has that, but X was still kept setuid so the non-modesetting drivers would still work. Well, since yesterday obviously: https://marc.info/?l=openbsd-cvs&m=154050453117246&w=2 https://marc.info/?l=openbsd-cvs&m=154050453117246&w=2
      - newnewpdro 8y ago
        Unnecessarily installing binaries as setuid... for how long now? So much for secure by default.
busterarm 8y ago
Responsible disclosure is a scam that puts vulnerability researchers, downstream project maintainers and users in the position of being malicious actors all while absolving those responsible from their responsibility. Immediate and public disclosure is the only responsible disclosure there is and I commend (and monetarily contribute to) the OpenBSD Project for their soft stance against embargoes. Operating in opposition to that, a large portion of the security industry plays along for reasons varying from personal pride (appealing to authority makes you feel like one of the good guys) to the extremely lucrative payouts for selling 0day to nation states. It's no surprise that the higher your profile in the industry and on twitter, the easier time you have getting paid out on bug bounties. All of this hurts users. I develop and maintain software and software infrastructure for a living. If you find a vulnerability in work I am responsible for, please rake me over the coals as publicly and loudly as you can. That motivates the PTB who fund my work to resolve the issue better than anything else.
- MaxBarraclough 8y ago
  I'm not convinced. Google's policy seems about right to me. When they discover a security flaw in someone else's software, they give them 90 days before making it public [0]. The choice of 90 days is to strike a balance between applying strong pressure to the company to get it fixed fast, and giving them a reasonable amount of time to get it done and rolled-out. My understanding is that this approach generally works fairly well. You'd rather that they adjust that notice period all the way down to zero, and hand vulnerabilities over to the bad guys for free right out of the gate? [0] https://arstechnica.com/information-technology/2015/02/google-updates-disclosure-policy-after-windows-os-x-zero-day-controversy/ https://arstechnica.com/information-technology/2015/02/googl...
  - desdiv 8y ago
    You are assuming that the white hat security researcher was the first to discover the flaw. That is a perfectly reasonable assumption, and your position is perfectly reasonable given that assumption. GP was assuming that the white hat security researcher was not the first to discover the flaw, and that the flaw is actively being used to attack users. That is a perfectly reasonable assumption, and GP's position is perfectly reasonable given that assumption.
yitchelle 8y ago
Is it common that this type of disputes are commonly discussed in the public? I guess that by doing the type of discussion in the public, the level of accountability is a lot higher for all concern.
bubblethink 8y ago
From the RH bug report (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14665 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14665), this is described as “an incorrect permission check for -modulepath and -logfile options when starting X.Org,". Would wayland be immune to these kinds of things, or is it not relevant here ? And is OpenBSD planning to switch to wayland ?
- bitwize 8y ago
  This vulnerability can be mitigated if you don't run X as root. Use the modesetting driver and ensure permissions to the video device with Unix groups or a mechanism like systemd-logind. Since Wayland compositors are almost never setuid root, it isn't a problem for them.

The X hole

167 points by bjpbakker 8y ago

based2 8y ago

https://lobste.rs/s/ebmcvk/x_hole https://lobste.rs/s/ebmcvk/x_hole

krackers 8y ago

Which CVE is this referencing?

jvreeland 8y ago
This I assume: https://lists.x.org/archives/xorg-announce/2018-October/002927.html https://lists.x.org/archives/xorg-announce/2018-October/0029...
- romed 8y ago
  This is much more interesting than all of this soap opera about Theo. What we see in this commit, regression, and vuln is that the X server is an enormous setuid program with tons of code and zero tests. The "fix" also does not contain any tests that could have detected the problem, so it's just a continuation of what is now a quarter-century of bad software engineering practices.
  - slededit 8y ago
    X was built on false assumptions of what the future would look like (dumb terminals). The whole thing is a massive hack around its server/client architecture - which does not work well with modern graphics hardware. It’s no small part of why Linux has failed on the desktop. In short, lack of tests are the least of its problems.
    - romed 8y ago
      The design defects of X11 do not necessitate the implementation defects of Xorg.

JshWright 8y ago

Given OpenBSD's pre-embargo leak of KRACK, I'm not sure why they feel entitled early access...

wahern 8y ago
Except they didn't. This has already been debunked: https://news.ycombinator.com/item?id=16440826 https://news.ycombinator.com/item?id=16440826
- dx87 8y ago
  The only reason the researcher gave permission was because the OpenBSD devs said that they were going to release on the original embargo date instead of extending out to 90 days like everyone else agreed to. They even say on their mailing list that they probably announced too much with their errata when they "silently" patched it. They techincally didn't break the embargo, but only because they refused to go along with what the rest of the community was doing.
  - anjbe 8y ago
    > The only reason the researcher gave permission was because the OpenBSD devs said that they were going to release on the original embargo date instead of extending out to 90 days like everyone else agreed to. “Said that they were going to”? More “expressed a desire to.” And that was a reasonable desire—so reasonable that the researcher willingly agreed, if reluctantly. https://marc.info/?l=openbsd-tech&m=152909822107104&w=2 https://marc.info/?l=openbsd-tech&m=152909822107104&w=2 Do you think it unreasonable for one project to strongly push back against a 180 day embargo? How about a year embargo? Two years? Is there any point where a project can say, “We believe extending the embargo beyond what we’ve agreed to is going to keep our users unpatched, and won’t succeed at keeping the bug secret, so we’d like your permission to release according to the schedule we agreed to,” or is that verboten since it’s not “going along with the rest of the community”?
tech-no-logical 8y ago
as I read it, it seems openbsd's X maintainer, matthieu herrb, knew about it but didn't tell theo or the other openbsd devs. that seems strange, and not really related to early access.

deleted 8y ago

[deleted]

protomyth 8y ago

Well, it looks like they have a patch [syspatch64-001_xserver] not sure which fix they chose. [edit] a tweet for @OpenBSD said: We're currently preparing errata and a security advisory for today's Xorg issue that allows arbitrary overwriting of files as a non-root user. You can run "chmod u-s /usr/X11R6/bin/Xorg" as a temporary workaround until the fixes are out.

cperciva 8y ago

OpenBSD doesn't keep secrets. The X.org team had to keep this secret, so they couldn't tell OpenBSD. If OpenBSD starts participating in embargoes, they'll get advance notice of vulnerabilities. It's as simple as that.

deleted 8y ago
[deleted]
- deleted 8y ago
  [deleted]
tedunangst 8y ago
Come on, you know better than that.
- cperciva 8y ago
  Maybe I should have said Theo rather than OpenBSD? But seriously, look at the Lazy FPU thing -- someone leaked it to Theo, and his immediate response wasn't "gee, this sounds serious, I should work together with other vendors to make sure that we can all get this fixed"; it was "let's publicly disclose the vulnerability at the soonest opportunity". I'm not saying that he has agreed to embargoes and then broken them. I'm saying that he has made it clear that he isn't interested in acting as a productive member of the community.
  - tedunangst 8y ago
    I think you've been cut out of enough embargoes to understand the openbsd position. Embargoes hurt users. The decision to not work together on lazy FPU was made before Theo got involved. What Theo and others, including myself, have made clear is that embargoes suck, and we will complain about them as is our right, but we will attempt to honor them if that's how it going to be.
    - cperciva 8y ago

fizwhiz 8y ago

For some of us who aren't OS enthusiasts: can anyone provide an ELI5 or deeper context links?

Lazare 8y ago
There's a serious bug that impacts a number of operating systems, including OpenBSD. In order to coordinate a release, some vendors were made aware of the bug before it was publically disclosed, but OpenBSD was not one of them, probably because OpenBSD has a reputation (fairly or not) as being very anti-secrecy, not being cooperative in situations like this, and not providing other vendors advance notice of issues they find. OpenBSD is, understandably, upset that they ended up shipping a bug when they could easily have delayed the release had they been made aware of it. Whether that's a legitimate complaint, or simply their just deserts given their past behaviour, or somewhere in between is something I'm not remotely qualified to answer. In any case, if people won't trust you to follow embargoes, you'll end up shipping bugs, and angrily complaining on public mailing lists that people don't trust you won't make people start trusting you. (For one thing, notably absent from the linked post was a "we would have course adhered to the embargo if we'd been asked", which leaves the question open of whether not trusting them, in this specific case, may not have been correct. In any case, this will be resolved, if it's resolved, in private between concerned individuals.)
- owenmarshall 8y ago
  To add a wrinkle that may be missed from a quick read of Theo’s post: OpenBSD’s X maintainer is on the X.org security team - that’s the Matthieu referenced. So it’s possible that an entirely human set of mistakes occurred that lead to this happening; it’s also possible that embargoed bugs came in to play.
  - Lazare 8y ago
    Yes. Simple oversight is possible. Alternatively, if it is a trust issue, the fact that it's not just "the X.org security team doesn't trust the OpenBSD maintainer team" but "the OpenBSD X maintainer doesn't trust the rest of the OpenBSD maintainer team" adds several extra levels of politics to this, which I suspect is what Theo was alluding to with his "abdication of the duty of care" comment. I assume Matthieu acted (if that is indeed what he did) in his role as a member of the X security team, but I imagine Theo would say that in doing so he failed to act appropriately in his role as a member of the OpenBSD maintenance team. It all makes me quite interested to know what his reasoning was.

DonHopkins 8y ago

Excerpt from the "Official Dangerous Virus Notice" Distributed at the X-Windows Conference: >This is what happens when software with good intentions goes bad. It victimizes innocent users by distorting their perception of what is and what is not good software. This malignant window system must be destroyed. >Ultimately DEC and MIT must be held accountable for this heinous software crime, brought to justice, and made to pay for a software cleanup. Until DEC and MIT answer to these charges, they both should be assumed to be protecting dangerous software criminals. >Don’t be fooled! Just say no to X. >X-Windows: …A mistake carried out to perfection. X-Windows: …Dissatisfaction guaranteed. X-Windows: …Don’t get frustrated without it. X-Windows: …Even your dog won’t like it. X-Windows: …Flaky and built to stay that way. X-Windows: …Complex non-solutions to simple non-problems. X-Windows: …Flawed beyond belief. X-Windows: …Form follows malfunction. X-Windows: …Garbage at your fingertips. X-Windows: …Ignorance is our most important resource. X-Windows: …It could be worse, but it’ll take time. X-Windows: …It could happen to you. X-Windows: …Japan’s secret weapon. X-Windows: …Let it get in your way. X-Windows: …Live the nightmare. X-Windows: …More than enough rope. X-Windows: …Never had it, never will. X-Windows: …No hardware is safe. X-Windows: …Power tools for power fools. X-Windows: …Putting new limits on productivity. X-Windows: …Simplicity made complex. X-Windows: …The cutting edge of obsolescence. X-Windows: …The art of incompetence. X-Windows: …The defacto substandard. X-Windows: …The first fully modular software disaster. X-Windows: …The joke that kills. X-Windows: …The problem for your problem. X-Windows: …There’s got to be a better way. X-Windows: …Warn your friends about it. X-Windows: …You’d better sit down. X-Windows: …You’ll envy the dead. https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39...

newnewpdro 8y ago

TIL OpenBSD still installs Xorg setuid root, yikes.

bitwize 8y ago
IKR? OpenBSD should really use systemd-logind and Wayland, the way modern desktops do.
- newnewpdro 8y ago
  Or just get a drm equivalent implementation that doesn't require root privileges for the modesetting Xorg driver to function.
  - anjbe 8y ago
    OpenBSD has that, but X was still kept setuid so the non-modesetting drivers would still work. Well, since yesterday obviously: https://marc.info/?l=openbsd-cvs&m=154050453117246&w=2 https://marc.info/?l=openbsd-cvs&m=154050453117246&w=2
    - newnewpdro 8y ago
      Unnecessarily installing binaries as setuid... for how long now? So much for secure by default.

busterarm 8y ago

Responsible disclosure is a scam that puts vulnerability researchers, downstream project maintainers and users in the position of being malicious actors all while absolving those responsible from their responsibility. Immediate and public disclosure is the only responsible disclosure there is and I commend (and monetarily contribute to) the OpenBSD Project for their soft stance against embargoes. Operating in opposition to that, a large portion of the security industry plays along for reasons varying from personal pride (appealing to authority makes you feel like one of the good guys) to the extremely lucrative payouts for selling 0day to nation states. It's no surprise that the higher your profile in the industry and on twitter, the easier time you have getting paid out on bug bounties. All of this hurts users. I develop and maintain software and software infrastructure for a living. If you find a vulnerability in work I am responsible for, please rake me over the coals as publicly and loudly as you can. That motivates the PTB who fund my work to resolve the issue better than anything else.

MaxBarraclough 8y ago
I'm not convinced. Google's policy seems about right to me. When they discover a security flaw in someone else's software, they give them 90 days before making it public [0]. The choice of 90 days is to strike a balance between applying strong pressure to the company to get it fixed fast, and giving them a reasonable amount of time to get it done and rolled-out. My understanding is that this approach generally works fairly well. You'd rather that they adjust that notice period all the way down to zero, and hand vulnerabilities over to the bad guys for free right out of the gate? [0] https://arstechnica.com/information-technology/2015/02/google-updates-disclosure-policy-after-windows-os-x-zero-day-controversy/ https://arstechnica.com/information-technology/2015/02/googl...
- desdiv 8y ago
  You are assuming that the white hat security researcher was the first to discover the flaw. That is a perfectly reasonable assumption, and your position is perfectly reasonable given that assumption. GP was assuming that the white hat security researcher was not the first to discover the flaw, and that the flaw is actively being used to attack users. That is a perfectly reasonable assumption, and GP's position is perfectly reasonable given that assumption.

yitchelle 8y ago

Is it common that this type of disputes are commonly discussed in the public? I guess that by doing the type of discussion in the public, the level of accountability is a lot higher for all concern.

bubblethink 8y ago

From the RH bug report (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14665 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14665), this is described as “an incorrect permission check for -modulepath and -logfile options when starting X.Org,". Would wayland be immune to these kinds of things, or is it not relevant here ? And is OpenBSD planning to switch to wayland ?

bitwize 8y ago
This vulnerability can be mitigated if you don't run X as root. Use the modesetting driver and ensure permissions to the video device with Unix groups or a mechanism like systemd-logind. Since Wayland compositors are almost never setuid root, it isn't a problem for them.