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

41–50 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#41

Post by firer »

eqvinox wrote: post #29
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…

No, unless I'm misreading it it's the *same* root cause: high 32 bits of Extended ESN in IPsec == authencesn module/cipher mode. The wrong thing got fixed for copy.fail, because people jumped to blame AF_ALG. [ed.: yes it's the same authencesn issue. https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... it doesn't say authencesn in the code, only in a comment, but nonetheless, same issue.] [ed.2: the RxRPC…

There are two vulnerabilities here.

The RxRPC one is definitely a different root cause (although caused by a very similar mistake).

For the ESP one it's a bit harder to tell. I don't think the wrong thing was fixed, just that there was a very similar bug in almost the same spot. Could be wrong about that though.

Re: Dirty Frag: Universal Linux LPE

#42

Post by staticassertion »

jacobgkau wrote: post #38
john_strinlai wrote: post #15

Earlier quoted context omitted.

it was published publicly by an unrelated third party

They're asking the nature of the third party's discovery/publishing. Someone on the inside who decided to leak it anonymously? Someone else who was able to access some private communication they shouldn't have been able to see? Or a third party who happened to discover the same vulnerability (which seems less unlikely than normal since this is so similar to Copy Fail), but didn't follow disclosure procedures?

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

Re: Dirty Frag: Universal Linux LPE

#43

Post by pjmlp »

grosswait wrote: post #24
pjmlp wrote: post #14

Earlier quoted context omitted.

Because Android is not Linux, as much as some pretend it is. In fact, given the official public APIs, Google could replace the Linux kernel with a BSD, and userspace wouldn't notice, other than rooted devices, and the OEMs themselves baking their Android distro.

It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.

No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land.

Some folks like the termux rebels, occasionally find out there is a sherif in town.

> As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: the NDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview.

https://android-developers.googleblog.com/2016/06/improving-...

These stable APIs,

https://developer.android.com/ndk/guides/stable_apis

Re: Dirty Frag: Universal Linux LPE

#44

Post by papascrubs »

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…

Or a follow up prompt: "find similar classes of bugs". Once the actual case has been layed out finding like bugs isn't too hard. I hear you on the creativity bit. Like any tool, AI can put blinders on. Using it to augment without it fully taking over your workflow is tough.

Re: Dirty Frag: Universal Linux LPE

#45

Post by eqvinox »

firer wrote: post #41
eqvinox wrote: post #29

Earlier quoted context omitted.

No, unless I'm misreading it it's the *same* root cause: high 32 bits of Extended ESN in IPsec == authencesn module/cipher mode. The wrong thing got fixed for copy.fail, because people jumped to blame AF_ALG. [ed.: yes it's the same authencesn issue. https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... it doesn't say authencesn in the code, only in a comment, but nonetheless, same issue.] [ed.2: the RxRPC…

There are two vulnerabilities here. The RxRPC one is definitely a different root cause (although caused by a very similar mistake). For the ESP one it's a bit harder to tell. I don't think the wrong thing was fixed, just that there was a very similar bug in almost the same spot. Could be wrong about that though.

(you probably wrote this while I was editing my post.)

It's absolutely the same issue in authencesn/ESP. There's another one in RxRPC that is AIUI completely unrelated.

Re: Dirty Frag: Universal Linux LPE

#47

Post by xxpor »

wolttam wrote: post #36
xxpor wrote: post #30

Linux is a single user system and should be treated as such. Run your services as root. Don't rely on unix user primitives for security.

Running as root opens you up to a class of vulnerabilities (denial of service, mainly) that you can avoid by not running as root. That said, running every process in its own micro VM is looking more attractive by the minute.

Half the point is that you should always assume that there exists a complete LPE bug.

But yes, micro VMs are a great idea!

Re: Dirty Frag: Universal Linux LPE

#49

Post by firer »

tptacek wrote: post #40
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…

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.

From what I understand, the copy fail bug was found by researcher who noticed something weird and then using AI to scan the codebase for instances where that becomes a problem.

I bet that with a slightly looser prompt/harness, the LLM could have found these twin bugs too.

Yet at the same time, I also think that if the human researcher had manually scanned the code, he'd have noticed these bugs too.

FWIW I do think LLMs are great tools for finding vulnerabilities in general. Just that they were visibly not optimally applied in this case.

Re: Dirty Frag: Universal Linux LPE

#50

Post by eqvinox »

firer wrote: post #32
formerly_proven wrote: post #31

Earlier quoted context omitted.

These are all page cache poisoning attacks (dirtyfrag, copyfail, dirtypipe). Maybe the page cache should have defense-in-depth measures for SUID binaries?

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.
Post reply on HN