Security Leftovers
-
Why being able to partially distrust a Certificate Authority is good
One of the arguments I've heard against supporting partial distrust of Certificate Authorities in places like Linux root certificate stores (which you currently can't really do) is that a bad CA can simply backdate TLS certificates to get around things like 'certificates issued from December 1st 2022 onward won't be trusted'. On the one hand, this is technically true (although these days either such a TLS certificate wouldn't be usable in the majority of web browsers or it would soon be detected through Certificate Transparency logs). On the other hand, there are a collection of reasons to think that it's a good thing that browser can do this sort of thing (and thus that more software should support it).
The original view of CA trust was that it was binary; either the CA was working perfectly fine and would in the future, or the CA was entirely bad and compromised, and should be distrusted immediately. While there have been some CA incidents like this, such as the DigiNotar compromise, in practice a significant number of the CA problems that have come up over the years have been less clear cut than this, such as the WoSign case (and the WoSign case was exceptionally bad in that WoSign actively issued bad TLS certificates). The recent case of TrustCor is illustrative; as far as was reported to Mozilla (and summarized by them), TrustCor never mis-issued any TLS certificates or committed any other clear violations of CA requirements. They were merely sketchy.
-
SBOM: An Up-Close Look at a Software Bill of Materials [Ed: 12 months later they still use Log4j for FUD; Microsoft et al took over the messaging of the 'Linux' Foundation]
Unless you’ve been living under a rock the past few years, you’ve likely at least heard of Log4j. This is an Apache open source library that’s commonly used in just about everything Java-related online. Unfortunately, in late 2021 the logging package was discovered to be critically vulnerable to remote code execution attacks, meaning an attacker could exploit it to install malware (e.g., ransomware) onto vulnerable systems and inject larger networks.
-
Hard to crack hardware | KAUST Discovery
Next-generation electronic devices could feature enhanced security systems built directly into their circuitry to help fend off malicious attacks. Protective “logic locks” — based on an advanced branch of electronics called spintronics — could be incorporated into the integrated circuits of electronic chips to defend chip security, KAUST researchers have shown.
“The need for hardware-based security features reflects the globalized nature of modern electronics manufacture,” explains Yehia Massoud from KAUST. Electronics companies usually employ large specialized, external foundries to produce their chips, which minimizes costs but introduces potential vulnerabilities to the supply chain. The circuit design could simply be illegally copied by an untrusted foundry for counterfeit chip production or could be maliciously modified by the incorporation of “hardware Trojans” into the circuitry that detrimentally affects its behavior in some way.
-
That grumpy BSD guy: Harvesting the Noise While it's Fresh, Revisited
Returning readers will be almost painfully aware that here at nxdomain.no (also known as bsdly.net) we host and maintain a blocklist, which in turn is the product of traffic that hits our mail system with attempts at delivery to one or more of the now more than three hundred thousand known bad addresses, also featured at the blocklist home page.
-
Episode 353 – Jill Moné-Corallo on GitHub’s bug bounty program [Ed: What a disgrace that they have Microsoft, NSA's back doors facilitator, there on the show to talk about "security"]
Josh and Kurt talk to Jill Moné-Corallo about GitHub’s bug bounty and product security team. It’s a treat to discuss bug bounties with someone who is managing a very large bug bounty for one of the most important web sites in the world of software today.