Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vulnerability research is cooked

sockpuppet.org

Post reply on HN
Print view View original

121–130 of 181 posts

Re: Vulnerability research is cooked

#121

Post by lmm »

thadt wrote: post #96
love2read wrote: post #70

Earlier quoted context omitted.

What about this article raises this question? If anything, this article makes it pretty clear that memory safe languages are a win. It seems like a serious disadvantage to require a nondeterministic program to evaluate your code's safety.

In general I agree and suspect that memory safety is a tool that will continue to pay dividends for some time. But there are tradeoffs and more ways to write correct and 'safe' code than doing it in a "memory safe" language. If frontier models indeed are a step function in finding vulnerabilities, then they're also a step function in writing safer code. We've been able to write safety critical C code with comprehensi…

> If frontier models indeed are a step function in finding vulnerabilities, then they're also a step function in writing safer code. We've been able to write safety critical C code with comprehensive testing for a long time (with SQLite presenting a well known critique of the tradeoffs).

More like: a few people have been able to write C code where the vulnerabilities are obscure enough that we mostly don't discover them very often.

The result of the phenomenon described in the article is that the gap between 99.9% secure and 100% secure just got a whole lot wider. Using herculean amounts of testing and fuzzing to catch most of the holes in a language that lacks secure-by-construction qualities is going to be even less viable going forward.

Re: Vulnerability research is cooked

#122

Post by hrmtst93837 »

stavros wrote: post #8

I don't understand why the takeaway here is (unless I'm missing something), more or less "everything is going to get exploited all the time". If LLMs can really find a ton of vulnerabilities in my software, why would I not run them and just patch all the vulnerabilities, leading to perfectly secure software (or, at the very least, software for which LLMs can no longer find any new vulnerabilities)?

[flagged]

Re: Vulnerability research is cooked

#123

Post by saagarjha »

tptacek wrote: post #92
joatmon-snoo wrote: post #90

Earlier quoted context omitted.

Hmm: can you elaborate? I've never been on a security-specific team, but it's always seemed to me that triggering a bug is, for the median issue, easier than fixing it, and I mentally extend that to security issues. This holds especially true if the "bug" is a question about "what is the correct behavior?", where the "current behavior of the system" is some emergent / underspecified consequence of how different featu…

It has generally been the case that (1) finding and (2) reliably exploiting vulnerabilities is much more difficult than patching them. In fact, patching them is often so straightforward that you can kill whole bug subspecies just by sweeping the codebase for the same pattern once you see a bug. You'd do that just sort of as a matter of course, without necessarily even qualifying the bugs you're squashing are exploita…

In a sense, breaking a vulnerability is easier than fixing it up to be an exploit.

Re: Vulnerability research is cooked

#124

Post by saagarjha »

nickpsecurity wrote: post #103
spr-alex wrote: post #86

Earlier quoted context omitted.

I was just very naive at 18 about program analysis. I haven't lost my imagination though. I was a self-taught IOI gold division competitor. I thought every problem had an algorithm. It doesn't work like that. Program analysis is collecting special snowflakes that melt in your hand. There is no end to the ways you can write a bug in C. Ghosts of Semmle, Semgrep, Coccinelle past, be humbled. LLMs saturate test coverage…

You've never seen the full power of static analysis, dynamic analysis, and test generation. The best examples were always silo'd, academic codebases. If they were combined, and matured, the results would be amazing. I wanted to do that back when I was in INFOSEC. That doesn't even account for lightweight, formal methods. SPARK Ada, Jahob verification system with its many solvers, Design ny Contract, LLM's spitting th…

Silo’d, academic codebases are not under the kind of attacks that commodity software is

Re: Vulnerability research is cooked

#125

Post by IsTom »

spr-alex wrote: post #86
IsTom wrote: post #61

Earlier quoted context omitted.

A lot of software doing useful work halts pretty trivialy, consuming inputs and doing bounded computation on each of them. You're not going to recurse much in click handlers or keep making larger requests to handle the current one.

I was just very naive at 18 about program analysis. I haven't lost my imagination though. I was a self-taught IOI gold division competitor. I thought every problem had an algorithm. It doesn't work like that. Program analysis is collecting special snowflakes that melt in your hand. There is no end to the ways you can write a bug in C. Ghosts of Semmle, Semgrep, Coccinelle past, be humbled. LLMs saturate test coverage…

If you start with safety in mind and don't just try to bolt it on, you're in a much better place. With the kind of code you need in typical applications you could force vast majority of it in a shape that passes termination checks in theorem provers without much overhead, especially if you can just put gnarly things in standard libarary and validate (with proofs hopefully) once.

Though starting with C/C++ is a losing proposition in that regard. And I guess any kind of discipline loses to just throwing half-baked javascript at wall, because deadlines don't care about bugs.

Re: Vulnerability research is cooked

#126

Post by majewsky »

lll-o-lll wrote: post #58
batshit_beaver wrote: post #52

Earlier quoted context omitted.

You literally cannot, since ANY changes to code tend to introduce unintended (or at least not explicitly requested) new behaviors.

Eventual convergence? Assuming each defect fix has a 30% chance of introducing a new defect, we keep cycling until done?

That's assuming that each fix can only introduce at most one additional defect, which is obviously untrue.

Re: Vulnerability research is cooked

#127

Post by motbus3 »

As many are saying in the comments... I understand the point of view but if this is all true, why so many open source projects are giving up because of the staggering amount of fake/useless reports.

This is the situation where a software will be pre-patched until bloated for no particular reason... I still think this will happen, but the eventual findings of real security issues at the moment is not really proof it works. A 1/50 real Vs. false is not acceptable even if the plan is to solve with llms.

Re: Vulnerability research is cooked

#130

Post by siruwastaken »

I can't fully agree with the author's worries about the legislation question. Even if legislation were to forbid using LLMs for vulnerability reports at first, they would quickly learn their lesson and reverse the policies. Not even a politician can fight against real world results.
Post reply on HN