301–310 of 370 posts
Monolithic UNIX-like kernels are a bankrupt design.
Only third generation microkernels like seL4[0] make sense in the present world. All effort put elsewhere is wasted outright.
Earlier quoted context omitted.
Have a look at https://github.com/atgreen/rhel-block-copyfail
Thanks! From the sound of it, the same mitigations for Copy Fail 1 are also effective here.
Earlier quoted context omitted.
xz was not directly linked to ssh, and systemd itself was not providing the backdoor. The weakness is embedded into the architecture of glibc (which has spread to other systems like FreeBSD as well): https://github.com/robertdfrench/ifuncd-up
Sure, but distros not using systemd were not affected.
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…
Earlier quoted context omitted.
This is really not a correct statement beyond the fact that both are a type of Unix.
What are the differences? I think of both as Unix-type sytems with macrokernels. I have no practical experience with BSDs.
Earlier quoted context omitted.
So a threat actor buys access to a managed kubernetes service, or other linux-based shared hosting platform, and now they have access to the computer. Hell, GitHub Actions would do.
Is there any service that relies on Linux user separation or containers to separate different user accounts? I’m pretty sure you’re not supposed to do that and the proper way is to run different instances in virtual machines.
Earlier quoted context omitted.
setuid binaries are not the only way to get root. E.g. one can change /etc/crontab or /etc/passwd. Or add trojan to /bin/ls and wait until admin type 'ls'
It's not always as easy as you imply. All the attack vectors you mentioned, require root on the host, before you can make the change or install the trojan.
Earlier quoted context omitted.
You appear to want to die on the hill of "This vulnerability would never have been found if we lived in a world without LLM AI" which is a very strange hill to die on. There's no question that we live in the world where LLM AI was involved in finding the copy fail vulnerability at this specific time, and it's completely normal for people to see a vulnerability and then look closer and find related vulnerabilities or…
It's weird to say I want to "die on this hill" because that's not even something I believe. There was nothing especially difficult about this particular vulnerability. My only observation that nobody did find it before, then an LLM security firm went out looking for Linux LPEs, and thus it was discovered. That is a very difficult fact pattern to which to attach the conclusion "LLMs have sabotaged security research" (…
Otherwise, it won't be classified as "new"
--
Edit:
I think LLM is very useful here.
When a researcher spot something funny, instead of spending two days on reading and testing, he can fire up a LLM and have it read all the code lead to there in ~30 minutes.
The fragmentation logic in the networking stack has been a recurring source of bugs for years. It is surprising how these edge cases keep surviving multiple security audits.