101–110 of 164 posts
What's the saying? Given many eyes, all bugs are shallow? Well, here are some more eyes.
> I don't know how long this pace will last. I suspect that bugs are reported faster than they are written, so we could in fact be purging a long backlog Hopefully these same tools will also help catch security bugs at the point they're written. Maybe one day we'll reach a point where the discovery of new, live vulnerabilities is extremely rare?
Earlier quoted context omitted.
> Can linters find these? Perhaps fuzzing? That's what syzbot / syzkaller does, as mentioned in the article, with somewhat similar results to the AI-fuzzing that they've been experiencing recently. The issue that Linux maintainers have in general is that there are so many of these "strict correctness and safety" bugs in the Linux codebase that they can't fix them all at once, and they have no good mechanism to triage…
It's a bigger deal than that. Academically, syzkaller is just a very well orchestrated fuzzer, producing random pathological inputs to system calls, detecting crashes, and then producing reproductions. Syzkaller doesn't "know" what it's found, and a substantial fraction of what it finds are "just" crashers that won't ever be weaponizable. An LLM agent finding vulnerabilities is an implicit search process over a corpu…
Modern LLMs are _exceptionally_ good at developing X-marks-the-spot vulnerabilities into working software; I fed an old RSA validation mistake in an ECU to someone in a GitHub comment the other day and they had Claude build them a working firmware reflashing tool within a matter of hours.
I think that the market for "using LLMs to triage bug-report inputs by asking it to produce working PoCs" is incredibly under-leveraged so far and if I were more entrepreneurial-minded at this junction I would even consider a company in this space. I'm a little surprised that both this article and most of the discussion under it hasn't gone that direction yet.
>software that used to follow the "release-then-go-back-to-cave" model will have to change to start dealing with maintenance for real, or to just stop being proposed to the world as the ultimate-tool-for-this-and-that because every piece of software becomes a target. Actually, some software are running the water-heater/heat-pump system in my basement. There is a small blue light screen, it keeps logs of consumed elec…
Definitely a different mindset/toolset is required when it comes to building systems that have to be working autonomously without "quick fixes" from the web.
Earlier quoted context omitted.
It's a bigger deal than that. Academically, syzkaller is just a very well orchestrated fuzzer, producing random pathological inputs to system calls, detecting crashes, and then producing reproductions. Syzkaller doesn't "know" what it's found, and a substantial fraction of what it finds are "just" crashers that won't ever be weaponizable. An LLM agent finding vulnerabilities is an implicit search process over a corpu…
Yes, once we reach the broader conversation (I actually didn't initially grasp that the OP post was a sub-article under another one on LWN which then linked out to yet another article called "Vulnerability Research is Cooked"), I completely agree. Modern LLMs are _exceptionally_ good at developing X-marks-the-spot vulnerabilities into working software; I fed an old RSA validation mistake in an ECU to someone in a Git…
Earlier quoted context omitted.
Around 70% of security vulnerabilities are about memory safety and only exist because software is written in C and C++. Because most vulnerabilities are in newly written code, Google has found that simply starting writing new code in Rust (rather than trying to rewrite existing codebases) quickly brings the number of found vulnerabilities down drastically.
I find this interesting. Curl's Daniel Stenberg claimed during his NDC talk that vulnerabilities in this project are 8 years old on average. I wonder where the disconnect comes from.
Earlier quoted context omitted.
It's amazing that the world has largely forgotten the terror of losing entire documents forever. It happened to me. It happened to everyone. And this is the only comment I've seen so far here to even mention this. Bad old days indeed!
Indeed, but it was pretty easy to develop the habit of hitting whatever function key was bound to "Save" fairly frequently. I certainly did. Also auto-save is a mixed bag. With manual save, I was free to start editing a document and then realize I want to save it as something else, or just throw away my changes and start over. With auto-save, I've already modified my original. It took me quite a while to adjust to th…
Almost none do, though. Auto-save almost always writes to a temporary file, that is erased when you save manually.
Earlier quoted context omitted.
I wouldn't take that as criticism; you are 100% correct. But that instability was a direct result of the issues I mentioned above: the ring transition protection/implementation was absolutely horrible; 3rd-party developers would discover a useful function in NTDLL and start using it in unintended ways, etc. Do you remember the CSRSS Backspace Bug? [0] A simple: printf("hung up\t\t\b\b\b\b\b\b"); from ring-3 would res…
I can't imagine how much of a breath of fresh air Python / Java must have been if you were used to write typical business crud apps (and server software) in C/C++ (with no sanitizers / modern tooling to speak of).
I spent the last few months building a toy LLM from scratch. I can't believe that within my lifetime I've gone from using punch cards to arguing with Claude when it does something ridiculous.