- [CramHacks] Newsletter #5: cURL & HTTP/2.0 Vulnerabilities
[CramHacks] Newsletter #5: cURL & HTTP/2.0 Vulnerabilities
CramHacks Chronicles: Key Insights On Software Supply Chain Risks
🥳 Happy Monday! 🥳
I bought a new surfboard! 🏄♂️ Sadly I don’t feel like my skills do it justice, but she’s beautiful and I’m getting better each day 🙂.
It’s fascinating to assess what makes you happy. What I’ve come to recognize is that what I enjoy most is learning. I somewhat strangely get very excited doing things I’m bad at; especially when those tasks have a steep learning curve.
Heading to Florida next week and am excited for some great food!
Software Supply Chain Security
Last week, I mentioned that Daniel Stenberg, Founder & Lead Developer of cURL, pre-announced a security vulnerability and stated that details would be released on October 11th, 2023. Well, last night (October 10th) I was surprised to see the patch for this security issue (CVE-2023-38545) on GitLab.
“Prior to this change the state machine attempted to change the remote resolve to a local resolve if the hostname was longer than 255 characters. Unfortunately that did not work as intended and caused a security issue.”
The official advisory has since been released and I’m relieved. Yes, a heap overflow vulnerability is not ideal, but based on my current understanding, RCE exploitation is very unlikely if at all possible. The de-anonymization piece is something some of you might care deeply about, but I don’t tend to fall into that category 😅.
In short, a client can open a large number of streams simultaneously followed by immediately canceling each request. Because the protocol allows for immediate cancellation of streams, additional requests can be made - causing for an indefinite number of requests at any given point in time. The is problematic because the server still has to do a significant amount of work for each canceled request.
CycloneDX fails horribly to bash penetration tests by suggesting an SBOM “saved the day”.
🌶️ This is a load of 💩. A penetration test and a SBOM have two very different objectives. Besides that (major) distinction, the penetration test apparently included an SBOM - but was manually discovered to be inaccurate - quite literally proving SBOMs are not the saving grace. SBOMs do have their place for sure, but this isn’t it.
Most notably, the application under review was from a “Cloud Data Provider, Inc.” hosted on AWS cloud. As Tom Alrich, Leader of OWASP SBOM Forum project, points out in the comments section - “The big problem with SBOMs for SaaS is that the cloud code isn't versioned (in a public way, anyway), and can undergo changes at any time. So the SBOM you get now will be out of date in 10 minutes.”
Legit Security’s Noam Dotan presents a new class of software supply chain vulnerabilities leveraging artifact poisoning. The attack targets GitHub Actions and involves replacing the content of a legitimate artifact with a malicious one; enabling a malicious actor execute code in a development pipeline.
Francis Odum, author of the software analyst blog, and Clint Gibler, the creator of tl;dr sec, published Part 2 of their supply chain security report. This part mentions over 20 supply chain security vendors covering a variety of solutions including; securing source code access, CI/CD pipelines, SCA, malicious dependencies, container security, SBOMs, code provenance, and more.
Paolo Mainardi does a beautiful job explaining exactly what the title suggests. 👋 I strongly suggest giving it a read, especially if you are curious of open source community efforts to combat these risks.
While not a new project, the official project page was recently released. Led by Tom Alrich, Tony Turner, Jeff Williams, the SBOM Forum thus far has been collaborating with NIST and ENISA on software identification and vulnerability database improvements, and developing playbooks for CSAF VEX and CycloneDX VEX document usage.
The forum meets every Friday @ 1:00 PM ET for a general meeting, open to all, to identify and try to find solutions to problems that are preventing widespread distribution and use of SBOMs by private and public organizations.
Roughly 6 hours of uploaded content shared from openSSF Day Europe 2023.
The Turbot team presents 7 lessons learned from managing 200+ open-source repositories. Most felt like no-brainers, but I was surprised about “Lesson 1: Respond instantly”
“When a community member opens a new issue, or raises a PR, we use a GitHub action that runs a Steampipe query every hour and notifies a Slack channel when something new turns up. When we scan all the repos we filter out members of our own organization so we can prioritize external contributors.”
I’d hate to be in one of these slack channels 😂 - but also, prioritizing external contributors is interesting. I can see this being a double-edged sword - in one case, you are likely to gain loyalty from the external contributor, but at the cost of devaluing your internal staff who (I would hope) are capable of prioritizing issues based on severity and something like the Eisenhower Matrix.
Georgia Tech’s Brendan Saltaformaggio is leading a $10M DARPA-funded effort to update critical defense software; but not how you’re probably thinking. 👋 I love the idea of deleting code being equally as valuable as adding code. Through the aforementioned “distillation” technique, testing has resulted in code base reduction upwards of 60% in less than 3 hours.
“Cryptographic protocol helps secure the open source software ecosystem with zero-trust passwordless authentication.”
👋 The details are outside of my realm of expertise, but I’ve seen a good bit of controversy due to OpenPubKey competing with Sigstore. That said, Dan Lorenc, Founder & CEO of Chainguard, published a beautifully written comparison.
Until Next Time! 👋
Hey, you made it to the bottom – thanks for sticking around!
Questions, ideas, or just want to chat? Slide into my inbox! 💌
If you think someone could benefit from this, don’t hesitate to forward.
See you next Monday!