
The X hole - bjpbakker
https://marc.info/?l=openbsd-tech&m=154050351216908&w=2
======
cperciva
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.

~~~
naner
I see this comment on every discussion regarding OpenBSD and security
vulnerability embargoes. Have they stated they won't stick to embargoes or
agreed to one and then broke it in the past?

~~~
tedunangst
Facts don't matter in the narrative zone.

~~~
GavinMcG
Without actually answering the question asked or clarifying what you're
referring to, your comment is not a good contribution.

~~~
busterarm
tedu is one of the more prolific OpenBSD contributors and has had a front-row
seat to the goings-on for a long time. If his experience is that "facts don't
matter", literally how can he provide you any kind of contribution that would
satisfy you that also doesn't contradict himself?

It's an important opinion, without any unnecessary words added.

~~~
GavinMcG
Well, _saying_ that he's one of the more prolific OpenBSD contributors and has
had a front row seat would obviously be a good start...

------
busterarm
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
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/googl...](https://arstechnica.com/information-
technology/2015/02/google-updates-disclosure-policy-after-windows-os-x-zero-
day-controversy/)

~~~
desdiv
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.

~~~
MaxBarraclough
That's still not enough. Even if bad guys are already using the exploit in the
wild, it _still_ isn't responsible to immediately make it public. If the
exploit isn't already public, that means the bad guys are treating it as
something to be traded in secret. (And of course, the only reason we're
discussing this is that the exploit is not already public.)

Instantly publishing the details of the exploit may well broaden its use by
bad actors, by reducing its market price to zero.

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

~~~
Lazare
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
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
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
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-128d39...](https://medium.com/@donhopkins/the-x-windows-
disaster-128d398ebd47)

------
krackers
Which CVE is this referencing?

~~~
jvreeland
This I assume:

[https://lists.x.org/archives/xorg-
announce/2018-October/0029...](https://lists.x.org/archives/xorg-
announce/2018-October/002927.html)

~~~
romed
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
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
The design defects of X11 do not necessitate the implementation defects of
Xorg.

------
protomyth
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._

------
newnewpdro
TIL OpenBSD still installs Xorg setuid root, yikes.

~~~
bitwize
IKR? OpenBSD should really use systemd-logind and Wayland, the way modern
desktops do.

~~~
newnewpdro
Or just get a drm equivalent implementation that doesn't require root
privileges for the modesetting Xorg driver to function.

~~~
anjbe
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
Unnecessarily installing binaries as setuid... for how long now? So much for
secure by default.

------
bubblethink
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
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.

------
yitchelle
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.

------
based2
[https://lobste.rs/s/ebmcvk/x_hole](https://lobste.rs/s/ebmcvk/x_hole)

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

~~~
wahern
Except they didn't. This has already been debunked:
[https://news.ycombinator.com/item?id=16440826](https://news.ycombinator.com/item?id=16440826)

~~~
dx87
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
> 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”?

