
FreeBSD Core statement on recent freebsd-update and related vulnerabilities - werid
https://lists.freebsd.org/pipermail/freebsd-announce/2016-August/001739.html
======
tptacek
Every part of this statement is alarming. Had the statement not been made at
all, and all I knew was that the FreeBSD update system had some
vulnerabilities, I'd be left with a higher opinion of FreeBSD.

1\. If there's a public exploit for a vulnerability, you disclose it to users,
full stop. This is obvious.

2\. If the steps you might normally take to remediate a vulnerability are
themselves exploitable, you print that in bold letters in the announcement,
full stop. "Requires active MITM" is just another way to say "requires real
attacker".

3\. You don't leave memory corruption vulnerabilities in software to preserve
backwards compatibility. It is better to break software briefly than to leave
memory corruption vulnerabilities in it.

All three of these FreeBSD statements are admissions not only of mistakes in
the announcement process, but of broken principles as well. Yikes.

~~~
ivoras
You'd be supried how few people actually work on issues such as security in
FreeBSD. Unfortunately, instead of using existing solutions to reduce their
workload, there's a lot of NIH-ism.

Like writing freebsd-update in POSIX shell, or using a home-made public key
signature format instead of PGP, or not using signatures at all for package
files, or refusing to use CDNs to deliver packages until very recently.

It's not that those things are inherently bad, it's that the bus factor ("what
stops working when a developer is hit by a bus - or goes on a vacation") is
very, very high.

~~~
tptacek
Vulnerabilities don't bother me! All code has vulnerabilities. Meanwhile, the
opportunity to use code built around a different (BSD-like) mindset is why
you'd use FreeBSD instead of Linux in the first place.

What freaks me out is simple problems of principle, like, "we won't disclose
this vulnerability because we don't have a patch, even though we know there's
an exploit available". Even if the exploit wasn't public, as long as you know
it's out there, people need to know about it!

~~~
loeg
Did you miss the directly following sentence?

> We are reviewing this policy for cases where a proof-of-concept or working
> exploit is already public.

The existing policy is flawed and they intend to fix it. It just hadn't been a
problem before now.

~~~
tptacek
No, it was that sentence that moved me to comment! They're "reviewing this
policy"? They were bound by the policy in this case? That's crazy. There's an
exploit. They didn't write it. Nobody should have to wonder if they're going
to disclose.

Ultimately I just care about this as an object lesson for how to handle
security incidents.

------
y0ghur7_xxx
"The Security Advisory did not contain information on the theoretical
implications of the vulnerability. A more explicit paragraph in the 'Impact'
statement may have been warranted."

I may be overreacting on this, but this sounds like "you who found bugs in our
code: document them better next time". I think the reporter does not owe
freebsd anything. If someone owes someone else something, freebsd developers
should thank the reporter for finding those vulnerabilities, and not ask for
even more of him.

~~~
g_p
I read it to mean something different; I think the advisory being referred to
is the FreeBSD advisory they wrote themselves [1]. The impact statement said:

> An attacker who can control the patch file can cause a crash or run
> arbitrary code under the credentials of the user who runs bspatch, in many
> cases, root.

I suspect this is where they feel that in future they would perhaps have been
better to mention the implication of this, given bspatch is used in the update
process users will run in response to the advisory.

[1] [https://www.freebsd.org/security/advisories/FreeBSD-
SA-16%3A...](https://www.freebsd.org/security/advisories/FreeBSD-
SA-16%3A25.bspatch.asc)

