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.

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

This sounds like a great approach. Kudos!

Better software is out there.

More evidence that "coding elegance" is irrelevant to a product's success, which bodes well for AI generated code.

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.

So again this is not reproducible and everything is hidden behind an SaaS platform. That is apparently the future people want.

> 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.

AI discovers 12 of 12 OpenSSL zero-days (while curl cancelled its bug bounty)

https://www.lesswrong.com/posts/7aJwgbMEiKq5egQbd/ai-found-1...

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.

Without Humans, AI does nothing. Currently, at least.

OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing

https://news.ycombinator.com/item?id=46782662

As for all the slop the Curl team has been putting up with, I suppose a fool with a tool is still a fool.

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!!!!