- 1. OpenSSL Security Advisory – Heap memory corruption with RSA private key operation (CVE-2022-2274)
OpenSSL fixed a high risk bug in how it handles RSA 2048 bit private keys. It leads to a heap overflow, but is only triggered on Intel CPUs that support a specific instruction set. It's also only in the 3.0 branch. So, overall it's not all that interesting of a bug.
However, the advisory has a wonderfully aspirational sentence that, perhaps unwittingly, sums up the state of appsec: "Note that on a vulnerable machine, proper testing of OpenSSL would fail and should be noticed before deployment."
- 2. atomicwrites’ old versions have been purged from pypi
A small story that touches on a bigger picture. The Python Package Index has started requiring 2FA for all critical packages (i.e. most downloads). One package owner didn't want to bother and pulled their package -- thereby causing apps depending on it to fail to build. They righted the situation by putting the most recent version back, but announced they'd no longer be maintaining the project.
For me, this is less about 2FA and more about managing dependency graphs. Yes, all devs should have FIDO keys for their workflows related to managing and building code. But there's a quote in the package owner's last update to the repo that stands out -- “Python 3 has os.replace and os.rename, and those should probably work for most usecases this package was designed for.”
That quote speaks to the idea that maybe we have an over-reliance on packages. And that there may be many basic functions that should have first-party language support or just be implemented in a few lines of code rather than pulling in a package.
Here's one article that summarizes what happened, https://www.bleepingcomputer.com/news/security/pypi-mandates-2fa-for-critical-projects-developer-pushes-back/
- 3. Wiz offers CVE-like cloud vulnerability registry, but will it gain traction?
I usually avoid any headline that's formulated as a question since they're either vapid clickbait with an obvious answer or cynical clickbait with an obvious answer. But this question about an open source cloud vuln registry is a good one. The principle of cataloging and tracking vulns in cloud service providers makes sense. What will be interesting to watch is what audiences find it useful -- tool developers looking to market "cloudvulndb compliant" scans (to be clear, such a thing would be purely made up), DevOps teams, or AppSec teams.
There's clearly a need to know about vulns. What will be important to watch is what concrete actions those various audiences will be able to take from these.
Check out the project at https://www.cloudvulndb.org
- 4. Whitepaper – Practical Attacks on Machine Learning Systems
The paper starts off with plenty of familiar attacks that are just given an ML flavor, like serialization, credentials in code, and package dependencies. That's fine and not surprising since all code has potential for these flaws and ML is no different.
But then the paper gets into more context-specific attacks against ML. This is where the paper shines and is worth reading if you work with any data science or ML teams. While the risk associated with each attack varies since their attack scenarios require varying degrees of access and knowledge, including these attacks in your threat models will help you better reason through the security and privacy implications of products that rely on the "magic" of ML.
- 5. Apple slaps hard against ‘mercenary’ surveillance-as-a-service industry
Apple has been putting lots of engineering effort into security improvements like sandboxing components withing iMessage and Safari. This takes that a step further by purposefully disabling or changing features in order to reduce the attack surface of their devices. While Lockdown Mode won't be needed by the majority of Apple users, it will be immensely valuable to those targeted by attacks like those developed by NSO Group. Giving users the ability to enable this mode is a good step in security design.
- 6. Inside NIST’s 4 Crypto Algorithms for a Post-Quantum World
Most organizations have far higher appsec priorities than worrying about shifting to "quantum-safe" crypto algorithms. The Cloud Security Alliance has set an aspirational goal of April 2030 for orgs to support these algorithms throughout their infrastructure, which feels like a similar timeline for the migration from SHA-1 to SHA-2.
Of course, the most interesting aspects right now are the algorithm names -- in particular the CRYSTALS-Kyber (a Star Wars reference) for public-key encryption and CRYSTALS-Dilithium (a Star Trek reference) for digital signatures. No love for the blue crystals of Metebelis III apparently.
Check out NIST's announcement at https://csrc.nist.gov/News/2022/pqc-candidates-to-be-standardized-and-round-4
- 7. Ledger HW.1 & Nano Security Keycard Bypass
Yes, we're dipping into a crypto-as-in-not-the-useful-kind article, but this article combines some hardware hacking and software analysis to demonstrate a serious flaw. Researchers managed to recover access to a hardware device needed to sign transactions -- a fundamental capability necessary to this crypto.
- 8. Verify Apple devices with no installed software
We'll welcome anything that accelerates the demise of CAPTCHAs. Apple recently announced Private Attestation Tokens, which aims to decouple device integrity assertions from persistent identifiers.
Check out the proposed standard at https://www.ietf.org/archive/id/draft-ietf-privacypass-auth-scheme-01.html