
Simple Bugs with Complex Exploits - based2
https://www.elttam.com/blog/simple-bugs-with-complex-exploits/
======
segfaultbuserr
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
> [ _]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
> _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
> 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
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.

