Live data from Hacker News

Dirty Frag: Universal Linux LPE

openwall.com

251–260 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#252
post #172

Earlier quoted context omitted.

That's not necessarily true. Who's to say the security researchers wouldn't have found it if they'd searched the code manually?

It would have taken a LOT longer but often this kind of manual search is so tedious people just don't do it. LLMs don't get bored.

> LLMs don't get bored

They do not get bored like a human but they are trained on human language and replicate the same traits, such as laziness, and expressing boredom or annoyance (even if obviously they do not experience anything at all). It’s actually a lot of effort to get them to engage with things at a deeper level without skipping corners

Re: Dirty Frag: Universal Linux LPE

#253
Perhaps we should consider designing distributions to be more tailored to specific purposes. Since no one needs the affected module on a desktop computer, distributions designed for that purpose should no longer include it by default. If this approach were consistently followed, significantly fewer systems would be vulnerable to such exploits. For most users a system with a kernel as minimalistic as the Android GKI kernel combined with sensible SELinux policies, would likely be sufficient.

Re: Dirty Frag: Universal Linux LPE

#254
post #77
post #60

Earlier quoted context omitted.

I don't think the copy.fail people understood the issue they found, as is evident by the heavy focus on AF_ALG/aead_algif, which is essentially "innocent" as we're seeing here. I think LLMs are great for vulnerability discovery, but you need to not skimp on the legwork and understanding what even you just found there.

Right but without the LLM the bug doesn't get found at all.

Safer to assume at least one of NSA, Mosad and a few others were sitting on it for years.

Re: Dirty Frag: Universal Linux LPE

#255
post #170

After all these years, we finally have enough eyeballs that all bugs are shallow, and it kinda sucks. How many times a week am I going to be updating my kernel from now on?

I sort of always expect there to be an LPE to root on Linux tbh, if anything this is great news and Linux might be a useful multiuser system after all.

Re: Dirty Frag: Universal Linux LPE

#256
post #170

After all these years, we finally have enough eyeballs that all bugs are shallow, and it kinda sucks. How many times a week am I going to be updating my kernel from now on?

With how things are going the question should be ‘is twice a day often enough?’

Re: Dirty Frag: Universal Linux LPE

#257

Perhaps we should consider designing distributions to be more tailored to specific purposes. Since no one needs the affected module on a desktop computer, distributions designed for that purpose should no longer include it by default. If this approach were consistently followed, significantly fewer systems would be vulnerable to such exploits. For most users a system with a kernel as minimalistic as the Android GKI k…

Both of the modules are (also) for desktop/workstation use. Though AFS could probably be retired generally.

Re: Dirty Frag: Universal Linux LPE

#258
post #170

After all these years, we finally have enough eyeballs that all bugs are shallow, and it kinda sucks. How many times a week am I going to be updating my kernel from now on?

I haven't updated mine. I have a firewall and it's not exposed to the Internet. Need a key to SSH in. Same with my public facing server. Almost none of these exploits are "drop everything now and patch" unless you are somehow exposing yourself stupidly.

If you’re running any sort of CI you’re probably going to have a bad couple of days if everything goes well

Re: Dirty Frag: Universal Linux LPE

#259
post #40
post #18

This is very similar in root cause and exploitation to Copy Fail. Which illustrates pretty well something that's lost when relying heavily on LLMs to do work for you: exploration. I find that doing vulnerability research using AI really hinders my creativity. When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby. It's like a genie - you get exactly what yo…

I don't follow. LLMs spotted these bugs in the first place . You seem to be saying that these discoveries are indications that they're bad for vulnerability discovery.

Right. Finding the bug is in itself a win. It seems we’re jumping from that spend-electricity-to-find-bugs win to arguing about how some things around it are not quite good or comfy.

Re: Dirty Frag: Universal Linux LPE

#260

Earlier quoted context omitted.

> When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby. Very much aligns with my experience. For me this is the most unsatisfying thing about AI-based workflows in general, they miss stuff humans would never miss. All the time I wonder what am I missing that's right nearby? It's remarkable how many times I have to ask Claude code to fully ingest something…

Do you think this is inherent or an artifact of prompting? Curiosity and side quests leads to higher token usage and longer time to finish, so I could understand why current harnesses and system prompts would not encourage that sort of thing. But what if a coding agent was prompted to be more curious during development? Like a human developer, make mental notes of alternatives to try out and chase suspicious looking…

I've seen something similar, solutions generated feel very pythonic or javaesque in languages that are neither Python nor Java (C, Rust, Ruby)

I've had to explicitly direct the machine to read existing sibling code and follow the specific idioms and patterns in use.

Post reply on HN