Comments URL: https://news.ycombinator.com/item?id=49933587

Points: 33

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49824969

Points: 24

# Comments: 4

Two problems that often arise when using LLM-based vulnerability assessment methodologies for a codebase are false positives and severity inflation.

As far as I can tell, false positives occur when the underlying language model pattern-matches a snippet of code with vulnerable, risky, or error-prone samples in its training data and/or context window. (Many SKILL.md files you find on GitHub are piles of Markdown describing anti-patterns, and occasionally TOML files describing roles the agent can assume when interpreting that Markdown.) It might be gesturing towards a real problem, but in practice, the signal-to-noise ratio can be extremely low without validation steps or expert feedback.

I don't quite understand the source of the usual severity inflation observed with LLM output, but I also haven't seen the training data, so it could just be a maladaptive behavior from the source material.

Regardless, the two problems are a symptom of the same systemic flaw: Insufficient rigor.

If you decide the work is done once you have "a result", you're doing yourself and your audience a disservice. It's imperative to have explicit mechanisms to ensure that the result is: a) real, b) relevant to the threat model of the application in scope, and c) measured appropriately in terms of both severity and difficulty. If you build the right mechanisms, you solve both symptoms in one fell swoop.

The post-patch-validation skill mentioned in the blog post was created as one of several mechanisms to ensure that the final output (i.e., what humans review) is actually worth anyone's time. We have other interesting AI experiments that I plan to open-source in the coming months (or in early 2027 at the latest).

Happy to answer any questions and hear any feedback anyone has on this skill.

A security researcher's ethical obligations are to protect users over vendors (barring any contractual agreement in place). From what has been discussed in this thread, they meet that bar.

Sure, they could have gone the extra mile to ensure the distros were in a good place to patch before they published the exploit. That's a kindness you can wish for, but don't disparage them for not going that extra mile. It's a bonus.

It's also possible that it simply didn't occur to them to do so this time. There's certainly lessons to be learned either way. I don't know that the right lessons will emerge from hostility.

This includes:

1. The Ed448 signature algorithm

2. The Edwards448 elliptic curve group (which could conceivably be used for ECDH)

3. The Decaf448 prime-order group (a much better target for doing non-EdDSA things with)

I've been putting off reviewing it and making the implementation public (as it was an exercise in "is this skill a sufficient guard-rail against implementation error" more than anything), but if there's any interest in this from the Go community, I'll try to prioritize it later this year.

(I'm not publishing it without approval from the rest of the cryptography team, which requires an internal review.)

But if you're curious about the efficacy of the Skill, it did discover https://github.com/RustCrypto/signatures/security/advisories...

[1] https://github.com/trailofbits/skills

Comments URL: https://news.ycombinator.com/item?id=45970165

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41161877

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=40776309

Points: 2

# Comments: 0

1. https://archiv.infsec.ethz.ch/education/fs08/secsem/bleichen... - This is necessary to scare newbies away from implementing textbook RSA

2. https://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e0... - Vaudenay's attack on CBC mode is essential to practitioners

3. https://mega-awry.io/pdf/mega-malleable-encryption-goes-awry... - A real world attack on Mega's encryption

Unfortunately, most interesting cryptanalysis results are easier to find as blog posts than academic papers.

For example: the Frozen Heart vulnerability in zero-knowledge proof systems that rely on the weak Fiat-Shamir transform.

https://blog.trailofbits.com/2022/04/13/part-1-coordinated-d...

https://blog.trailofbits.com/2022/04/15/the-frozen-heart-vul...

https://blog.trailofbits.com/2022/04/18/the-frozen-heart-vul...

These blog posts are great, but they aren't academic papers, so they may not qualify for your list.

Comments URL: https://news.ycombinator.com/item?id=39604111

Points: 25

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=39370154

Points: 4

# Comments: 0

If you ever get the impression that I'm underestimating the complexity of a typical TLS implementation, I promise you that I'm not. I speak to improvements, not panaceas.

Until the end of last year, I was one of the security engineers that the s2n team at AWS consulted on potential security issues. You will never hear me say anything will magically fix all our problems. Especially with TLS.

However, Rust does bring a lot to the table, so I feel I'm allowed to be excited about not reviewing another X.509 library written in C.

Rust isn't just memory-safety. The type system also coaxes developers towards eliminating some types of logic bugs.

Not all, granted, but it does move the needle.

The other details covered in the blog post, however, would absolutely do something to fix denial of service attacks.

To wit: x509-limbo

This could be game-changing for a lot of open source software.

I spent years avoiding X.509 (and ASN.1, for that matter) in my designs because every time someone I trust poked it, a remotely exploitable bug fell out. Most often, it was a Denial of Service issue rather than Remote Code Execution. Moving to Rust would demonstrably improve the security of the entire Internet.

You might be tempted to ask, "What about BouncyCastle?" (or similar queries).

Sure, you're not overwriting the EIP in most Java X.509 bugs, but check the release notes for X.509 and ASN.1 mentions: https://www.bouncycastle.org/releasenotes.html

When I worked for Amazon, we disclosed a few X.509-related vulnerabilities to projects that we almost found by accident.

Aptitude with a technology certainly correlates with intelligence, but it doesn't necessarily imply above-average intelligence.

Some people attain their skills through Herculean levels of hard work, rather than reading about it once and the information just clicking because of their excellent brains. (Though, in my experience, they tend to also be less arrogant than techno-prodigies, but YMMV.)

Self-awareness is, similarly, orthogonal to intelligence (as you correctly state).

I find it interesting that an assumption of equivalence (or, at least, strong correlation) is so prevalent among tech workers and their friends.