AI finds thousands of zero-day exploits... including in FreeBSD.

blackbird9 said:
Oh well, we shall have to see if re-writing everyting in Rust is the solution. I wonder how that's coming along? :)
Click to expand...
A possible "dreaming scenario": important parts of FreeBSD like Jails and Capsicum will be checked and declared secure (more feasible than in Linux); then all the rest of services and applications will be built/adapted composing these parts. This will reduce a lot the escalation of security problems in non-safe code. A bad video will break ffmpeg output but not the system, and it will be self-sabotage...

The majority of secure systems (e.g. seL4, Google Fuchsia) use capabilities, so FreeBSD is well positioned in this regard.

Or maybe they can combine static source code analyzer (a sort of formal analysis) with AI. AI can automatize a lot the double checking of the many (too much) false warnings.
 
My .02$; Anthropic is spamming FUD all over the place, the handling of the new model is a clear proof. Check out their papers, those are not scientific papers, they literally write like they're in awe of the output. The progress curve is shrinking and just like OpenAI used to do, they will gaslight the audience.

blackbird9 said:
"A flaw in OpenBSD's TCP SACK implementation dating back to 1999. A signed integer overflow allowing remote denial-of-service. The kind of bug that survived hundreds of reviews, dozens of major releases, thousands of pairs of eyes. Still there.

A defect in FFmpeg's H.264 decoder, 16 years old. A sentinel collision causing an out-of-bounds write. Automated tools never caught it. Not for lack of trying: 5 million fuzz tests. Zero results. Mythos found it by analyzing the code directly."

Although it doesn't say so, what would have impressed me would be if it only found ONE bug in openbsd... we don't know the full number, of course.

"The model chained multiple Linux kernel vulnerabilities to build a full privilege escalation path, defeating hardened protections: stack canaries, KASLR, W^X. Not an isolated flaw. A working attack chain.

On FreeBSD, Mythos autonomously identified and exploited a 17-year-old remote code execution vulnerability in the NFS service. Unauthenticated root access. Fully autonomous. No human steering.

And then there's this: against Firefox 147, the model successfully developed JavaScript shell exploits 181 times. Claude Opus 4.6, the previous best model? Twice."
Click to expand...

This gist was written by LLM.
I wonder whether I would take its output more seriously if it didn't engage in that braindead style of writing, close to speaking style of a certain important country's president.

Again, Anthropic is trying to one up OpenAI by selling FUD directly to the major corporations. The fear-of-missing-out pattern OpenAI has used on individuals is dwindling down and Anthropic has retargeted the same approach towards major IT enterprises; now if you're a major software company, you might be missing out on not having Anthropic as "security partner", just like everyone here who wasn't using OpenAI for their projects has missed out on having "Artificial Intelligence" as their engineering sidekick.

As for the FreeBSD NFS exploit, nobody same would claim that stuff is secure. It is ancient code, hasn't been audited and refactored for secutiry as far as I know. It is not nice having a remote exploit in the base install, again, FreeBSD is ~35 years old and has never ever had a code freeze for a proper security audit, nor it can do that.
 
NFS isn't exactly new technology. I'm really not very surprised they found a problem.

Hmm, so the jury is out. Either they do have something real... or this is all hype and an attempt at a kind of 'protection racket' to try to get a funding stream from corporates. Or perhaps a bit of both.

Presumably they did actually find some important, real exploits, or they would be laughed out of the room. Finding something in some old freebsd NFS code that isn't used all that much today isn't particularly impressive though. If they had found something in sshfs, that would be more interesting. I am a bit more interested in what they claim to have found in linux, and in firefox. But all we have is a summary in a press release, which really lies in the category of "claims". Oh well, we shall have to see what happens with this. It's interesting to hear people's opinions.
 
blackbird9 said:
Hmm, so the jury is out. Either they do have something real... or this is all hype and an attempt at a kind of 'protection racket' to try to get a funding stream from corporates. Or perhaps a bit of both.
Click to expand...
I'm thinking a bit of both, maybe biased towards hype.
Honestly, look at NFS. Does anyone run NFS over the public internet or do you use it on your home network (isolated) or work network (again isolated)? If an exploit is not a "remote" exploit, then you start needing more physical access, so there are other concerns that need breaking before the exploit can happen.
 
blackbird9 said:
Yes, iSCSI is a better example, if they had found an exploit in that, that would have been more significant.
Click to expand...

NFS is in much more common use than iSCSI, though.

NFS with Kerberos (as I understand the exploit is only against NFS with Kerberos) might be a different matter.
 
mer said:
I'm thinking a bit of both, maybe biased towards hype.
Honestly, look at NFS. Does anyone run NFS over the public internet or do you use it on your home network (isolated) or work network (again isolated)? If an exploit is not a "remote" exploit, then you start needing more physical access, so there are other concerns that need breaking before the exploit can happen.
Click to expand...

LAN is a relative term. There are a lot of devices such as video streamers, cameras and wifi hubs that are easily taken over and could attack an NFS server on the LAN.
 
Zare said:
They should all be isolated. Anything that runs proprietary or unchecked firmware should be isolated.
Click to expand...

Yes, but I know very few people who do that. Most people only have one LAN. Maybe an additional WLAN for guests, but it doesn't carry their own bad devices.

Even when they do, the bad devices are usually fed with an SMB drive or similar, so you are right back where you started.
 
This brings to mind the idea of resurrecting SQUID as a malware filtering proxy between the LAN and the public facing world.

Is this still viable?
 
Alain De Vos said:
I don't trust NFS. It's not performant , it's not safe.

iSCSI is preferable , it's a block device , not a "file device".
Click to expand...
Obviously in certain usage scenario you cannot replace NFS with iSCSI. NFS is a network file system, while iSCSI simulates a local drive, hence you cannot share an iSCSI device between many clients.

I never used network file systems, apart some sshfs connection, and minimal Samba setup, but they intrigue me a lot. CephFS, Garage, Seaweed, etc.. Or distribuited filesystems like IPFS and hyperdrive.
 
OpenFreeNet said:
Obviously in certain usage scenario you cannot replace NFS with iSCSI. NFS is a network file system, while iSCSI simulates a local drive, hence you cannot share an iSCSI device between many clients.

I never used network file systems, apart some sshfs connection, and minimal Samba setup, but they intrigue me a lot. CephFS, Garage, Seaweed, etc.. Or distribuited filesystems like IPFS and hyperdrive.
Click to expand...
Nfs on top of iSCSI? Never used it but nfs doesn't really care about the physical medium of local files. It suits for quick access to a network directory with only a few commands and it needs no reboot to activate it.
 
MG said:
If iSCSI is safe enough, everything that relies on it is safe too, right? You can share things with other clients while using iSCSI anyway.
Click to expand...
If there is security hole in NFS + Kerberos, the security hole does not depend from where NFS store the data: it can be a local device or a iSCSI device.
 
You must log in or register to reply here.
Back
Top