I checked the stack overflow that was marked High, and Fil-C prevents that one.
One of the out-of-bounds writes is also definitely prevented.
It's not clear if Fil-C protects you against all of the others (Fil-C won't prevent denial of service, and that's what some of these are; Fil-C also won't help you if you accidentally didn't encrypt something, which is what another one of these bugs is about).
The one about forgetting to encrypt some bytes is marked Low Severity because it's an API that they say you're unlikely to use. Seems kinda believable but also ....... terrifying? What if someone is calling the AESNI codepath directly for reasons?
Here's the data about that one:
"Issue summary: When using the low-level OCB API directly with AES-NI or other hardware-accelerated code paths, inputs whose length is not a multiple of 16 bytes can leave the final partial block unencrypted and unauthenticated.
Impact summary: The trailing 1-15 bytes of a message may be exposed in cleartext on encryption and are not covered by the authentication tag, allowing an attacker to read or tamper with those bytes without detection."
I suspect this year we are going to see a _lot_ more of this.
While it's good these bugs are being found and closed, the problem is two fold
1) It takes time to get the patches through distribution 2) the vast majority of projects are not well equipped to handle complex security bugs in a "reasonable" time frame.
2 is a killer. There's so much abandonware out there, either as full apps/servers or libraries. These can't ever really be patched. Previously these weren't really worth spending effort on - might have a few thousand targets of questionable value.
Now you can spin up potentially thousands of exploits against thousands of long tail services. In aggregate this is millions of targets.
And even if this case didn't exist it's going to be difficult to patch systems quickly enough. Imagine an adversary that can drip feed zero days against targets.
Not really sure how this can be solved. I guess you'd hope that the good guys can do some sort of mega patch against software quicker than bad actors.
But really as the npm debacle showed the industry is not in a good place when it comes to timely secure software delivery even without millions of potential new zero days flying around.
No, the biggest problem at the root of all this is complexity. OpenSSL is a garbled mess. No matter AI or not, such software should not be the security backbone of the internet.
People writing and maintaining software need to optimize for simplicity, readibility, maintainability. Whether they use an LLM to achieve that is seconday. The humans in the loop must understand what's going on.
Let’s see them to do this on projects with a better historical track record.
history suggests otherwise
> The fact that 12 previously unknown vulnerabilities could still be found there, including issues dating back to 1998, suggests that manual review faces significant limits, even in mature, heavily audited codebases.
no, the code is simply beyond horrible to read, not to mention diabolically bad
if you've never tried it, have a go, but bring plenty of eyebleach
If someone meant to engineer a codebase to hide subtle bugs which might be remotely exploitable, leak state, behave unexpectedly at runtime, or all of the above, the code would look like this.
I wonder who could possibly be incentivized to make the cryptography package used by most of the worlds computers and communications networks full of subtly exploitable hard to find bugs. Surely everyone would want such a key piece of technology to be air tight and easy to debug
But also: surely a technology developed in a highly adversarial environment would be easy to maintain and keep understandable. You definitely would have no reason to play whackamole with random stuff as it arises
1. Tragedy of the Commons (https://en.wikipedia.org/wiki/Tragedy_of_the_commons) / Bystander Effect (https://en.wikipedia.org/wiki/Bystander_effect)
2. In practice, the risk of introducing a breakage probably makes upstream averse to refactoring for aesthetics alone; you’d need to prove that there’s a functional bug. But of course, you’re less likely to notice a functional bug if the aesthetic is so bad you can’t follow the code. And when people need a new feature, that will get shoehorned in while changing as little code as possible, because nobody fully understands why everything is there. Especially when execution speed is a potential attack vector.
So maybe shades of the trolley problem too - people would rather passively let multiple bugs exist, than be actively responsible for introducing one.
It reminds me of Google Dart, which was originally pitched as an alternate language that enabled web programming in the style Google likes (strong types etc.). There was a loud cry of scope creep from implementors and undo market influence in places like Hacker News. It was so poorly received that Google rescinded the proposal to make it a peer language to JavaScript.
Granted, the interests point in different directions for security software v.s. a mainstream platform. Still, audiences are quick to question the motives of companies that have the scale to invest in something like making a net-new security runtime.
The incentives of different parties / actors are different. 'Everyone' necessarily comprises an extremely broad category, and we should only invoke that category with care.
I could claim "Everyone" wants banks to be secure - and you would be correct to reject that claim. Note that if the actual sense of the term in that sentence is really "almost everyone, but definitely not everyone", then threat landscape is entirely different.
Except it's not. Literally nobody ever in history had their credit card number stolen because of SSL implementation issues. It's security theater.
https://youtu.be/WFMYeMNCcSY&t=1024
Teaser: "It's like throw a rock, you're gonna hit something... I pointed people in the wrong direction, and they still found a bug".
https://cryptography.io/en/latest/statements/state-of-openss...
Recently discussed: https://news.ycombinator.com/item?id=46624352
> Finally, taking an OpenSSL public API and attempting to trace the implementation to see how it is implemented has become an exercise in self-flagellation. Being able to read the source to understand how something works is important both as part of self-improvement in software engineering, but also because as sophisticated consumers there are inevitably things about how an implementation works that aren’t documented, and reading the source gives you ground truth. The number of indirect calls, optional paths, #ifdef, and other obstacles to comprehension is astounding. We cannot overstate the extent to which just reading the OpenSSL source code has become miserable — in a way that both wasn’t true previously, and isn’t true in LibreSSL, BoringSSL, or AWS-LC.
Also,
> OpenSSL’s CI is exceptionally flaky, and the OpenSSL project has grown to tolerate this flakiness, which masks serious bugs. OpenSSL 3.0.4 contained a critical buffer overflow in the RSA implementation on AVX-512-capable CPUs. This bug was actually caught by CI — but because the crash only occurred when the CI runner happened to have an AVX-512 CPU (not all did), the failures were apparently dismissed as flakiness. Three years later, the project still merges code with failing tests: the day we prepared our conference slides, five of ten recent commits had failing CI checks, and the day before we delivered the talk, every single commit had failing cross-compilation builds.
Even bugs caught by CI get ignored and end up in releases.
I remain surprised at how long people can flog horses I figured would be dead decades earlier in enterprise. Too scared to fix fundamental issues and still running off the fumes of vendor lock-in with exasperated end users.
Even with all the best practices, patterns and reviews in place software products often turns out to be held up by hacks and patches.
Add AI and inexperienced developers into the mix, the risk of fragile software increases ?
It might simply be the case that buying more tokens and kicking the code enough times might give a "good enough" result for the industry to continue. I don't want to believe this but the discussion of how awful the openssl code base is seems to suggest that might be the case. You just need to automate the process of caution we have around it. We should all be hoping that Gastown fails but I feel like it might succeed.
Given the resilience, how can the cuts have been "insanity"?
I'd love to find that sometime. Maybe it's time to ask Gemini once again to look for me.
https://medium.com/message/everything-is-broken-81e5f33a24e1
With yours as candidate #2. It's too late here now for me to read them both, but I'll try to go back and check when I have time.
- astronaut
"I don't quite know how to put this, but our entire field is bad at what we do, and if you rely on us everyone will die"
"They say they've fixed it with something called <del>blockchain</del> AI"
"Bury it in the desert. Wear gloves"
Oftentimes, I wonder if the world wouldn't be a bit better without the last 10 or 15 years of computer technology.
It's about as serious as a heart attack at this point...
(We don't know how to secure other codebases either, but C is harder since its memory safety story is like a chainsaw juggling act so code has classes of vulnerabilities that other languages don't and this eats a lot of the attention).
The methodology for developing and maintaining codebases like OpenSSL has changed!
> no, the code is simply beyond horrible to read, not to mention diabolically bad
OpenSSL? Parts of it definitely are, yes. It's better since they re-styled it. The old SSLeay code was truly truly awful.
Would be interesting to see if any of those found exist there.
Why not start from a clean slate? Companies like Google could afford it
We are still suffering from that mistake, and LibreSSL is well-maintained and easier to migrate to than it ever was.
What the hell are we waiting for?
Is nobody at Debian, Fedora or Ubuntu able to step forward and set the direction?
What’s eye bleachy about this beyond regular C/C++?
For context I’m fluent in C#/javascript/ruby and generally understand structs and pointers although not confident in writing performant code with them.
Part of OpenSSL's incomprehensibility is that it is not C++ and therefore lacks automatic memory management. Because it doesn't have built-in allocation and initialization, it is filled with BLAH_grunk_new and QVQ_hurrr_init. "new" and "init" semantics vary between modules because it's all ad hoc. Sometimes callees deallocate their arguments.
The only reason it needs module prefixes like BLAH and QVQ and DERP is that again it is not C++ and lacks namespaces. To readers, this is just visual noise. Sometimes a function has the same name with a different module, and compatible function signature, so it's possible to accidentally call the wrong one.
This sounds like a great approach. Kudos!
More evidence that "coding elegance" is irrelevant to a product's success, which bodes well for AI generated code.
The unexpected part here being that AI brings specks of elegance to a terrible, inelegant codebase.
I was part of a body which funded work to include some stuff in the code, and the way you take something like X509 and incorperate a new ASN.1 structure inside the code, to be validated against conformance requirements (so not just signing blindly over the bitstream, but understanding the ASN.1 and validating it has certain properties about what it says, like not overlapping assertions of numeric ranges encoded in it) is to invoke callouts from deep down, to perform tasks and then return state. You basically seem to have to do about a 5 layer deep callout and return. It's a massive wedding cake of dependency on itself, it personifies the xkcd diagram of "...depends on <small thing>" risks.
I'm not surprised people continue to find flaws. I would like to understand if this approach also found flaws in e.g. libsodium or other more modern crytography, or in the OpenBSD maintained libreSSL code (or whatever it is) or Peter Gutmann's code.
OpenSSL is a large target.
It's also leading people to submit hallucinations as security vulns in open source. I've had to deal with some of them.
From a marketing angle, for a startup whose product is an AI security tool, buying zero-days from black market and claiming the AI tool found them might be good ROI. After all this is making waves.
Or, could it be possible the training set contains zero-day vulnerabilities known to three-letter agencies and other threat actors but not to public?
These two are not mutually exclusive either. You could buy exploits and put them in the training set.
I would not be surprised if it is legit though.
AI discovers 12 of 12 OpenSSL zero-days (while curl cancelled its bug bounty)
https://www.lesswrong.com/posts/7aJwgbMEiKq5egQbd/ai-found-1...
Besides the HN submission, XBOW and Hacktron AI has found plenty of vulnerabilities in code.
It doesn't look like they had 1 AI run for 20 minutes and then 30 humans sift through for weeks.
Yes, we have been on the receiving end of AI generated bug reports and in the vast majority of cases they are really bad. But you still need humans to sift through them. And when you ask the submitter questions, it’s often clear that they just give the questions to an LLM again to answer.
It costs a huge amount of human manpower, so if the company who made this had an AI based solution with a far lower false-positive rate, that would be great.
It does, though, look like they were running their AI over the codebase for an extended period of time (not per run, but multiple runs over the period of a year)
> Does it matter?
Hell yes, false reports are the bane of the bug bounty industry.
I think that it would be helpful from a research point of view to know what sort of noise their AI tool is generating, but, because they appear to be trying to sell the service, they don't want you to know how many dev months you will lose chasing issues that amount to nothing.
We made good choices when we decided the information on the internet should be delivered by simple, open protocols.
We made bad choices when we decided that the information on the internet didn't need to be verified, or verifiable.
Then we slipped on our good choices, because our bad choices let robber barons claim the verified or verifiable case.
And then we were left an explosive entropy shit-pile.
But now the new tools the new overlords are paying us to use will help us break free from their shackles, bwahahahahahahahahahahahah!!!!
As for all the slop the Curl team has been putting up with, I suppose a fool with a tool is still a fool.
Better software is out there.
I like to recommend that project because it has a very transparent vulnerabilities approach, and is in my opinion written a lot more sane than OpenSSL which is somewhat not using standard C features because it always implements everything from scratch like a kernel does.
But yeah, anyways, WolfSSL comes from the embedded area in case that's your thing.
> This doesn't mean that AI can replace human expertise. The OpenSSL maintainers' deep knowledge of the codebase was essential for validating findings and developing robust fixes. But it does change the SLA of security. When autonomous discovery is paired with responsible disclosure, it collapses the time-to-remediation for the entire ecosystem.