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.
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.
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.
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.
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.
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 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.
Ultimately I just care about this as an object lesson for how to handle security incidents.
we won't disclose this vulnerability because we
don't have a patch, even though we know there's an
Not admitting your software has flaws until you fix them is beyond irresponsible.
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.
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).
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.
> 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?
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.
How is this a bad thing? It is part of the base system, so it's either /bin/sh or C.
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.
#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.
How about you?
I think you'd have held your own in this discussion if you'd just signed a name to it; it didn't even have to be your name.
(You'd still be wrong about "the security community").
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. :-)
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.
> 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.
> 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.