Search
Items tagged with: cve
Put yourself in Jia Tan's shoes, the malicious contributor to the xz backdoor...
It's been, what, two... three?... years since you started this campaign. You've had the entire support of your team and of your chain of command.
Your coders created a complex and sublime backdoor. A secure! backdoor that only you and your team could connect to. Heck it can even be deleted remotely. This is clean code. A responsible hack that doesn't open up the backdoor for others to hijack.
You spend years on your long con - your social engineering skills are at the top of the game. You've ingratiated yourself painstakingly into multiple teams. Finally it all pays off and you're ready to go!
You succeed multiple times in getting your backdoor inserted in all the major Linux distributions!!! Now its just a matter of weeks before it makes it to production and stable releases!
This is the culmination of years of labor and planning and of a massive team and budget.
You did good.
This will get you promoted. Esteemed by your colleagues and leadership alike. Your spouse and kids will understsnd why you haven't been at home lately and why you've spent all those late nights at the office.
It's finally going to pay off.
But what's this?! Some rando poking around in their box running a pre-release unstable version of linux has found everything?!?! It's all being ripped down?! And on a Friday before a western holiday weekend?!?!
Fuck. Fuck. FUCK!!!
Three years for nothing!!! My wife is going to leave me! I missed my kid's recital for this!!! They'll hate me because I told them it was worth it. Daddy will be able to play with you again once Daddy finishes this last bit of work. But it was all for nothing!!!
Leadership took a big risk on me and my team but I kept assuring them it would pay off!
It would be one thing if another nation state found it and stopped it. But one random dude poking his nose where it shouldn't belong?! Ohhh fuck, I'm going to be fired. We're going to lose our budget. My team is going to be fired. I've let down everyone that ever believed in me and supported me and relied on me!
Oh fuck!!!
#xz #backdoor #xzBackDoor #cve #cve20243094 #infosec #hacking #FOSS
I think a LOT of people are missing the fact that we got LUCKY with this malicious backdoor.
The backdoor was created by an Insider Threat - by a developer / maintainer of various linux packages. The backdoor was apparently pushed back on March 8th (I believe) and MADE IT PAST all QA checks.
Let me state that again. Any quality assurance, security checks, etc., failed to catch this.
This was so far upstream, it had already gotten into the major Linux distributions. It made it into Debian pre-release, Fedora rolling, OpenSUSE rolling, Kali rolling, etc.
This is an example of Supply Chain Security that CISOs love to talk and freak out about. This is an example of an Insider Threat that is the boogey man of corporate infosec.
A couple more weeks, and it would have been in many major distributions without any of us knowing about it.
The ONLY reason we know about it is because @AndresFreundTec got curious about login issues and some benchmarking checks that had nothing to do with security and ran the issue down and stumbled upon a nasty mess that was trying to remain hidden.
It was luck.
That's it. We got lucky this time.
So this begs the question. Did the malicious insider backdoor anything else? Are they working with anyone else who might have access to other upstream packages? If the QA checks failed to find this specific backdoor by this specific malicious actor, what other intentional backdoors have they missed?
And before anyone goes and blames Linux (as a platform or as a concept), if this had happened (if it HAS happened!!!) in Windows, Apple, iOS, etc.... we would not (or will not) know about it. It was only because all these systems are open source that Andres was able to go back and look through the code himself.
Massive props and kudos and all the thank yours to Andres, those who helped him, to all the Linux teams jumping on this to fix it, and to all the folks on high alert just before this Easter weekend.
I imagine (hope) that once this gets cleaned up, there will be many fruitful discussions around why this passed all checks and what can be changed to prevent it from happening again.
(I also hope they run down any and all packages this person had the signing key for....)
Two years ago I chased a ghost #curl #CVE that Apple invented: https://daniel.haxx.se/blog/2022/03/23/anatomy-of-a-ghost-cve/
Fun times.
OK #vulnerability nerds
With the current state of #NVD, there is a need to fill the gap right now. It's expected that anything new happening is going to take months or years, which is longer than the world can wait
Anchore has an open source project we're currently calling "NVD Data Overrides" (naming things is hard)
https://github.com/anchore/nvd-data-overrides/
We're working on adding the same type of thing NVD used to do to the #CVE data. The data is licensed CC0, anyone can use it for anything.
The data repo currently has over 500 enriched IDs (there's a lot more to do, but this is how it starts).
If you're interested in this sort of thing please come help. The vulnerability world is now so big we need to cooperate the same way open source works, nobody can do this alone anymore
GitHub - anchore/nvd-data-overrides
Contribute to anchore/nvd-data-overrides development by creating an account on GitHub.GitHub
I'm convinced someone just grepped commit messages for this and submitted a #CVE and there was nothing and no one that even tried to confirm or check that this was actually legitimate. There was no filter in place and it was incorrectly let through. That's why it should be rejected. Saying it is "disputed" hints that there can be different views on this subject.
So, you are asking me to explain how this not identified vulnerability is actually not identifying a vulnerability.
Hello #MITRE, (regarding CVE-2023-52071)
Well, first I of course think that the "burden of proof" would be on the person that insists that there is a problem. The one saying that this is a #CVE should provide the necessary details to explain "beyond reasonable doubt" that the identified problem is a vulnerability. There are no such details or explanations provided in the existing CVE. There is nothing there that identifies a vulnerability.
If you're a #Mastodon admin, you're going to want to apply the latest security patch as soon as possible.
curl is now a CVE Numbering Authority (CNA) assigning CVE IDs for all for all products made and managed by the curl project. This includes curl, libcurl, and trurl.
https://cve.org/Media/News/item/news/2024/01/16/curl-Added-as-CNA
#CVE #CNA #VulnerabilityManagement #Vulnerability #Cybersecurity
https://daniel.haxx.se/blog/2023/10/11/how-i-made-a-heap-overflow-in-curl/
“””
In hindsight, shipping a heap overflow in code installed in over twenty billion instances is not an experience I would recommend.
“””
Fantastic write up by @badger about the #curl #cve . I can’t imagine dealing with this sort of stress! But as a consumer of the internet I am very grateful for his contributions.
“””
Everyone not happy about this are of course welcome to roll up their sleeves and get working.
“””
This is such a good quote… I may borrow this one
100% agreed that the CVSS scoring system and "assume the worst" guidance makes for scores that do not accurately reflect importance. Especially for very broad-use things.
My take on this is that. like it or not, more open source projects of note need to become "CNA" (certificate numbering authorities) of their own which I understand can given them some control over the content of CVEs filed against their project. https://www.cve.org/ProgramOrganization/CNAs