6 ms·

FreeBSD Core statement on recent freebsd-update and related vulnerabilities

128 points by werid 10y ago

y0ghur7_xxx 10y ago
"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 10y ago
  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%3A25.bspatch.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-16%3A...
- Tomte 10y ago
  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.
- stonogo 10y ago
  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.
- schwarze_pest 10y ago
  Aehm, what are you talking about? Maybe you should read the mail again.
tptacek 10y ago
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 10y ago
  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 10y ago
    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!
    - valarauca1 10y ago
      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.

128 points by werid 10y ago

"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 10y ago
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%3A25.bspatch.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-16%3A...
Tomte 10y ago
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.
stonogo 10y ago
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.
schwarze_pest 10y ago
Aehm, what are you talking about? Maybe you should read the mail again.

tptacek 10y ago

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 10y ago
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 10y ago
  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!
  - valarauca1 10y ago
    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.