Here's the thing, all of these problems are pre-existing. All LLMs are doing is shining a big bright light on it.
With enough tokens, all bugs are shallow? :D
Kernel code removals driven by LLM-created security reports
121–130 of 130 posts
Re: Kernel code removals driven by LLM-created security reports
#122Earlier quoted context omitted.
We are talking about drivers for devices from the last century which nobody even uses anymore. This isn't "shining light" on important pre-existing issues that have been ignored for too long or something, it isn't helping. The only problem here, if any, is the false sense of confidence given by LLMs to people who have no business touching kernel code.
what do you mean nobody? there are a few of us using it, and we are completely broken when support is taken away.
Sounds like someone should budget for an oss sponsorship
Re: Kernel code removals driven by LLM-created security reports
#123Earlier quoted context omitted.
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 stu…
>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...
Not an issue for AX25 per se.
If you can fool an user to run root instructions, it's game over, period.
Re: Kernel code removals driven by LLM-created security reports
#124Earlier 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…
> You cannot blindly fix stuff just because the LLM says it needs fixing.
> You cannot report stuff just because the LLM says it needs reporting.
Not today, maybe. Though with a good enough harness we're pretty close to seeing that already.
But in 6 months after another halving of the error rate? I wouldn't be so sure.
Re: Kernel code removals driven by LLM-created security reports
#125Earlier quoted context omitted.
... 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 stu…
>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... Not an issue for AX25 per se . If you can fool an user to run root instructions , it's game over, period.
There is a difference between running any instructions and an instruction that would otherwise be considered safe.
Re: Kernel code removals driven by LLM-created security reports
#126Earlier quoted context omitted.
... 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 stu…
>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... Not an issue for AX25 per se . If you can fool an user to run root instructions , it's game over, period.
[deleted]
Re: Kernel code removals driven by LLM-created security reports
#127Earlier quoted context omitted.
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.
And then you'd be able to hear the difference in the chat between the two machines! That's an amazing demo :-)
I used to use mosh and tmux over 9600bps AX.25 before I had 3G data, a very long time ago. Strictly speaking SSH over amateur radio breaks the rule about encryption but 144MHz is a big place with no-one in it, and you can't pay Ofcom to take an interest in what people do on amateur radio.
Re: Kernel code removals driven by LLM-created security reports
#128Earlier quoted context omitted.
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.
I believe the LLM would flag this kind of thing as a potential issue.
Re: Kernel code removals driven by LLM-created security reports
#129[dead]
Re: Kernel code removals driven by LLM-created security reports
#130Earlier quoted context omitted.
Opuses is also correct English, and clearer in non-academic contexts. Opera is the traditional plural from Latin, now perhaps for more scholarly use in English. Results from a quick search.
I'll do the faux German thing then: Opusen :)
pseudofauxteutönic