4 ms·

Simple Bugs with Complex Exploits

56 points by based2 6y ago

segfaultbuserr 6y ago
It's always desirable to apply all security updates regardless of the official rating. Many security issues initially thought to be "just denial-of-service bugs" have been discovered to be exploitable and dangerous in non-obvious ways, it has occurred many times in many different programs. DoS bugs are also famously used intentionally as a camouflage to hide deeper security problems before the embargo expires. Of course it's not always practical on production systems, but always desirable.
- a1369209993 6y ago
  > []always[] desirable Nitpick: this not true[0] because some updates include or depend on secrity regressions either embedded in or misrepresented as[1] new features. Strongly agree with the actual point that there's no reason to dismiss a security bug as unimportant just because (you think that) it's impossible or impractical to exploit. 0: at least of "security" "updates" in the sense of "discrete packets of data that move a program from one nominal version to another nominal version" "which fix security bugs and are described as such by relevant metadata" contrarespectively 1: the classic example being "We added support for javascript! Now any website you visit can remotely execute code on your computer!", but most cases are more subtle
  - segfaultbuserr 6y ago
    > Nitpick: this not true[0] because some updates I specifically mentioned "security updates", not just any updates. For reasonable software that maintains a stable/ESR branch in the form of x.y.z, the .z updates are always bugfixes and security patches, no vendor-forced new feature. > secrity regressions either embedded in or misrepresented as new features. If you have this problem, then you've got a bigger trouble to solve... Unfortunately sometimes users have no control over it in many software.
    - a1369209993 6y ago
      > the .z updates are always bugfixes and security patches Fair; I was talking about those updates that are required in order to fix known vulnerabilities. > If you have this problem, then you've got a bigger trouble to solve... Unfortunately sometimes users have no control over it in many software. "Regressions" is probably the wrong word[0], but new features by definition have new bugs in them (they're code that wasn't there before, so the bugs in that code weren't there before); the problem is that some security fixes for the pre-feature-X version aren't available without adding the new bugs introduced in feature-X code. 0: I was aiming for the opposite of update in the sense of adding bugs rather than removing them.
TwoBit 6y ago
The bug was due to missing a max length check. Maybe the developer and code reviewer(s) were unaware that there was a max length? No amount of coding diligence could save you if there are requirements you don't know. Granted, length limits are a common requirement and maybe they should have known.

56 points by based2 6y ago

It's always desirable to apply all security updates regardless of the official rating. Many security issues initially thought to be "just denial-of-service bugs" have been discovered to be exploitable and dangerous in non-obvious ways, it has occurred many times in many different programs. DoS bugs are also famously used intentionally as a camouflage to hide deeper security problems before the embargo expires. Of course it's not always practical on production systems, but always desirable.

a1369209993 6y ago
> []always[] desirable Nitpick: this not true[0] because some updates include or depend on secrity regressions either embedded in or misrepresented as[1] new features. Strongly agree with the actual point that there's no reason to dismiss a security bug as unimportant just because (you think that) it's impossible or impractical to exploit. 0: at least of "security" "updates" in the sense of "discrete packets of data that move a program from one nominal version to another nominal version" "which fix security bugs and are described as such by relevant metadata" contrarespectively 1: the classic example being "We added support for javascript! Now any website you visit can remotely execute code on your computer!", but most cases are more subtle
- segfaultbuserr 6y ago
  > Nitpick: this not true[0] because some updates I specifically mentioned "security updates", not just any updates. For reasonable software that maintains a stable/ESR branch in the form of x.y.z, the .z updates are always bugfixes and security patches, no vendor-forced new feature. > secrity regressions either embedded in or misrepresented as new features. If you have this problem, then you've got a bigger trouble to solve... Unfortunately sometimes users have no control over it in many software.
  - a1369209993 6y ago
    > the .z updates are always bugfixes and security patches Fair; I was talking about those updates that are required in order to fix known vulnerabilities. > If you have this problem, then you've got a bigger trouble to solve... Unfortunately sometimes users have no control over it in many software. "Regressions" is probably the wrong word[0], but new features by definition have new bugs in them (they're code that wasn't there before, so the bugs in that code weren't there before); the problem is that some security fixes for the pre-feature-X version aren't available without adding the new bugs introduced in feature-X code. 0: I was aiming for the opposite of update in the sense of adding bugs rather than removing them.

TwoBit 6y ago

The bug was due to missing a max length check. Maybe the developer and code reviewer(s) were unaware that there was a max length? No amount of coding diligence could save you if there are requirements you don't know. Granted, length limits are a common requirement and maybe they should have known.