FreeBSD Core statement on recent freebsd-update and related vulnerabilities | Hacker News Reader

FreeBSD Core statement on recent freebsd-update and related vulnerabilities

lists.freebsd.org

128 pointswerid35 comments

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.

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.

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!

       we won't disclose this vulnerability because we 
       don't have a patch, even though we know there's an
       exploit available.

This is some 1984 shit. It's a horrible policy. While yes it'll make it easier for bad actors to write exploits, it'll also allow for sys-admins to possibly mitigate those exploits, or add extra logging to make it easier to catch exploits.

Not admitting your software has flaws until you fix them is beyond irresponsible.

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.

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.

a home-made public key signature format instead of PGP

How is 'openssl rsautl -sign' a "home-made" signature format?

As for using GPG... given its security track record, that's one of the last things I'd want to consider using for verifying signatures on binary updates.

or not using signatures at all for package files

The pkg repository is signed.

>> a home-made public key signature format instead of PGP

> How is 'openssl rsautl -sign' a "home-made" signature format?

It's RAW RSA DATA. You could argue it's more pure that way but if that were the case, noone would ask for more metadata-rich signatures.

> As for using GPG... given its security track record, that's one of the last things I'd want to consider using for verifying signatures on binary updates.

If you don't see the NIH-ism in that sentence, then I'm sorry, neither I nor nobody else can help you.

> The pkg repository is signed.

Can individual package files be verified off-line?

Is it not possible for cperciva's assessment of GPG to be accurate regardless of where it was invented?

Whether code is crap is a completely separate question from where it was invented.

Putting signatures onto the individual package files could expose users to mismatch attacks, and would also make it harder to defend against build-trojan theft of signing keys.

I think Colin has the better argument here. You were hyperbolic when you called rsautl a "home-made format".

Packages are not meant to be distributed ad-hoc. You're meant to host a repo and sign it.

I find it amusing that the line before your statement of distrust around GPG refers to using that bastion of solid, dependable crypto code that ships with OpenSSL.

OpenSSL's crypto code isn't all that bad as long as you're not worried about side channel attacks. Most of their remote code execution bugs have been in protocol code.

> OpenSSL's crypto code isn't all that bad as long as you're not worried about side channel attacks.

I consider "horrible API that makes it basically impossible to write safe code" to be a security vulnerability. Not to mention that OpenSSL's example code actually had security vulnerabilities (they didn't check the return value from one of the IV routines, whish means that you could end up using a shorter key than you expected).

That was pretty funny. Gets better with the Snowden slides where mighty NSA basically says they can't break it in basic, use case. At Princeton, Snowden even said analysts got failure notices even for requests to decrypt GPG w/ 1,024-bit RSA at a time when paranoids wondered how long 4,096-bit might last. Haha.

Next I'm going to hear that using TAIL's increases your risk of damning evidence found during a disk audit by a forensics team.

> Like writing freebsd-update in POSIX shell

How is this a bad thing? It is part of the base system, so it's either /bin/sh or C.

The packages don't need signing! The repo database is signed and the package checksums are inside. If the checksum doesn't match, the package is refused to be installed. This is vastly simpler than signing every package.

Maybe cperciva can comment directly on this, but regarding #3, my reading of the statement on bspatch is that Colin is worried a compatibility breaking kludge now may prevent patching of the permanent fix when it is released, not just any ol' functionality.

I think there's two separate questions being conflated here. There's a bspatch patch circulating which makes changes which don't seem to be security-relevant; there's a libarchive patch circulating which removes widely-used functionality in tar.

for #1, doesn't OpenBSD have the same policy?

#2 is one point, but for #3, I would agree that a temporary patch to your patching utility that would make it difficult to apply the permanant patch should be approached cautiously.

Regarding OpenBSD. No. When shit hit the fan we gave out a heads up.

https://marc.info/?l=openbsd-misc&m=145278077920530&w=2

http://undeadly.org/cgi?action=article&sid=20160114142733

Huh. I thought I recalled OpenSSH, part of the same project, saying that they wouldn't release an advisory until there was a patch. Oh well.

I'm not part of the FreeBSD Security Team any more (I stepped down as Security Officer a few years ago because I was no longer able to find time to do both that and Tarsnap, and last year I left the security team entirely when the team was pruned of its not-recently-active members), but some comments based on my experience:

1. If there's an exploit circulating "in the wild" then yes, obviously, an issue should be publicly disclosed. (I did this with an rtld bug in December 2009, circulating a "quick patch" about 48 hours before we had the advisory and binary updates available.) The only exploit I've seen circulating recently was for the issue fixed in FreeBSD-SA-16:25.bspatch.

2. The boilerplate updating instructions in FreeBSD-SA-16:25.bspatch should have been amended to remove the use of bspatch. Unfortunately I didn't see the advisory text until it went out. (For reference: Adding ": > /usr/bin/bspatch" before running freebsd-update would solve this; freebsd-update would fall back to downloading complete files rather than using patches, and one of those files would be the corrected bspatch binary.)

3. I'm sure it was never the intention to leave vulnerabilities unfixed. But we've also learned to be cautious about adopting patches which are "thrown over the wall" at us; one source in particular had roughly equal odds of "doesn't fix the vulnerability", "fixes the vulnerability", "fixes the vulnerability but breaks functionality", and "introduces a new vulnerability which is worse than the one being fixed". So the approach was normally (and I assume still is) to look through a patch and ask "what does this change fix?" and take the changes which we can identify a purpose for.

> For reference: Adding ": > /usr/bin/bspatch" before running freebsd-update [...]

In case people were wondering what that line is doing, ":" is basically the same as "true". Perhaps "truncate -s 0 /usr/bin/bspatch" would be clearer.

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

I know nothing about FreeBSD updates. But my reading was that there is a concern that a misguided patch could break the update process itself, leaving a lot of systems unable to fix themselves. Updating the code that distributes updates is risky.

> Every part of this statement is alarming.

The document itself is creepy as fuck. Have you seen the bspatch exploit and its comments? I've dabbled with iOS multimedia, and I know browser/JIT exploits get pretty complex, but this really takes the fucking piss. The unknown authorship and the fact that someone probably spent weeks to detonate a nuclear device against the software equivalent of a tree house in full seriousness and with no sense of absurdity is chilling.

Besides that, how many exploit coders in the public sphere even bother with FBSD nowadays? It just doesn't attract much interest from them, with everybody doing Windows, Mac, Linux, and mobile. Yet to someone this mattered a great deal. The jemalloc stuff could be skill-transferred from Firefox exploitation, though the exploit delves into compression routines and stdio internals as well.

Pit that against the "everybody calm down" complacency of the average Linux developer/fanboy, and you know they don't stand a chance. I haven't looked at Linux package managers in detail, but I can see them getting completely ass-raped at the "non-cryptanalytic" level in all their bloat.

Fact is, the open-source community is simply not paranoid enough to defend against nation-state talent.

And no offense to the FBSD secteam--I've doubtless made many more coding blunders than all of them put together--but I couldn't help but laugh at this:

"After discussion with the author of bspatch (Colin Percival, a former FreeBSD Security Officer himself"

It's a completely unnecessary detail, seemingly added for reasons of pride, but having the opposite effect from that intended, with no sense of irony. :-)

Agreed on all points I think, the silence on -security has been a bit harrowing. Rightly or wrongly, it felt like the project was dead to me seeing the lack of response (and some perhaps hyperbolic posts not rebutted or even responded to).

I feel like all FreeBSD needs is some understanding about what a nice system it is (despite some warts). Security though, as a volunteer arrangement, that must be tough. It's like an arms race keeping up with the blackhats, and doing that for free can't be fun.

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

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

The Security Advisory was written by FreeBSD. They are saying that they could have been more explicit in explaining to their users what the vulnerability means.

You are undoubtedly overreacting. They are talking about their own announcement, not the initial disclosure. This is 'Impact' statement from the Security Advisory in question:

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

Their criticism is of their own work, not of the researcher.

Reply on news.ycombinator.com