Security impact ratings considered harmful · HackerPapers discussions

Security impact ratings considered harmful — mentioned by geofft

Wed, 16 Dec 2020 20:08:53 GMT

Debian eLTS offers 7 years: https://wiki.debian.org/LTS/Extended That said, if you're really in the position of depending on a free project for over five years of security support, you probably will be totally fine with just ignoring the fact it's out of support. Just keep running Debian 6 for a decade, whatever. The code still runs. Pretend you've patched. Sure, there are probably some vulnerabilities, but you haven't actually looked to see if the project you're actually using right now has patched all the known vulnerabilities, have you? (Spoiler, it hasn't: https://arxiv.org/abs/0904.4058)

Paper and discussion history. A mention is not an endorsement.

Security impact ratings considered harmful — mentioned by geofft

Sun, 08 Sep 2019 12:19:19 GMT

In 2009 some classmates and I wrote a paper called "Security Impact Ratings Considered Harmful": https://arxiv.org/pdf/0904.4058.pdf The position is that using CVSS to decide which updates to take is a losing gamble. You don't have a good idea in advance of how easily something is exploitable, and trusting the CVSS scorers to say "oh, this particular out-of-bounds write causes a crash but isn't exploitable to run arbitrary code" is misplaced: they're not exploit developers and they're not spending time trying to build an exploit chain. If you have a process for doing software updates, do them…

Paper and discussion history. A mention is not an endorsement.

Security impact ratings considered harmful — mentioned by geofft

Thu, 23 May 2019 12:23:47 GMT

> As a security engineer, I like having a core team and a standard library in place that has gone through a long mature process with experienced developers, instead of someone who just git pushes code every night. This is an appealing sentiment, but you will get hacked if you rely on it. Python 2's standard library didn't do SSL certificate verification by default until the fairly controversial PEP 476 from late 2014, which changed the default in a point release of Python 2.7. Through 2014 (and for some time later, given how slow it is to get new upstream releases through distros onto…

Paper and discussion history. A mention is not an endorsement.

Security impact ratings considered harmful — mentioned by geofft

Tue, 07 May 2019 16:02:52 GMT

It doesn't generate more secure code—as you say, patches themselves may have bugs, and way fewer people are looking at the patched branches. Active development happens on HEAD, and dodgy code is often rewritten before anyone goes actually looking for bugs (security or otherwise). Many years ago I helped with a paper on how the practice of applying only "important" security bug fixes doesn't work: https://arxiv.org/abs/0904.4058 But the goal of the long-term-stable approach isn't security or stability per se: it's striking a tradeoff between operator work and risks to security and stability.…

Paper and discussion history. A mention is not an endorsement.