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

241–250 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#241

Post by cyphar »

pjmlp wrote: post #236
esseph wrote: post #55

Earlier quoted context omitted.

https://www.androidpolice.com/google-support-linux-kernels-a... Google relies on Linux LTS kernels. When the Linux LTS team dropped support from 6 years down to 2 years, Google stepped in to cover the 4-year gap. It is Linux. It's basically a distro.

When people say Linux they mean GNU/Linux.

In common parlance, yes -- because there is no practical distinction. But in cases where something is just using the Linux kernel without GNU and other common userpand components (and there is a practical distinction) then it's definitionally untrue to say that it's "not Linux" if you really meant to say "it's not GNU/Linux".

Re: Dirty Frag: Universal Linux LPE

#242

Post by [deleted] »

timcobb wrote: post #230
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. 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…

[deleted]

Re: Dirty Frag: Universal Linux LPE

#243

Post by ulrikrasmussen »

timcobb wrote: post #230
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. 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 code which may seem unrelated to the task at hand. It could even spawn rabbit hole agents in parallel.

Taking a step back, this probably highlights major hazard with the increased usage of LLMs for coding, which is that everyone's style of work is going to converge because most code will be written by the 2-3 most popular models using the same system prompts.

Re: Dirty Frag: Universal Linux LPE

#244

Post by tetha »

Tiberium wrote: post #4

Do you think with modern LLMs in a few years projects like Linux will have all those low-hanging security bugs fixed? Are we witnessing a transition period, or will nothing change?

Out of this dataset of 2-3 vulnerabilities, I'm noticing a pattern: All of those are in older and/or niche kernel modules. That raises two thoughts:

Maybe the more regularly used kernel code has a lot of low-hanging security topics shaken out of it already.

And second, I'm indeed wondering what a good path to minimize the loadable kernel code is on a system looks like. My container hosts for example have a fairly well defined set of requirements, and IPSec certainly is not in there. So why not block everything solely made to support IPSec? I'm sure there is more than that.

After all, the most reliable way to higher security is to do less things.

Re: Dirty Frag: Universal Linux LPE

#245

Post by bjackman »

thom wrote: 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?

Updating your kernel isn't good enough, it never was.

Native unsandboxed execution == root. Only thing that's new is some people started making websites for their LPEs.

https://github.com/google/security-research/tree/master/pocs...

Re: Dirty Frag: Universal Linux LPE

#246

Post by riedel »

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…

Just on a side note. Negative synergy does not seem so uncommon with machine learning. We did some research maybe 10 yrs ago an human/ML based duplicate detection (for a municipal support ticket system) . Research showed that pure AI and pur human outperformed co-working. Human oversight often e.g. overcorrected machine work. I think it is a nice HCI problem to solve actually to amplify creativity and unique skills in such processes. Particularly if they can be to some degree repetitive and tiresome.

Re: Dirty Frag: Universal Linux LPE

#247

Post by akimbostrawman »

croes wrote: post #219
lunar_rover wrote: post #160

Earlier quoted context omitted.

In many ways non mobile computers are very much still stuck in 1999. Android is significantly more secure than other Linux systems because it's much younger and had the chance to integrate mandatory access control into the entire stack.

Unless your Android doesn’t get any security updates anymore. https://durovscode.com/google-android-security-update-warnin...

That is a well know and entirely different issue

Re: Dirty Frag: Universal Linux LPE

#248

Post by thom »

brcmthrowaway wrote: post #176
thom wrote: 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?

I think when there’s a step change in our ability to find one type of vulnerability, other types of vulnerability are probably going to become more common as well. Let’s see where we stand at the end of the year.

Re: Dirty Frag: Universal Linux LPE

#249

Post by pepa65 »

michaelt wrote: post #174
JeremyNT wrote: post #119

Earlier quoted context omitted.

Distro maintainers blacklisting specific functionality because they believe YAGNI is a pretty big ask. They just don't know who is using what. It's always possible for users to go back and tailor their builds for the stuff they actually want. And... I remember the early days of Linux where I ran `make menuconfig` and selected exactly the functionality I wanted in my kernel. I'd... rather not end up back there. That s…

Now I think about it, it's kinda weird if non-root users can cause kernel modules to get loaded, without any hardware changes having happened. If the kernel modules for esp4, esp6 and rxrpc aren't loaded - how is it that a non-root attacker can cause them to get loaded?

It seems that this is allowed as part of a dependency chain...

Re: Dirty Frag: Universal Linux LPE

#250

Post by dgellow »

papascrubs wrote: post #44
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.

Not just like any tool though. Interacting with agents can be incredibly boring and frustrating in a way that I personally do not experience with other technology
Post reply on HN