RE: https://hachyderm.io/@damienmiller/117563026759098135
It's important to remember that OpenSSH is highly build-time configurable software. Only certain build configurations and system states present a real concern as an "emergent property" of this complex system.
For everyone else, it's a latent or "non-expressing" defect in source code.
@adamshostack Also Chapter 3 of Security Engineering 3rd edition covers satisficing and bounded rationality.
We miss you, #RossAnderson
@adamshostack Dr. Shaw talks about it a lot in the context of Software Engineering, e.g. her keynote at FSE this summer.
@adamshostack In https://arxiv.org/abs/2301.03593 you wrote, "we do not use any of our limited citation count for the idea of satisficing."
I have some references, but I'm curious if there are any that have been most useful for you on the subject, in particular in the context of human behaviors observed in the field in security domains.
I'm not sure claiming "everything is on fire" is the correct takeaway here
There is a pile of flammable materials we've been ignoring for decades. It catches on fire sometimes. It caught on fire a lot this week
And the people who put out the fires, for free, put the fire out again
The current plan is to just keep throwing more oily rags on the pile. We could try to help the volunteers, but that costs more than adding oily rags to the pile
Trying to figure out how to dress as an unpatched "remote, zero click, unauthenticated" (that has only been demonstrated exploitable under lab conditions) Linux kernel vulnerability for Halloween. 🎃
RE: https://xoxo.zone/@neilk/117532969677535814
To clarify, when I say open source I actually mean the original end goals of the FOSS movement, which were not any particular license or I’d argue even the source itself, but rather putting users in control of their software: the freedom to do everything from running the software without the continual permission of the creator to being able to modify/repair/expand/share that software without their creators permission as well (1/🧵)
RE: https://mastodon.social/@glyph/117503267164875706
Yet another example where applying CVSS yields the wrong signal for consumers of security vulnerability information.
IMHO the vendor severity rating (independent of any CVSS formula) should be one of the more reliable pieces of information. CVSS scores can artificially inflate severity.
CNAs that provide CVE records with CVSS scores aren't trying to do the wrong thing here. They're using the system that they've been asked to use by CISA et al.
My retirement day job is looking after the security committee at Apache Software Foundation. So if you're interested in how we're coping after going from getting 50 vuln reports a month to over 800 (yeah those extra 750 are AI) come say hi at #emfcamp (I'll mention it briefly in my Sun talk too, but the talk has nothing about vulnerabilities, security, Apache, or Heartbleed).
The #curl summer of bliss continues to be great and even greater. You realize the pressure possible 24/7 security reports exert when it is gone.
Recommended.
Big XKCD 424 energy.
https://www.explainxkcd.com/wiki/index.php/424:_Security_Holes
RE: https://abyssdomain.expert/@filippo/116781705785046708
Sometimes the response to a software defect that is discovered, fixed, and disclosed as a "security vulnerability" has a far worse effect than the defect itself.
There was never any indication that this static analysis discovered bug in OpenSSL was likely to be exploited.
In 2020, OpenSSL had a vulnerability in handling the signature_algorithms_cert extension. https://openssl-library.org/news/secadv/20200421.txt
Palo Alto apparently "solved" this in their IPS by blocking connections with "unknown" algs in signature_algorithms_cert.
Six years later, we can't add ML-DSA to signature_algorithms_cert in Go. signature_algorithms_cert is dead.
Sigh.
Thanks to @cks for diagnosing this. Sometimes it takes us months to figure out things like this.
https://github.com/golang/go/issues/79626#issuecomment-4754225610
due to the increase in vulnerabilities, we recommend upgrading your software all the time to patch all vulnerabilities, but we also recommend pinning your software to the past to avoid new vulnerabilities
"Responsible Disclosure" was the framing that proprietary software vendors used to suggest that those who disclosed details about software vulnerabilities were acting irresponsibly.
They also called it "information anarchy".
People are worried about AI killing open source, I'm more worried about some companies looking to enclose open source under the premise that AI is making it too risky.
For those who have forgotten what happens when program analysis tools flag a "bug" and then someone tries to "fix" it.
https://www.schneier.com/blog/archives/2008/05/random_number_b.html