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

Kernel code removals driven by LLM-created security reports

lwn.net

Post reply on HN
Print view View original

111–120 of 130 posts

Re: Kernel code removals driven by LLM-created security reports

#111

Post by anthk »

mike_hearn wrote: post #102
traceroute66 wrote: post #92

Earlier quoted context omitted.

>You can doubt it all you want, ISDN is used internally in broadcast all over the world Since you claim to be a domain expert, give me hard named examples with independently verifiable links. At this stage I want facts, not anecdotes. Because right now, my semi-educated guess is they are all using IP-based streaming codecs and protocols for remote contributions, outside broadcast, studio links and pretty much everyth…

No, he's right. I have a friend who does voiceover work and is and announcer for the UK Channel 4. He does all his work from home using an ISDN link. It's a huge pita for him because the telcos don't want to know indeed, but it's the usual story with legacy workflows. I think it's also a fully switched system so you are guaranteed bandwidth with no packet drops or buffering which is clearly useful for broadcast work.

And by IP over media, it's literal:

https://en.wikipedia.org/wiki/DOCSIS

https://defcon.org/images/defcon-16/dc16-presentations/defco...

Re: Kernel code removals driven by LLM-created security reports

#112

Post by ajross »

sylware wrote: post #107
ajross wrote: post #50

Earlier quoted context omitted.

> more modern protocols (in userspace) That's really it. The list of things that "need" to be in the kernel is shrinking steadily, and the downsides of having C code running in elevated privilege levels are increasing. None of that is about LLMs at all, except to the extent that it's a notable inflection point in a decades-scale curve. The future, and we basically all agree, puts complexities like protocol handling a…

kernel/user space context switching, in high performance context has to be seriously evaluated. And this is very dependent on the hardware programming interface of the devices. Look at AMD who is investigating hardware user-level queues for their GPUs (dunno if this is possible because of VMID stuff)

> kernel/user space context switching, in high performance context has to be seriously evaluated.

Of course. But that's true for all userspace solutions too, and there are many options for async APIs (io_uring et. al.) which work to address that.

The point is that you want the IP stack (or whatever) to be passing stuff around on unix domain sockets for every packet. It's that you want it running in its own memory domain.

Re: Kernel code removals driven by LLM-created security reports

#113

Post by arcfour »

DanielHB wrote: post #14
stratos123 wrote: post #11

Earlier quoted context omitted.

In terms of quantity, definitely yes (a single person managing a swarm of Opusi can already find much more real bugs than a security researcher, hence the rise in reports). In terms of quality ("are there bugs that professional humans can't see at any budget but LLMs can?") - it's not very clear, because Opus is still worse than a human specialist, but Mythos might be comparable. We'll just have to wait and see what…

There is also a huge surface area of security problems that can't happen in practice due to how other parts of the code work. A classic example is unsanitized input being used somewhere where untrusted users can't inject any input. Being flooded with these kind of reports can make the actual real problems harder to see.

They wouldn't be classed as vulnerabilities then, since, you know, there is no vulnerability. Unless you have evidence that most of these issues are unexploitable, but I would be surprised to hear that they were considered vulnerabilities in that case.

Re: Kernel code removals driven by LLM-created security reports

#115

Post by ErroneousBosh »

duskwuff wrote: post #99
rwmj wrote: post #64

Earlier quoted context omitted.

I don't think this is actually true (eg. DPDK), but even if it is, you can put the driver in userspace (tun/tap + vfio/libusb/ioport/...) and still use TCP/IP in the kernel.

Speed certainly certainly isn't an issue for AX.25. The protocol typically runs at <10 kbps; the overhead of processing packets in userspace is negligible.

It most commonly runs at 1200bps, used for APRS these days.

You can do a neat trick with this if you set up IP over AX.25, particularly with softmodems. Since you've got IP you can do SSH or TLS over it, right? At least, if you set all the timeouts really long, because some of those packets take a while at 120 bytes per second.

So then you can tune the tones to be a little off the normal frequencies of one side, and play them through speakers with two PCs connected together. When you ssh from one to the other, you will hear the establishment packets and the flurry of packets for every keypress pingponging backwards and forwards between the two systems.

Absolutely brilliant for demonstrating how things like TCP works with retries (plug a mike into it too, shout some interference) and how UDP doesn't, and stuff.

Re: Kernel code removals driven by LLM-created security reports

#116

Post by ajross »

anthk wrote: post #103
pixl97 wrote: post #91

Earlier quoted context omitted.

"Get Pwn3d server times faster!" Seemingly we've been writing kernels for years, and they still are full of security holes.

p0wned from where? Where's the vector attack? Do you realize AX25 it's just something loaded on demand when the user requires it, and not by default? Do you know the basics on how the systems work bellow your shiny UI's and IDE's? First, AX25 modules would just lie down in the disk harmless, no AX25 stuff it's loaded unless some user modprobe thems in order to setup some hamradio stack with HamNet and the like. I see…

> p0wned from where? Where's the vector attack?

For clarity: the example upthread about pwning was TCP/IP, not AX.25.

Also the idea that "there are no local exploits in this kernel code because it's not used by the running system" is like the proximate cause of 80% of local privilege escalation vulnerabilities. Seriously?

Re: Kernel code removals driven by LLM-created security reports

#117

Post by anthk »

ErroneousBosh wrote: post #115
duskwuff wrote: post #99

Earlier quoted context omitted.

Speed certainly certainly isn't an issue for AX.25. The protocol typically runs at <10 kbps; the overhead of processing packets in userspace is negligible.

It most commonly runs at 1200bps, used for APRS these days. You can do a neat trick with this if you set up IP over AX.25, particularly with softmodems. Since you've got IP you can do SSH or TLS over it, right? At least, if you set all the timeouts really long, because some of those packets take a while at 120 bytes per second. So then you can tune the tones to be a little off the normal frequencies of one side, and…

- Lower the MTU

- Use Mosh instead of SSH

- Spawn TMUX in the remote machine to send less bits per session

I tried Mosh+Tmux with 2.7 KBPS (and less) when I was using a data plan. It worked perfectly fine, no delay or barely noticeable.

Re: Kernel code removals driven by LLM-created security reports

#118

Post by anthk »

ajross wrote: post #116
anthk wrote: post #103

Earlier quoted context omitted.

p0wned from where? Where's the vector attack? Do you realize AX25 it's just something loaded on demand when the user requires it, and not by default? Do you know the basics on how the systems work bellow your shiny UI's and IDE's? First, AX25 modules would just lie down in the disk harmless, no AX25 stuff it's loaded unless some user modprobe thems in order to setup some hamradio stack with HamNet and the like. I see…

> p0wned from where? Where's the vector attack? For clarity: the example upthread about pwning was TCP/IP, not AX.25. Also the idea that "there are no local exploits in this kernel code because it's not used by the running system" is like the proximate cause of 80% of local privilege escalation vulnerabilities. Seriously?

How can I exploit an unloaded module?

Re: Kernel code removals driven by LLM-created security reports

#119

Post by ajross »

anthk wrote: post #118
ajross wrote: post #116

Earlier quoted context omitted.

> p0wned from where? Where's the vector attack? For clarity: the example upthread about pwning was TCP/IP, not AX.25. Also the idea that "there are no local exploits in this kernel code because it's not used by the running system" is like the proximate cause of 80% of local privilege escalation vulnerabilities. Seriously?

How can I exploit an unloaded module?

... by loading it? There are many ways to get the kernel to suck in a module you can then bang on over sysfs or whatever API it presents. You can have a local exploit in a binary with CAP_SYS_MODULE, subsystems can be fooled into passing uncooked strings to modprobe, users can be fooled into dropping junk into /etc/modprobe.d (instructions for doing so are pervasive in the embedded world and most users think this stuff is safe), etc...

This kind of chicanery is the vanilla pudding of the hacker world. It's everywhere. Suffice it to say that you're simply wrong: NO, it's never OK to argue a subsystem is safe because you personally think it can't be loaded. It 100% can be, that's the easy part.

Re: Kernel code removals driven by LLM-created security reports

#120

Post by charleslmunger »

traceroute66 wrote: post #67
stratos123 wrote: post #20

Earlier quoted context omitted.

A 0% false-positive rate is not necessary for LLM-powered security review to be a big deal. It was worthless a few months ago, when the models were terrible at actually finding vulnerabilities and so basically all the reports were confabulated, with a false positive rate of >95%. Nowadays things are much better - see e.g. [1] by a kernel maintainer. Another way to see this is that you mentioned "LLM found this seriou…

> A 0% false-positive rate is not necessary To be clear, I'm not saying 0% false-positive because that will always be impossible with any LLM. However, to greatly over-simplify what I already said ... The presence of >0 false-positives means you still need someone who knows what they are doing behind the keyboard. The presence of an LLM, no matter how good, will never remove the need for a human with domain expertise…

If you can trigger address sanitizer from input outside the program, and the program may interact with untrusted input, isn't that always worth reporting and fixing?
Post reply on HN