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.
>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.
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.
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!
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.
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.
>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.
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...
[2] https://news.ycombinator.com/item?id=48139219