Sustainable Funding of Open Source Tools – Mark Curphey, Simon Bennetts – ASW #282

The thrust of the article is that companies should invest time or money into the open source projects they consume. That's neither a new topic nor a new concern. It's just that security events like the XZ Utils backdoor, Log4Shell, and Heartbleed bring renewed interest in it. A positive outcome of Heartbleed was the emergence of alternatives to OpenSSL in addition to OpenSSL itself getting an overhaul. Log4Shell brought attention to the low investment in log4j despite its popularity.

The Heartbleed and OpenSSL situation also highlighted the aspect of which projects to invest in vs. launching new ones. Would it have been better for the impacted Linux distros to have chosen an alternative like zstd -- or does the proximity to corporate influence and governance not sit as well with open source? And, of course, there's also the aspect of minimizing dependencies altogether, such as the sudo-rs example we covered a few weeks ago. In other words, these are as much social and economic problems as they are technical ones.

p.s. this CISA article also links to a tabletop exercise about a flaw in open source being exploited and a fix expected to take a month to develop and deploy -- it's a good scenario for considering how you'd handle events like these.

A very quick way to highlight the problem is that PuTTY relied on a 512-bit mechanism to generate key material for a 521-bit key -- thereby leaving nine bits of zeros that could enable key recovery.

For me, this is one of those articles that's appealing because of how the flaw came about. At that turn of the century (lol I've wanted to use that phrase within appsec for a while), Windows didn't have a cryptographically-secure pseudo-random number generator for PuTTY to use. So the project avoided relying on random numbers altogether and used a deterministic method that -- at the time -- provided equivalent security properties.

That technique even became an RFC. However, when RFC 6979 came around in 2013, PuTTY had been content with doing things its own way for the past decade and neglected to update their method to match the RFC. Thus, they missed the nuance of the 521-bit key size mismatch. The app's threat model didn't exactly change, but the its design ever-so-slightly did.

Read the post from PuTTY's maintainer for more of that background context.

Microsoft's Azure got a CVE with a CVSS of 8.6 for a leaky CLI last year. This year AWS and Google Cloud join the team.

But what stands out to me is the distinction between a high CVSS score that represents a worst-case scenario and what feels like a quite reasonable response and explanation from AWS and Google that boils down to "expected behavior".

The takeaway is really that this scenario shouldn't happen in modern cloud development. As both CSPs point out, CLI tools (along with everything else) should be using a secrets manager for working with credentials. Environment variables aren't necessary, have been known to be insecure, and have easy to use alternatives.

This article nicely walks through some aspects of a paper whose headline could far too easily seed hyperbole and over-excitement about LLMs and infosec. (To be clear, a lot of breathless excitement about LLMs figuring out novel exploits for new vulns happens independently of this paper.)

This is more about emphasizing that LLMs have utility in helping users and bridging different contexts in things like the textual description of a flaw and code that could exploit it. As a very fancy (and impressive!) autocomplete, LLMs have shown value as assistants. They just haven't yet shown emergent capabilities like exploiting vulns they're never seen before.

(Such emergence -- or lack thereof -- has been examined in several areas.)

p.s. While I thoroughly appreciate the clear, direct title of the article, I probably would have gone with something like, "Do LLMs dream of exploited heap?"

I wanted to take two different routes with this article about security and framing.

On the security side, this seems positive, but part of me still questions the aspect of paying for security features -- especially when phrased like "better malware scanning". I can understand the economics of deeper analysis requiring more CPU and more memory if that's offloaded from the client. Even so, seeing the list of features feels like it's veering towards something like an sso.tax.

The framing side is a pure thought experiment in how the community or media would react if this were Microsoft announcing paid security features, especially with the recent CSRB report admonishing them for effectively not taking security seriously. Not sure this is a useful thought experiment or even what the experiment's underlying hypothesis is -- I suppose we'll figure that out on the show!

Besides the irony of a vulnerability in a security feature on a Cisco switch, I found this interesting to remind ourselves what a security announcement from a mature company/process looks like. Years ago, Cisco's announcements left network engineers scurrying to try and figure out if an issue affected them - now the announcements lay out fairly clearly how to tell if you're affected.

Brian Krebs has a piece up discussing an issue on an app from Chirp Systems. Chirp sells software for landlords to manage physical access to their apartment buildings and units ("Curb to Couch Access Control"). As part of this, there's an app that tenants use to control the smart locks on their units.

Well, it sounds like the Chirp app is storing the credentials for the locks in plaintext. And doing the tacky thing of not just admitting and fixing the issue.

Don't be like Chrip.

Flatpak - one of the latest packaging systems for Linux distributions - uses "sandboxing" (they seem to want to avoid saying "containers") in an attempt to keep apps secure and organized on the OS. Alas...

A condition was discovered where passing certain arguments (such as "--bind") into APIs to run commands in the background, the arguments are incorrectly parsed/escaped and a malicious app could then run a command outside the sandbox.

To me...just reading the advisory gives me that sense of "this is more complicated than it needs to be," which is what I think about flatpak in general. Unfortunately from a security POV, when you overcomplicate things, we end up talking about them...