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

Dirty Frag: Universal Linux LPE

openwall.com

Post reply on HN
Print view View original

91–100 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#91

Post by tptacek »

parliament32 wrote: post #64
tptacek wrote: post #40

Earlier quoted context omitted.

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.

No, they did not. Careful of falling for the psychosis. > This finding was AI-assisted, but began with an insight from Theori researcher Taeyang Lee, who was studying how the Linux crypto subsystem interacts with page-cache-backed data. https://xint.io/blog/copy-fail-linux-distributions

Theori is an AI security research firm.

Re: Dirty Frag: Universal Linux LPE

#92

Post by tptacek »

angry_octet wrote: post #90
tptacek wrote: post #83

Earlier quoted context omitted.

The energy here is "so don't leave anything valuable in your car".

Unfortunately that is not what they proposed. To stretch the automotive analogy too far, you could say: if you invite a carjacker in, their seatbelt is not going to stop them from carjacking you.

"Avoid shared-kernel attack surfaces" is not an unreasonable proposition in 2026.

Re: Dirty Frag: Universal Linux LPE

#93

Post by wpollock »

dundarious wrote: post #65
john_strinlai wrote: post #3

"Because the embargo has now been broken, no patches or CVEs exist for these vulnerabilities." link: https://github.com/V4bel/dirtyfrag detailed writeup: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-... importantly: " Copy Fail was the motivation for starting this research. In particular, xfrm-ESP Page-Cache Write in the Dirty Frag vulnerability chain shares the same sink as Copy Fail. However, it is t…

You can't sudo echo and redirect from the non-sudo shell like that. echo 3 | sudo tee /proc/sys/vm/drop_caches or sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' Also fixed your typo in /proc...

Or more simply, use

   su -c 'echo 3 > /proc/sys/vm/drop_caches'

Re: Dirty Frag: Universal Linux LPE

#95

Post by eqvinox »

If you don't need it (rootless containers), you can disable unprivileged userns to block these two:

  echo 1 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns
May also break sandboxes (e.g. browser) though.

Re: Dirty Frag: Universal Linux LPE

#96

Post by toast0 »

eqvinox wrote: post #50
firer wrote: post #32

Earlier quoted context omitted.

SUID mitigations have nothing to do with the vulnerability itself - just the exploit. If there's a root cronjob that runs a world readable binary, you could modify it in the page cache and exploit it that way. Modifying the page cache is a really strong primitive with countless ways to exploit it.

splice() should maybe generally refuse to operate on things you can't write to.

splice is documented to return EBADF if "One or both file descriptors are not valid, or do not have proper read-write mode."

So it seems surprising to me that you can call it when the out fd is not writable? But I didn't retain the information about the vulnerability, so I'm missing something. There was something about copy on write, IIRC?

Re: Dirty Frag: Universal Linux LPE

#97

Post by varispeed »

firer wrote: 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…

> When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby.

That's why is very very important to just step out and use saved time to go for a walk, to a park, sit on a bench, listen do birds, close eyes and zoom out.

The state we are in is actually brilliant.

Re: Dirty Frag: Universal Linux LPE

#98

Post by seba_dos1 »

wpollock wrote: post #93
dundarious wrote: post #65

Earlier quoted context omitted.

You can't sudo echo and redirect from the non-sudo shell like that. echo 3 | sudo tee /proc/sys/vm/drop_caches or sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' Also fixed your typo in /proc...

Or more simply, use su -c 'echo 3 > /proc/sys/vm/drop_caches'

echo 3 | sudo tee /proc/sys/vm/drop_caches

Re: Dirty Frag: Universal Linux LPE

#100

Post by eqvinox »

toast0 wrote: post #96
eqvinox wrote: post #50

Earlier quoted context omitted.

splice() should maybe generally refuse to operate on things you can't write to.

splice is documented to return EBADF if "One or both file descriptors are not valid, or do not have proper read-write mode." So it seems surprising to me that you can call it when the out fd is not writable? But I didn't retain the information about the vulnerability, so I'm missing something. There was something about copy on write, IIRC?

"proper read-write mode" for the input fd is reading only. The exploit is writing to the splice() input fd.

Also, NB, I said permission check, not mode check. The input fd to splice can and will be open for only reading quite often. Doesn't mean the kernel can't still do a write permission check.

(Except I didn't say that here. Oops. Getting confused with my posts.)

Post reply on HN