Live data from Hacker News

Assessing Claude Mythos Preview's cybersecurity capabilities

red.anthropic.com

31–40 of 59 posts

Re: Assessing Claude Mythos Preview's cybersecurity capabilities

#32

My two cents is LLMs are way stronger in areas where the reward function is well known, such as exploiting - you break the security, you succeed. It's much harder to establish whats a usable and well architected, novel piece of software, thus in that area, progress isn't nearly as fast, while here you can just gradient descent your way to world domination, provided you have enough GPUs.

Construction is always more expensive than destruction

Re: Assessing Claude Mythos Preview's cybersecurity capabilities

#33
post #20

Related ongoing threads: System Card: Claude Mythos Preview [pdf] - https://news.ycombinator.com/item?id=47679258 Project Glasswing: Securing critical software for the AI era - https://news.ycombinator.com/item?id=47679121 I can't tell which of the current threads, if any, should be merged - they all seem significant. Anyone?

I think the system card one should be separate, but this and the Glasswing thread are basically the same story.

Re: Assessing Claude Mythos Preview's cybersecurity capabilities

#34

Since this level of security ”scanning” requires heaps of money, this is going to kill off a substantial part of F/OSS.

Well, maybe not... see Simon Willison's ongoing reporting [0] on all the bug reports for `curl` people are finding with LLMs. Interesting to see them go from "DON'T GIVE US AI SLOP!" to "Wow, lots of actual bugs found, including [ed: at least one] bug found by two people!" [0]: https://simonwillison.net/search/?q=curl

curl is both very high-profile and very security-central though. A lot of people would happily pay $100 to tuck "found a curl vulnerability" under their belt. I'm not sure that's even true for, say, Notepad++, much less all the random FOSS projects with 1 maintainer and 50 stars whose names I've never thought about twice.

Re: Assessing Claude Mythos Preview's cybersecurity capabilities

#35

Since this level of security ”scanning” requires heaps of money, this is going to kill off a substantial part of F/OSS.

Keep in mind that Opus detected most of these vulnerabilities, it just didn’t exploit them (says so much in the article).

I’m honestly not convinced this is changing the landscape significantly. It’s simple a bit better at self directing.

Re: Assessing Claude Mythos Preview's cybersecurity capabilities

#36
post #21

The elephant in the room here is that there are hundreds of millions of embedded devices that cannot be upgraded easily and will be running vulnerable binaries essentially forever. This was a problem before of course, but the ease of chaining vulnerabilities takes the issue to a new level. The only practical defense is for these frontier models to generate _beneficial_ attacks to innoculate older binaries by remote e…

> The only practical defense is for these frontier models

Another practical defence for many of these devices would be to just disconnect them... I feel like an old man yelling at a cloud, but too much is connected to the Internet these days.

Re: Assessing Claude Mythos Preview's cybersecurity capabilities

#37
post #20

Related ongoing threads: System Card: Claude Mythos Preview [pdf] - https://news.ycombinator.com/item?id=47679258 Project Glasswing: Securing critical software for the AI era - https://news.ycombinator.com/item?id=47679121 I can't tell which of the current threads, if any, should be merged - they all seem significant. Anyone?

Would vote to keep them separate. They seem independent enough to warrant their own discussion based only (or rather, mostly) on the content from each link. edit: merging this and glasswing as underdeserver stated would probably be fine

Re: Assessing Claude Mythos Preview's cybersecurity capabilities

#38
post #36
post #21

The elephant in the room here is that there are hundreds of millions of embedded devices that cannot be upgraded easily and will be running vulnerable binaries essentially forever. This was a problem before of course, but the ease of chaining vulnerabilities takes the issue to a new level. The only practical defense is for these frontier models to generate _beneficial_ attacks to innoculate older binaries by remote e…

> The only practical defense is for these frontier models Another practical defence for many of these devices would be to just disconnect them... I feel like an old man yelling at a cloud, but too much is connected to the Internet these days.

It can be easier to hack the device and patch it than determine which device it is. This is nearly always true for the non-technical, but it is true for most technical people as well. Many of the devices in peoples homes that aren't being actively patched are not that old!

Re: Assessing Claude Mythos Preview's cybersecurity capabilities

#39

I'd love to see them point at a target that's not a decades old C/C++ codebase. Of the targets, only browsers are what should be considered hardened, and their biggest lever is sandboxing, which requires a lot of chained exploits to bypass - we're seeing that LLMs are fast to discover bugs, which means they can chain more easily. But bug density in these code bases is known to be extremely high - especially the under…

I'd love for them to target their own code base considering we keep seeing security vulnerabilities in claude code.

How likely is it that they're not using their latest and greatest for their own projects though? Perhaps their ability to find security flaws is surpassed by their ability to create them.

Re: Assessing Claude Mythos Preview's cybersecurity capabilities

#40
post #21

The elephant in the room here is that there are hundreds of millions of embedded devices that cannot be upgraded easily and will be running vulnerable binaries essentially forever. This was a problem before of course, but the ease of chaining vulnerabilities takes the issue to a new level. The only practical defense is for these frontier models to generate _beneficial_ attacks to innoculate older binaries by remote e…

[flagged]
Post reply on HN