You can run 1960s System/360 binaries unmodified on modern z/OS. The system also uses a lot of "high level assembler" and "system provided assembly macros" making a complete architecture switch extremely painful and complicated.
They called their new architecture "ESAME" for a while for a pretty obvious reason.
It's fdac::1. If you're using random 48 bit or 64 bit numbers in your IP address you're doing it wrong.
I have zero concerns that the IPv6 namespace for my home network will conflict with another administrative site during a merger. So.. it works great. Also super handy when the DNS resolver for my local network is down because of power outages or other unrelated failures.
It's not a fake quote. It's an extreme distillation of the apparent core of your argument. It's how it appears to me. It's related to what you wrote in that someone read it and came away with that conclusion.
Those CVEs seem a little more subtle than OID serialization issues. In the first example there are actually two distinct problems in concert that lead to the vulnerability, one of which is when a "low public exponent" is used.
This is Bleichenbacher's rump-session e=3 RSA attack. It's pretty straightforward, and is in Cryptopals if anyone wants to try it. If you don't check all the RSA padding, and you use e=3, you can just take an integer cube root.
It seems like in that PR, the fact that the OID wasn't checked is part of the problem. I think a better system wouldn't compile or would always fail to verify if the OID (domain separator) is wrong, and I think you'd get that behavior in the posted system.
Letting Claude get at the source code to try to find CVEs. I found it particularly entertaining that after finding none it just devolved to a grep for "strcat."
Oh, I see. No, you're wrong. That's absolutely not what it did and not at all an accurate way to sum up what it found.
This isn't a complete rebuttal to your argument but I'll note with irony that we're commenting on a thread about a FreeBSD kernel remote that Claude both found and wrote a reliable exploit for (though people will come out of the woodwork to say that reliable exploitation of FreeBSD kernel remotes isn't much of a flex).
Here, from the exact tranche of vulnerabilities you're saying was just a "grep for strcat", are the Firefox findings:
We're getting to a point, like we did with coding agents last year, where you can just say "I believe my lying eyes". Check out a repository and do Carlini's "foreach FILE in $(sourcefiles); <run claude -p and just ask for zero days starting from that file>". I did last night, and my current dilemma is how obligated I am to report findings.
It's from the link I posted. Claude's own team in January trying to do exactly what you suggested and ending with results that are less than promising. It's their blog. I assumed it represented the pinnacle of their research.
We're getting a point where anecdotes are being used in place of reason. I'd think you want to ask "how many bug bounties are earned by humans vs AI assistants?" If there's money to be made in finding 0-days then shouldn't there be ample evidence of this?
No. I can't. That's the point. You've not disclosed what you've done, the link you provided contains locked disclosures I can't access but which appear all to be submitted by humans, and the article itself contains a giant problem, it didn't discover anything, it merely crafted a POC from an existing CVE.
Which is why I'm confused. A limited number of particular people say there's this giant sea change. I cannot find any hard evidence that's true.
If anthropic blog was trying to _sell me_ on their service they failed miserably. So I guess my assumption can, at least, safely be, they have no idea how to market their own product.
The Firefox team has acknowledged the vulnerabilities, which are obviously not "greps for strcat" as you claimed. I mean, you've been refuted; I don't really understand what the argument is supposed to be at this point.
How did you managed to get it to do that? When I gave it instructions to use Ghidra MCP to look for vulnerabilities in a windows driver on my local machine it refused saying it's not allowed to do pentest activities even if sandboxed to your own device.
Not who you were asking and not explicitly looking for vulnerabilities... I have gotten a ton of mileage from getting Claude to reverse engineer both firmware and applications with Ghidra and radare2. My usual prompt starts with "Here's the problem I'm having [insert problem]. @foo.exe is the _installer for the latest firmware update_. Extract the firmware and determine if there's a plausible path that could cause this problem. Document how you've extracted the firmware, how you've done the analysis, and the ultimate conclusions in @this-markdown-file.md"
I have gotten absolutely incredible results out of it. I have had a few hallucinations/incorrect analyses (hard to tell which it was), but in general the results have been fantastic.
The closest I've come to security vulnerabilities was a Bluetooth OBD-II reader. I gave Claude the APK and asked it to reverse engineer the BLE protocol so that I could use the device from Python. There was apparently a ton of obfuscation in the APK, with the actual BLE logic buried inside an obfuscated native code library instead of Java code. Claude eventually asked me to install the Android emulator so that it could use https://frida.re to do dynamic instrumentation instead of relying entirely on static analysis. The output was impressive.
They called their new architecture "ESAME" for a while for a pretty obvious reason.
reply