Live data from Hacker News

Dirty Frag: Universal Linux LPE

openwall.com

201–210 of 370 posts

Re: Dirty Frag: Universal Linux LPE

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

It’s incredible humans spot stuff like this. I guess even more incredible that LLMs can do it!

Re: Dirty Frag: Universal Linux LPE

#203

Earlier quoted context omitted.

The commit for the fix was public. Someone noticed. An exploit was published.

I think I read on the bug's website that "No fix has been released". I understood that as there is no public fix, but maybe it only means it's not in a tagged version of the kernel and no hotfixed distro kernels have been released?

The fix has been commited to the git tree for the `netdev` linux subsystem fork. That's how it was noticed by the grsecurity guy who published an exploit. Then, it will be merged by linus either into a RC/master for the next linux minor version release, or into the patch releases branch by GregKH/Sasha for already-released versions. Or in this case, both, because it's a security fix.

Re: Dirty Frag: Universal Linux LPE

#205
post #172
post #77

Earlier quoted context omitted.

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

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

I’m hardly going to simp for LLM tools but the fact that the bug existed and no one had reported it seems proof positive no one was about to find it without them

Re: Dirty Frag: Universal Linux LPE

#207
post #116

Earlier quoted context omitted.

It’s not enabled by default. It’s an optional module that is loaded on demand. The entire setup of the kernel promotes compiling in the core set of things your users will need and offering basically everything else as a module to load on demand.

This is a pedantry for the sake of it. If it's present by default and an attacker can trivially cause it to be loaded, it's the same as "on by default".

How would the attacker cause one of these modules to get loaded without already having root?

Re: Dirty Frag: Universal Linux LPE

#208
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?

So you think someone is going to break into your house, find your default credentials somehow and get root access?

With physical access, root access is as simple as setting init=/bin/bash in the kernel parameters from a bootloader. No need for credentials or anything.

Re: Dirty Frag: Universal Linux LPE

#210
post #203

Earlier quoted context omitted.

I think I read on the bug's website that "No fix has been released". I understood that as there is no public fix, but maybe it only means it's not in a tagged version of the kernel and no hotfixed distro kernels have been released?

The fix has been commited to the git tree for the `netdev` linux subsystem fork. That's how it was noticed by the grsecurity guy who published an exploit. Then, it will be merged by linus either into a RC/master for the next linux minor version release, or into the patch releases branch by GregKH/Sasha for already-released versions. Or in this case, both, because it's a security fix.

Spender didn't publish any exploit afaik
Post reply on HN