HN user
Oh hey, this is our work! We helped Anthropic analyze and report this bug.
For the record, this bug has nothing to do with our recent MIE attack [1] [2], which exploited two different kernel bugs. Our bugs are not fixed yet.
[1] https://blog.calif.io/p/first-public-kernel-memory-corruptio...
Nope. Try the PoC on macOS:
https://github.com/califio/publications/blob/main/MADBugs/fr...
The script downloads and sets up FreeBSD on QEMU, then runs the exploit.
The exploit is very smart: https://github.com/califio/publications/blob/main/MADBugs/fr.... It basically backdoors sshd.
You're always super kind to me :)
Nice to randomly encounter our own work here.
Check out our blog post for a fun walkthrough: https://blog.calif.io/p/cve-2026-7270-how-i-get-root-on-free...
AI-generated working exploit, write-up and prompts: https://github.com/califio/publications/tree/main/MADBugs/fr...
The feature is enabled by default. You can test it by yourself.
This is a good title, thanks! There was iTerm2 in the original title, but it overflowed to the subtitle in Substack.
I've now updated the blog post.
Disclosure: I didn't discover the vulnerability. I wrote the blog post.
Thanks for releasing a fix!
It was surprising that there wasn't an official release, even though the bug impacts otherwise routine, harmless workflows. The patch itself [1] framed the issue as "hypothetical," so the goal of the blog post was to demonstrate that it is not. I'm glad that you've agreed to release a fix.
[1] https://github.com/gnachman/iTerm2/commit/a9e745993c2e2cbb30...
Disclosure: I didn't discover the vulnerability. I wrote the blog post.
The author was able to develop an exploit by prompting an LLM with just the upstream commit
Yes, I was able to do this. I believe anyone watching iTerm2's commits would be able to do this too.
but I still think this blog post raises the visibility of the vulnerability.
Yes, I wanted to raise the visibility of the vulnerability, and it works!
The author of iTerm2 initially didn’t consider it severe enough to warrant an immediate release, but they now seem to have reconsidered.
Key point is that Claude did not find the bug it exploits.
It found the bug man. You didn't even read the advisory. It was credited to "Nicholas Carlini using Claude, Anthropic".
But you would expect running "git status" or "git ls-files" in the unzipped directory to completely pwn your system? Probably not either.
That’s fair, but it would be pretty unusual for me to run Git commands in a directory I’m not actively working on. On the other hand, I open files from random folders all the time without really thinking about it, so that scenario feels much more realistic.
I think we can agree that Git is at least partly responsible for this issue, if not more.
That said, even being aware of that doesn’t necessarily help much in practice. When you’re using Emacs or Vim, you’re not really thinking about Git at all. You’re just opening and editing files. So it’s not obvious to most users why Git would be relevant in that context.
This is why I think editor maintainers should do more to protect their users. Even if the root cause sits elsewhere, users experience the risk at the point where they open files. From their perspective, the editor is the last line of defense, so it makes sense to add safeguards there.
Yes, likely. And git is not going to fix it. So isn't it fair to expect the editor maintainers to do something about it, to protect their users, no?
Disclosure: I didn’t discover the bugs, but helped write the blog post.
These issues are technically classified as local code execution (AV:L), but they go against a pretty strong user expectation: that opening a file should be safe. In reality, they can be triggered through very common workflows like downloading and opening files, which makes them feel a lot closer to some remote scenarios, even if they’re not strictly RCE.
At the end of the day, regardless of how you classify them, it’s worth being aware of the risks when opening untrusted files in editors like Vim or Emacs.
When I wget a tarball, unzip, and emacs a.txt inside, I don't expect that it'd execute arbitrary commands.
I think people should be aware of this risk, especially when it looks like it's not getting fixed.
Disclosure: I didn't find the bugs. I helped wrote the blog post.
Thanks for sharing. I'm one of the co-authors of the blog post. Let me know if you have any questions!
tl;dr: We analyzed a LockBit v3 variant, and rediscovered a bug that allows us to decrypt some data without paying the ransom. We also found a design flaw that may cause permanent data loss. Nothing's earth-shattering, but it should be a fun read if you're into crypto and security!
It really is turned off. Companies like Google get huge fines when they break their promise -- even accidentally.
You can use Google Search and tell Google not to log your search history or use the data for advertising purposes. See my comment [1] for how to turn on these privacy controls.
Google provides decent security/privacy controls, see my comment on how to turn them on [1].
If you have any specific concerns, I'd love to learn more and see if there's anything I can help.
If you want to keep using Google services, here are some Google Alternatives Alternatives:
1/ Google Search, YouTube, Maps: visit https://myactivity.google.com/activitycontrols to turn on auto-deletion or turn off search history, location history or YouTube watch history. This page also allows you to turn off ads personalization. There are many security and privacy controls on https://myaccount.google.com/, turn them on however you see fit.
2/ Chrome: visit chrome://settings/syncSetup to turn off Chromesync, disallow Chrome sign-in, disable automcomplete searches and URLs, etc. You can also change the default search engine to something else, but see point 1/ if you want to use Google Search. Use Incognito mode more often.
3/ Gmail, Photos, Calendar, Drive, Docs: "we don’t use information in apps where you primarily store personal content—such as Gmail, Drive, Calendar and Photos—for advertising purposes, period." [1] In other words, Gmail, YouTube or Search ads are not targeted or personalized using your emails, photos, events, docs, etc.
Disclosure: I'm a Google's security engineer, advocating for and contributing to some of the aforementioned security/privacy controls.
[1] https://blog.google/technology/safety-security/keeping-priva...
Crypto is hard because you don't get quick feedback on whether you are doing well.
Well said.
If you are to implement a sorting algorithm, you'll know immediately whether it works or is fast enough. Crypto doesn't provide this feedback. It's important to get help from others, if you can't tell yourself whether your code works.
I wrote this article to encourage people to study the field I love. If I wanted to tell people to back off, why would I bother providing advice, material and telling people to have fun?
Those rules aren't easy to follow, but they are simple to know about.
If the rules were so simple, how come your library had a signature bypass vulnerability that you did NOT understand its root cause until I explained?
The root cause looks deceptively simple, until you take your time to understand the underlying math. I didn't fully understand it until a professor at MIT explained it to me. Maybe it's just that I'm stupid, but it is never simple to me.
About not using your crypto until it's been vetted by professionals… How do you get those vaunted professionals to even look at your work?
You can't expect people to pay attention to your work until you earn it. Why would anyone bother reviewing a random library from a random dude? Frank of libsodium fame didn't start by writing a brand new library from scratch, but built it on top of NaCl. If he did that, nobody would take him seriously either.
About CTF (Capture The Flag), and cryptopal challenges, my advice is: don't waste your time. The penetration testing approach to secure systems does not work. You whack a mole, two more appear. We need ways to prevent whole classes of errors, like proofs. For instance, tools like https://verifpal.com/ can be a great help when designing a protocol.
This was how my friends and I got started. Maybe you were right that it isn't worth it, but it helps get us to where we are, being paid to do security and crypto.
There are two approaches to learning: top down or bottom up.
The former is what you get at university. If you want to learn crypto, you have to learn abstract algebra, linear algebra, probability theory, complexity theory, and computer security. If you want to learn complexity theory, you want to learn automata theory, computability theory, and algorithms. If you want to learn computer security, you want to learn computer architecture, operating systems, networking, etc.
The top down approach is systematic, but it might not prepare you for the real world. For that, you need internships and CTFs. They are reality checks with a fast feedback loop, showing you very quickly which skill or knowledge you are lacking or need improvement. They are also fun.
I of course agree with all of this, but as someone pretty much at the bottom of the food chain who just wants to encrypt some data, there's often no libraries that safely glue the primitives together in the way that I require.
I hope this doesn't come off as entitled, but I feel like the best way to get people to stop rolling their own crypto is to provide more/better libraries.
Author here. I mentioned libsodium [1] and Tink [2]. We started Tink because we want to provide more/better libraries.
Granted, this is getting better, for example NaCl's crypto_box[0] is awesome and very hard to misuse. But say you want forward secrecy now. chirp, tumbleweed.
It looks like you want to build an interactive protocol. I'm not sure if libsodium has a solution, but Tink doesn't. So far we've been focusing on encryption at rest. Can you tell me more about your use case?
I'll tell you next time we meet ;-)
For example, let's look at the IV.
Symmetric encryption algorithms usually need an input called the initialization vector (IV), but different algorithms have different requirements.
AES-CBC requires unpredictability, but AES-CTR (and AES-GCM) require uniqueness. Misunderstanding of these requirements have led to real world attacks, see for example BEAST or https://eprint.iacr.org/2016/475.pdf.
Or was it that they were trying to use low level APIs in OpenSSL to create some higher-level cryptosystem they perhaps didn’t fully understand?
Yes. They wanted to encrypt some URL parameters with AES-ECB.
Author here, ask me anything.
The last vulnerability [1] is super cool, as it allows to decrypt AES-GCM ciphertexts using an AES-CBC padding oracle!
The exploit is very efficient and fits in a tweet:
1. Take C = E(K, IV) \xor P from GCM encryption
2. Make a guess of P, send (IV \ xor PADDING) || (C \xor P_guess) to the CBC oracle where PADDING is a fixed constant. If the oracle returns that the padding is correct, P_guess is correct. Otherwise make another guess.
The root cause of the issue runs pretty deep. It's a class of crypto vulnerabilities we called "in-band protocol negotiation". That is, the ciphertext contains protocol-related parameters that determine how it should be decrypted. The JWT standard has this issue, which has led to countless "alg": "none" vulnerabilities. JWT is not alone, this mistake is presented in many other libraries or standards.
I wrote about how we avoid this issue in Tink [2] [3]:
2/ A key in Tink contains not only the raw key material, but also all necessary parameters. It is equivalent to the result of a handshake. Before any data encryption can take place, both sides have to reach an agreement not only on a raw key, but also how to use that key to encrypt data. Since a key in Tink contains all parameters, Tink does not require in-band ciphersuite negotiation. That is no ciphertext in Tink contains any other metadata aside from a key ID.
This design sounds so simple but I've seen people get this wrong all the time. For example, the root cause of many embarrassing vulnerabilities in JWT [1] is in-band ciphersuite negotiation. That is, a JWT contains an alg field that dictates how the receiver should process it. This alg field should rather be included as part of the key.
JWT is not the only standard making this mistake. Many crypto libraries only ask users for the raw key material. This means the parameters are either implicitly assumed or under specified. Aside from the aforementioned vulnerabilities, this can also lead to key confusion, cross-protocol key reuse and make it hard to rotate keys or change algorithms.
To the best of my knowledge, Tink is the only high-level library that gets this right.
[1] https://github.com/google/security-research/security/advisor...
It's coming and will be part of 1.4.0: https://github.com/google/tink/issues/358.
We have a test package for Linux with Python 3.7 or 3.8
pip3 install -i https://test.pypi.org/simple/ tink
Disclaimer: I'm a maintainer of Tink.
From a user's point of view, keys are still binary blob. Internally Tink serializes keys using protobuf, but in principle it supports arbitrary key formats via the KeysetReader/KeysetWriter interfaces. Admittedly, this aspect of our design is somewhat clumsy. We're working on a new design.
The key differences (pun intended) between Tink and other libraries are:
1/ Tink works with keysets instead of individual keys. This enables key rotation and crypto agility. This is very important at Google because there are systems that generate too much data to encrypt with a single key. We want to be able to rotate keys and still be able to decrypt old ciphertext.
Also most crypto schemes we're using today would be broken eventually. We want to make sure we can add new schemes and retire old ones over time without users having to change their code. For example, a lot of libraries have functions containing algorithm names, e.g., aes_gcm_encrypt. When GCM is no longer adequate, users of these libraries would have a hard time upgrading to alternatives.
Tink interfaces don't contain the algorithm name. We name our APIs after generic crypto primitives rather than famous cryptographers or algorithms. For example, we provide a generic AEAD interface for symmetric key encryption. With proper key management, users don't have to know anything about any particular algorithms and can easily rotate to new ones without changing a single line of code (rather than upgrading Tink).
2/ A key in Tink contains not only the raw key material, but also all necessary parameters. It is equivalent to the result of a handshake. Before any data encryption can take place, both sides have to reach an agreement not only on a raw key, but also how to use that key to encrypt data. Since a key in Tink contains all parameters, Tink does not require in-band ciphersuite negotiation. That is no ciphertext in Tink contains any other metadata aside from a key ID.
This design sounds so simple but I've seen people get this wrong all the time. For example, the root cause of many embarrassing vulnerabilities in JWT [1] is in-band ciphersuite negotiation. That is, a JWT contains an alg field that dictates how the receiver should process it. This alg field should rather be included as part of the key.
JWT is not the only standard making this mistake. Many crypto libraries only ask users for the raw key material. This means the parameters are either implicitly assumed or under specified. Aside from the aforementioned vulnerabilities, this can also lead to key confusion, cross-protocol key reuse and make it hard to rotate keys or change algorithms.
To the best of my knowledge, Tink is the only high-level library that gets this right.
[1] https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
Disclaimer: I'm one of the maintainers of Tink.
I'm not sure if NaCl itself is production ready, but I'm a great fan of libsodium. If I weren't working on Tink, I'd use libsodium for my personal projects. Did you know that Frank Denis [1] the creator of libsodium is not working full time on crypto or security? He's a professional photographer. I can't figure out how he manages to single-handedly maintain such a high-profile high-quality library as a side project. We have a team of full time cryptographers and engineers working on Tink, but we've struggled a lot.
We started Tink because all existing libraries that we had at Google didn't meet our requirements.
Business-wise, we need an open source library that can work on all major platforms that Google products run on including web, iOS, Android, Borg and GCP. There are many Google products that need crypto integration with external partners. While we can take care of the crypto implementation on our side, we found that many partners got it wrong. It'd be very nice if they can use the same library that we're using internally.
We learned very early that a single ciphersuite wouldn't work for everybody. Some would need short ciphertext. Some would need speed. Some would need FIPS certified. We want a library that can support a wide range of options. It should be easy to add new options and remove old ones.
Security-wise, we found that most libraries are either too high-level or too low.
The latter ask users for security-critical input such as nonces or randomness. In most crypto schemes, using a wrong kind of nonces can totally break an otherwise secure scheme. Based on our experience working with tens of thousands of engineers at Google, we found that most engineers can't tell why the IV must be non-repeated in some schemes but unpredictable in others. More importantly, we found that this level of control is not needed when using crypto to implement security/privacy features in most of our products. Tink aims to eliminate as many potential misuses as possible. For example, if the underlying encryption mode requires nonces and is insecure if nonces are reused, then Tink does not allow the passing of nonces by the user.
Why is too high-level also a bad idea? We found that many libraries provide a single API for different kinds of crypto primitive. For example, sign() is used for both MAC and digital signatures, and encrypt() for both AEAD and public key encryption. This reduces readability, making code review much harder because the crypto APIs can't provide accurate information on the security guarantees of the implementations.
Last but not least, Tink encourages the usage of key management system. Most libraries don't care where the keys come from, and as a result many users use hardcoded keys. Tink encourages developers to store keys encrypted or within a KMS. It provides security teams mechanisms to enforce this requirement. For example, at Google developers can't use Tink in production with keys stored outside our KMS, unless they got an explicit approval from us.
Further explanations of these design goals can be found in [2].
To wrap this up, IMHO libsodium and Tink are targeting different groups of audience. libsodium is great for personal projects, when you know what you're doing and can take care of yourself. Tink provides more bells and whistles which are useful when you want to do crypto in an enterprise setting.
[1] https://00f.net/
[2] https://github.com/google/tink/blob/master/docs/SECURITY-USA...