> If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released.
Reading that in a different light, it says give me time to adjust my exploits and capitalize on any targets. Makes me wonder what other vulns might exist in the author's other projects.
It's a SEVERE issue, to my mind, and 90 days seems too long to me.
This situation is perhaps a little different as its not an accidental bug waiting to be discovered but an intentionally placed exploit. We know that a malicious person already knows about it.
But in the general case, it's normal for 90 days to be given for the coordinated patching of even very severe vulnerabilities -- you are giving time not just to the project maintainers, but to the users of the software to finish updating their systems to a new fixed release, before enough detail to easily weaponize the vulnerability is shared. Google Project Zero is an example of a team with many critical impact findings using a 90-day timeline.
My customers and business are not any less important or valuable than anyone else's, and I should not be left being potentially exploited, and my customers harmed, for 90 more days while the big guys get to patch their systems (thinking of e.g. Log4J, where Amazon, Meta, Google, and others were told privately how to fix their systems, before others were even though the fix was simple).
Likewise, as a customer I should get to know as soon as someone's software is found vulnerable, so I can then make the choice whether to continue to subject myself to the risk of continuing to use it until it gets patched.
Plainly untrue. The reason they keep distribution minimal is to maximise the chance of keeping the vuln secret. Your business is plainly less valuable than google, than walmart, than godaddy, than BoA. Maybe you're some big cheese with a big reputation to keep, but seeing as you're feeling excluded, I guess these orgs have no more reason to trust you than they have to trust me, or hundreds of thousands of others who want to know. If they let you in, they'd let all the others in, and odds are greatly increased that now your customers are at risk from something one of these others has worked out, and either blabbed about or has themselves a reason to exploit it.
Similarly plainly, by disclosing to 100 major companies, they protect a vast breadth of consumers/customer-businesses of these major companies at a risk of 10,000,000/100 (or even less, given they may have more valuable reputation to keep). Changing that risk to 12,000,000/10,000 is, well, a risk they don't feel is worth taking.
The company I work for has a market cap roughly 5x that of goDaddy and we're responsible for network connected security systems that potentially control whether a person can physically access your home, school, or business. We were never notified of this until this HN thread.
If your BofA account gets hacked you lose money. If your GoDaddy account gets hacked you lose your domain. If Walmart gets hacked they lose... What money and have logistics issues for a while?
Thankfully my company's products have additional safeguards and this isn't a breach for us. But what if it was? Our customers can literally lose their lives if someone cracks the security and finds a way to remotely open all the locks in their home or business.
Don't tell me that some search engine profits or someone's emails history is "more valuable" than 2000 schoolchildren's lives.
How about you give copies of the keys to your apartment and a card containing your address to 50 random people on the streets and see if you still feel that having your Gmail account hacked is more valuable.
None of the points you make are relevant since I have yet to see any software based entry product whose software security can be concidered more than lackluster at best, maybe your company is better since you didn't mention a name I can't say otherwise.
What I'm saying is your customers are more likely to have their doors physically broken than remotely opened by software and you are here on about life and death because of a vuln in xz?
If your companies market cap is as high as you say and they are as security aware as you say why aren't they employing security researchers and actively on the forefront of finding vulns and reporting them? That would get them an invite to the party.
The think of the children part is a nice touch as well. 10/10 copypasta would repost.
Keep in mind it's the EROI not market cap.
A company is worth attacking if their reward:effort ratio is right. Smaller companies have a much lower effort required.
You do get to know that the vulnerability exists quickly, and you could choose to stop using OpenSSL altogether (among other mitigations) once that email goes out.
Also, if something is being actively exploited, usually there's no or very little embargo.
But I don't want anyone else to get notified immediately because the odds that somebody will start exploiting people before a patch is available is pretty high. Since I can't have both, I will choose the 90 days for the project to get patches done and all the packagers to include them and make them available, so that by the time it's public knowledge I'm already patched.
I think this is a Tragedy of the Commons type of problem.
Caveat: This assume the vuln is found by a white hat. If it's being exploited already or is known to others, then I fully agree the disclosure time should be eliminated and it's BS for the big companies to get more time than us.
Of course they are. If Red Hat has a million times more customers than you do then they are collectively more valuable almost by definition.
a. Use commercial OS vendors who will push out fixes.
b. Set up a Continuous Integration process where everything is open source and is built from the ground up, with some reliance on open source platforms such as distros.
One needs different types of competence and IT Operational readiness in each approach.
How would that have prevented this backdoor?
Though anything actually potentially lethal shouldn't really have a standard Internet connection. E.g. nuclear power plants, trains, planes controls, heavy industrial equipment, nuclear weapons...
Hate to break it to you but yes they are.
Is there "a new fixed release" ?
If it's a large company, made of people with names and faces, with a lot to lose by hacking its users, they're unlikely to abuse private disclosure. If it's some tiny library, the maintainers might be in on it.
Also, if there's evidence of exploitation in the wild, the embargo is a gift to the attacker. The existence of a vulnerability in that case should be announced, even if the specifics have to be kept under embargo.
But why? A year is a ridiculous time for fixing a vulnerability even a minor one. If a vendor is taking that long its because they don't prioritize security at all and are just dragging their feet.
That said, this is an important question. We, particularly those us who work on critical infrastructure or software, should be asking ourselves this regularly to help prevent this type of thing.
Note that it's also easy (and similarly catastrophic) to swing too far the other way and approach all unknowns with automatic paranoia. We live in a world where we have to trust strangers every day, and if we lose that option completely then our civilization grinds to a halt.
But-- vigilance is warranted. I applaud these engineers who followed their instincts and dug into this. They all did us a huge service!
EDIT: wording, spelling
The current situation is ridiculous - if I pull in a compression library from npm, cargo or Python, why can that package interact with my network, make syscalls (as me) and read and write files on my computer? Leftpad shouldn’t be able to install crypto ransomware on my computer.
To solve that, package managers should include capability based security. I want to say “use this package from cargo, but refuse to compile or link into my binary any function which makes any syscall except for read and write. No open - if I want to compress or decompress a file, I’ll open the file myself and pass it in.” No messing with my filesystem. No network access. No raw asm, no trusted build scripts and no exec. What I allow is all you get.
The capability should be transitive. All dependencies of the package should be brought in under the same restriction.
In dynamic languages like (server side) JavaScript, I think this would have to be handled at runtime. We could add a capability parameter to all functions which issue syscalls (or do anything else that’s security sensitive). When the program starts, it gets an “everything” capability. That capability can be cloned and reduced to just the capabilities needed. (Think, pledge). If I want to talk to redis using a 3rd party library, I pass the redis package a capability which only allows it to open network connections. And only to this specific host on this specific port.
It wouldn’t stop all security problems. It might not even stop this one. But it would dramatically reduce the attack surface of badly behaving libraries.
It is hijacking a process that has network access at runtime not build time.
The build hack grabs files from the repo and inspects build parameters (in a benign way, everyone checks whether you are running on X platform etc)
Another way of thinking about the problem is that right now every line of code within a process runs with the same permissions. If we could restrict what 3rd party libraries can do - via checks either at build time or runtime - then supply chain attacks like this would be much harder to pull off.
I agree that it wouldn’t stop this library from injecting backdoors into decompressed executables. But I still think it would be a big help anyway. It would stop this attack from working.
At the big picture, we need to acknowledge that we can’t implicitly trust opensource libraries on the internet. They are written by strangers, and if you wouldn’t invite them into your home you shouldn’t give them permission to execute arbitrary code with user level permissions on your computer.
I don’t think there are any one size fits all answers here. And I can’t see a way to make your “tainted output” idea work. But even so, cutting down the trusted surface area from “leftpad can cryptolocker your computer” to “Leftpad could return bad output” sounds like it would move us in the right direction.
And by scratch I mean "without modern hardware" given supply chain attacks also apply to the hardware you build from.
We (obviously) put too much trust in little libraries like xz. I don't see a world in which people start using fewer dependencies in their projects. So given that, I think anything which makes 3rd party dependencies safer than they are now is a good thing. Hence the proposal.
The downside is it adds more complexity. Is that complexity worth it? Hard to say. Thats still worth talking about.
there are some researches on the right track already https://www.se.cs.uni-saarland.de/projects/congruence/
The goal is to restrict what included libraries can do. As you say, in languages like Rust, Go or Swift, the mechanism to do this would also need to work with statically linked code to work. And thats quite tricky, because there are no isolation boundaries between functions in executables.
It should still be possible to build something like this. It would just be inconvenient. In rust, swift and go you'd probably want to implement something like this at compile time.
In rust, I'd start by banning unsafe in dependencies. (Or whitelisting which projects are allowed to use unsafe code.) Then add special annotations on all the methods in the standard library which need special permissions to run. For example, File::open, fork, exec, networking, and so on. In cargo.toml, add a way to specify which permissions your child libraries get. "Import serde, but give it no OS permissions". When you compile your program, the compiler can look at the call tree of each function to see what actually gets called, and make sure the permissions match up. If you call a function in serde which in turn calls File::open (directly or indirectly), and you didn't explicitly allow that, the program should fail to compile.
It should be fine for serde to contain some utility function that calls the banned File::open, so long as the utility function isn't called.
Permissions should be in a tree. As you get further out in the dependency tree, libraries get fewer permissions. If I pass permissions {X,Y} to serde, serde can pass permission {X} to one of its dependencies in turn. But serde can't pass permission {Q} to its dependency - since it doesn't have that capability itself.
Any libraries which use unsafe are sort of trusted to do everything. You might need to insist that any package which calls unsafe code is actively whitelisted by the cargo.toml file in the project root.
Inconvenient is quite the understatement. Designing and implementing something like this for each and every language compiler/runtime requires hugely more effort than doing it on the OS level. The likelihood of mistakes is also far greater.
Perhaps it's worth exploring whether it can be done on the LLVM level so that at least some languages can share an implementation.
so the problem is IFUNC mechanism, which has its valid uses but can be EASILY misused for any sort of attacks
The rule we need is "If I pull in library X with some capability set, then X can't do anything not explicitly allowed by the passed set of capabilities". The problem in C is that there is currently no straightforward way to firewall off different parts of a linux process from each other. And dynamic linking on linux is done by gluing together compiled artifacts - with no way to check or understand what assembly instructions any of those parts contain.
I see two ways to solve this generally:
- Statically - ie at compile time, the compiler annotates every method with a set of permissions it (recursively) requires. The program fails to compile if a method is called which requires permissions that the caller does not pass it. In rust for example, I could imagine cargo enforcing this for rust programs. But I think it would require some changes to the C language itself if we want to add capabilities there. Maybe some compiler extensions would be enough - but probably not given a C program could obfuscate which functions call which other functions.
- Dynamically. In this case, every linux system call is replaced with a new version which takes a capability object as a parameter. When the program starts, it is given a capability by the OS and it can then use that to make child capabilities passed to different libraries. I could imagine this working in python or javascript. But for this to work in C, we need to stop libraries from just scanning the process's memory and stealing capabilities from elsewhere in the program.
Enough to be cautious, enough to think about how to catch bad actors, not so much as to close yourself off and become a paranoid hermit.
I've been evil, been wonderful, and indifferent at different stages in life.
I have known those who have done similar for money, fame, and boredom.
I think, given a backstory, incentive, opportunity, and resources it would be possible to most people to flip from wouldn't to enlisted.
Leverage has shown to be the biggest lever when it comes to compliance.
North America is only about 5% of the world's population. [1] (We can assume that malicious actors are in North America, too, but this helps to adjust our perspective.)
The percentage of maliciousness on the Internet is much higher.
[1] _ See continental subregions. https://en.wikipedia.org/wiki/List_of_continents_and_contine...
Bullies who would have supported Hitler had he been named Netanyahu.
You may of course choose whatever words you like. But your statement is nonsense, and the failures in the Middle East are all humanity's fault.
The kakistocracies of CN, RU, and IR are not the feeble foes of democracy and capitalism that they were in the 20th century.
I'm curious, how do you rank CN, RU, and IR?
> The percentage of maliciousness on the Internet is much higher.
A baseless assumption.
We should also be asking ourselves if we are working on critical infrastructure. Lasse Collin probably did not consider liblzma being loaded by sshd when vetting the new maintainer. Did the xz project ever agree to this responsibility?
We should also be asking ourselfs if each dependency of critical infrastructure is worth the risk. sshd linking libsystemd just to write a few bytes into an open fd is absurd. libsystemd pulling in liblzma because hey it also does compressed logging is absurd. Yet this kind of absurd dependency bloat is everywhere.
I guess every 3 letter agency has at least one. You can do the math. They havent't learned anything after Solar Winds.
My understanding is that right now it's pretty much a name and shame of people who most of the time aren't even real "people" but hostile agents either working for governments or criminal groups ( or both )
Getting punched in the face is actually a necessary human condition for a healthy civilization.
The long-con theory seems a bit more plausible at the moment
To me that's way more plausible than losing control of your account and the person who compromised it then having someone over a long time insert the backdoor that took a long time to develop and then obfuscate it.
Likely someone at GH is talking to some government agencies right now about the behavior of the private repos of that user and their associated users.
I would not be surprised if there was a group using this approach, but I doubt most of them are/would. If they were that dedicated, they'd just have a fucking job, instead of being dicks on the internet for a living.
However at this point: every developed nation has a professional offensive security group that have varying degrees of potency. All are more resourced than 99.9% of organizations defending and enjoy legal autonomy in their country and allied countries for their work.
If you're getting salaried comfortably, and you have near infinite resources, a two year timeline is trivial. As an American, I always like to point to things we know our own services have done first[0].
Each actor group have their own motivations and tactics[1]. As someone who spent a lot of time dealing with a few state actors, you learn your adversaries tricks of the trade and they are patient for the long-con because they can afford to be.
[0] - https://www.npr.org/2020/03/05/812499752/uncovering-the-cias... [1] - https://learn.microsoft.com/en-us/microsoft-365/security/def...
As someone that's spent a lot of time in darker places, I would agree.
With the added bonus that sometimes they get to pull off a longcon like this.
So most likely he didn't wait two years to benefit.
Or they WERE legit and simply went rogue, perhaps due to external factors.
Unless you have some very specific cultural knowledge you could not make even vaguely useful deductions about my location, nationality, culture, ethnicity etc. from my name. I get a lot of wrong guesses though!
Also nobody checked that person's id, so "Jia" is only slightly more meaningful than "ghrssbitrvii".
And some others hints at Eastern Europe, comparing the timezones. Taiwan ist still the strongest hint though.
Looking at the times of commits shouldn’t be given much value at all. A pretty pointless endeavour.
https://news.ycombinator.com/item?id=39870925
https://play.clickhouse.com/play?user=play#U0VMRUNUIHRvSG91c...
As some of the Tweet replies mentioned, they shipped releases that contained the backdoor, and committed other questionable changes at the "usual" times. For sure we're almost certainly not dealing with a compromised workstation, so I don't think that would explain the different times for the worst offending changes.
Maybe he has some technical experts/handlers/managers that had to oversee when they introduced the actual malicious changes, and thus this reflects when he got the go-ahead signal from these other people (and thus that reflects their working hours?)
Or maybe they were just travelling at that time? (maybe travelling to visit the aforementioned handlers? Or travel to visit family... even criminals have a mom and dad)
Also, keep in mind that my Clickhouse query includes all of the Github interactions (for example, timestamp of issue comments)... and unlike a Git commit timestamp, it's hard to fake those (because you'd need to schedule the posting of such comments, probably via the API. Not impossible, but easier to think that JiaT75 just used the Gitub UI to write comments), the Tweet mentions just "commit history"
Usually the simpler explanation has less chance of being wrong... thinking of some possibilities:
- Chinese/Taiwanese state actor, who employs people 9-5 (but somehow, their guy worked 20.00 - 02.00 local time)
- Chinese/Taiwanese rogue group/lone wolf... moonlighting on this exploit after their day job (given that to interact with Lasse they'd be forced to work late, this is not outside of the realm of possibilities)
- Non-Chinese state actor, employing someone 9-5 (consistent with most of the Github interactions), wanting to pin responsibility on China/Taiwan (+0800 timezone for commits), which for some unexplained reason pushed the worst offending changes at really weird times.
- Chinese/Taiwanese state actor, that wanted to pin the blame on western state actors (by making all of the changes at times compatible with someone working in Europe), and somehow they slipped up when pushing the worst offending changes.
- Chinese/Taiwanese state actor, employing someone in Europe (if they need to get approval of changes/gain the trust of the previous maintainer Lasse, it might make sense to have better/more timezone overlap)... which for some weird (yet "innocent") reason, kept the device that they worked on, configured with a +0800 timezone
- Non-Chinese state actor, pretending to be a Chinese entity that wanted to pin the blame on a western entity and slip up by making the worst offending changes at 3am (i.e. it was not a slip up, but it's part of the misdirection efforts.)
Some of these hypotheses are a bit farfetched, but reality is stranger than fiction
Note that it say "Fedora 41" in the CISA page link to Red Hat, but Red Hat changed the blog title to "Fedora 40" and left the HTML page title as "Fedora 41".
And if someone wanted to attack a target running on Loongson, they would certainly have to make sure the code can actually run there in the first place.
This is more reckless than any backdoor I can think of by a US agency . NSA backdoored Dual EC DRBG, which was extremely reckless, but this makes that look careful and that was the Zenith of NSA recklessness. The attackers here straight up just cowboy'd the joint. I can't think of any instance in which US intelligence used sock puppets on public forums and mailinglists to encourage deployment of the backdoored software and I maintain a list of NSA backdoors: https://www.ethanheilman.com/x/12/index.html
It just doesn't seem like their style.
Operation Northwoods came about because Brig. Gen. Edward Lansdale, asked the CIA to come up with a list of pretexts that might be used to justify an invasion of Cuba. This request had a number of planners at the CIA enumerate possible false flags that could be used as a pretext. One of those plans was a terror attack against US citizens. Operation Northwoods was rejected and never implemented.
The US has plans for nearly everything, but there is a massive difference between a plan that some CIA analyst is pitching and something the US is likely or even able to do. The US had all sorts of plans for how to handle a pandemic, but then when one actually happened, the plans couldn't be implemented because the US didn't actually have the capabilities the plans called for.
> example, perhaps they were planning to blame the hack of a power plant or critical infrastructure on this exploit, then use the "evidence" that was leaked to prove it was China, and from there carry out an offensive operation against Chinese infrastructure.
Backdooring OpenSSH would in no way function as a pretext for attacks on Chinese infrastructure. No one outside the tech companies cares about this. The US also doesn't need to invent hacking pretexts, you could just point to one of many exposed Chinese hacking incidents.
> knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
If an attacker then actually uses the backdoor created by the new release to gain unauthorized access to a protected computer system, then obviously there's a CFAA violation there. The public facts don't contain documented examples of this having happened (yet), though it will be unsurprising if that changes.
So it is still not obvious, at least to me, that any crime under US law has occurred so far. I am not a lawyer, though I'm aware of how badly the government has lost the previous court cases that attempted to restrict what humans can put in source code.
Aside from signed commits, we need to bring back GPG key parties and web of trust. When using a project you would know how many punches away from the committers you are.
For all of their nerd cred, key parties didn't accomplish very much (as evidenced by the fact that nothing on the Internet really broke when the WoT imploded a few years ago[1]). The "real" solution here is mostly cultural: treating third-party software like the risky thing it actually is, rather than a free source of pre-screened labor.
I know of the key party issues. But there is some value to knowing how far removed from me and people I trust the project authors are.
[1] formerly also twitter, at least partially.
That's true!
This is factually false - in fact, it's literally the direct opposite of the truth. "Getting punched in the face" is base violence that is incompatible with a healthy civilization. A good government with a robust justice system is what is actually needed for a healthy civilization.
It's a known fact that China will "recruit" people to operate them. A quote:
> They talk to them, say my friend, I see you like our special menu. Are you from China? Are you here on a VISA? Do you have family back there? Would you like your family to stay alive? Is your loyalty to this temporary employer or is your loyalty to your motherland? You know, a whole bunch of stuff like that. That’s how Chinese intelligence operations acts...
This just gives feelings of less "compromised account" and more "Your account is now our account"
However if we were critiquing characters in a book-- especially ones where narrative voice tells us exactly their true motivations--then maybe not, and they get framed as a "dupe" or "manipulated" etc.
Was xz/lzma a core technology when it was created? Is my tiny "constant time equality" Rust crate a core technology? Even though it's used by the BLAKE3 crate? By the way, is the BLAKE3 crate a core technology? Will it ever become a core technology?
With free software in general, things do not start a "core technology"; they become a "core technology" over time due to usage. At which point would a maintainer have to get a TS clearance? Would the equivalent of a TS clearance from my Latin America country be acceptable? And how would I obtain it? Is it even available to people outside the military and government (legit question, I never looked)?
If that's the case, you do you. Do you also think that all other countries should do the same, and rewrite everything from scratch for their government use (without foreign, for example American, influence)? And what about companies? Should they be forced to switch to their government's "safe" software, or can they keep using Linux and ssh? What about multi-national companies? And what even counts as a "core" software?
So yeah, I don't think it's a good idea.
Corps? Aside from Intel most of them barely pay to upstream their drivers.
The govt? The US federal government cut so much of it's support since the 70s and 80s.
Maintainers need to be more stringent and vigilant of the code they ship, and core projects that many other projects depend upon should receive better support, financial and otherwise, from users, open source funds and companies alike. This is a fragile ecosystem that this person managed to exploit, and they likely weren't the only one.
I’ve been a package maintainer for a decade. I make it a habit to spot check the source code of every update of every upstream package, hoping that if many others do the same, it might make a difference.
But this backdoor? I wouldn’t have been able to spot it to save my life.
I do agree that it's unreasonable to review the code of the entire dependency tree, but reviewing own code thoroughly and direct dependencies casually should be the bare minimum we should expect maintainers to do.
The OpenSSH project has nothing to do with xz. The transitive dependency on liblzma was introduced by a patch written by a third party. [1] You can't hold OpenSSH project members accountable for something like this.
This is a tragedy of the commons, and we can't place blame on a single project besides xz itself, yet we can all share part of the blame to collectively do better in the future.
At the end of the day we have to be able to answer why this happened, and how we can prevent it from happening again. It's not about pointing fingers, but about improving the process.
BTW, there have been several attempts at introducing backdoors in the Linux kernel. Some manage to go through, and perhaps we don't know about others, but many were thwarted due to the extreme vigilance of maintainers. Thankfully so, as everyone is well aware of how critical the project is. I'm not saying that all projects have the resources and visibility of Linux, but clearly vigilance is a requirement for lowering the chances of this happening.
> That's assuming a maintainer wasn't compromised, like in this case.
What makes you say that? Everything I've read about this (e.g. [1]) suggests that this was done by someone who also made valid contributions and gained gradual control of the project, where they were allowed to bypass any checks, if they existed at all. The misplaced trust in external contributions, and the lack of a proper peer review process are precisely what allowed this to happen.
[1]: https://boehs.org/node/everything-i-know-about-the-xz-backdo...
Projects that end up with a single maintainer should raise some flags, and depending on their importance, help and resources should be made available. We've all seen that xkcd, and found it more amusing than scary.
One idea to raise awareness: a service that scans projects on GitHub and elsewhere, and assigns maintenance scores, depending on various factors. The bus factor should be a primary one. Make a scoreboard, badges, integrate it into package managers and IDEs, etc. GitHub itself would be the ideal company to implement this, if they cared about OSS as much as they claim to do.
And you're free to not accept amateur contributions to the OS projects you maintain. Hell, you can require security clearance for your contributors right now, if you want.
If this backdoor turns out to be linked to the US, what would your proposal even solve?
1) and 3) (and, to an extent, 2) )are routinely done, to some degree, by your average security-conscious employer. Your employer knows who you are and probably put some thought on how to avoid your accounts getting hacked.
But what is reliability? Could be anything from "this dude has no outstanding warrants" to "this dude has been extensively investigated by a law enforcement agency with enough resources to dig into their life, finances, friends and family, habits, and so on".
I might be willing to go through these hoops for an actual, "real world" job, but submitting myself to months of investigation just to be able to commit into a Github repository seems excessive.
Also, people change, and you should be able to keep track of everyone all the time, in case someone gets blackmailed or otherwise persuaded to do bad things. And what happens if you find out someone is a double agent? Rolling back years of commits can be incredibly hard.
If the ultimate goal is to avoid backdoors in critical infrastructures (think government systems, financial sector, transportation,...) you could force those organizations to use forks managed by an entity like CISA, NIST or whatever.
If the ultimate goal is to avoid backdoors in random systems (i.e. for "opportunistic attacks"), you have to keep in mind random people and non-critical companies can and will install unknown OSS projects as well as unknown proprietary stuff, known but unmaintained proprietary stuff (think Windows XP), self-maintained code, and so on. Enforcing TS clearances on OSS projects would not significantly mitigate that risk, IMHO.
Not to mention that, as we now know, allies spy and backdoor allies (or at least they try)... so an international alliance doesn't mean intelligence agencies won't try to backdoor systems owned by other countries, even if they are "allies".
The most practical way to establish some uniform governance over how people use those tools would involve a new OS distribution, kinda like Debian, Fedora, Slackware,... but managed by NIST or equivalent, which takes whatever they want from upstream and enrich it with other features.
But it doesn't stop here. What about browsers (think about how browsers protect us from XSS)? What about glibc, major interpreters and compilers? How do you deal with random Chrome or VS Code extensions? Not to mention "smart devices"...
Cybersecurity is not just about backdoors, it is also about patching software, avoiding data leaks or misconfigurations, proper password management, network security and much more.
Relying on trusted, TS cleared personnel for OS development doesn't prevent companies from using 5-years old distros or choosing predictable passwords or exposing critical servers to the Internet.
As the saying goes, security is not a product, it's a mindset.
As for applications beyond the core system, that would fall on the individual organizations to weigh the risks. Most places already have a fairly limited stack and do not let you install whatever you want. But given that the core system isn't optional in most cases, it needs extra care. That's putting aside the fact that most projects are worked on by big corps that do go after rogue employees. Still, I would prefer if some of the bigger projects were more secure as well.
Your "mindset" is basically allowing bad code into the Kernel and hoping that it gets caught.
Not at all. I'm talking about running more and more rigorous security tests because you have to catch vulnerabilities, 99% of which are probably introduced accidentally by an otherwise good, reliable developer.
This can be done in multiple ways. A downstream distribution which adds its own layers of security tests and doesn't blindly accept upstream commits. An informal standard on open source projects, kinda like all those Github projects with coverage tests shown on the main repo page. A more formal standard, forcing some critical companies to only adopt projects with a standardized set of security tests and with a sufficiently high score. All these approaches focus on the content, not on the authors, since you can have a totally good-willing developer introducing critical vulnerabilities (not the case here, apparently, but it happens all the time).
On top of that, however, you should also invest in training, awareness, and other "soft" issues that are actually crucial in order to actualy improve cybersecurity. Using the most battle-tested operating systems and kernels is not enough if someone actually puts sensitive data on an open S3 bucket, or if someone only patches their systems once a decade, or if someone uses admin/admin on an Internet-facing website.
Seen this happen to friends here in Australia who were attending pro-Taiwan protests.
(I have written a TOTP implementation myself. I do not have a GH account, and likely never will.)
What makes TOTP different from a password in terms of use or refusal?
The main problem I have with MFA is that it gets used too frequently for things that don't need that much protection, which from my perspective is basically anything other than making a transfer or trade in my bank/brokerage. Just user-hostile requiring of manual action, including finding my phone that I don't always keep on me.
It's also often used as a way to justify collecting a phone number, which I wouldn't even have if not for MFA.
The worse part is that people think they're more protected, when they're really not.
It's very easy to permanently lose accounts when 2FA is in use. If I lose my device my account is gone for good.
Tokens from github never expire, and can do everything via API without ever touching 2FA, so it's not that secure.
Incorrect, unless you choose not to record your seeds anywhere else, which is not a 2fa problem.
2fa is in the end nothing more than a 2nd password that just isn't sent over the wire when used.
You can store a totp seed exactly the same as a password, in any form you want, anywhere you want, and use on a brand new device at any time.
You know google authenticator app introduced a backup feature less than 1 year ago right?
You know phones break all the time right?
When I said they are just another password, I was neither lying nor in error. I presume you can think of all the infinite ways that you would keep copies of a password so that when your phone or laptop with keepassxc on it breaks, you still have other copies you can use. Well when I say just like a password, that's what I mean. It's just another secret you can keep anywhere, copy 50 times in different password managers or encrypted files, print on paper and stick in a safe, whatever.
Even if some particular auth app does not provide any sort of manual export function (I think google auth did have an export function even before the recent cloud backup, but let's assume it didn't), you can still just save the original number the first time you get it from a qr code or a link. You just had to know that that's what those qr codes are doing. They aren't single-use, they are nothing more than a random secret which you can keep andbcopy and re-use forever, exactly the same as a password. You can copy that number into any password manager or plain file or whatever you want just like a password, and then use it to set up the same totp on 20 different apps on 20 different devices, all working at the same time, all generating valid totp codes at the same time, destroy them all, buy a new phone, retrieve any one of your backup keepass files or printouts, and enter them into a fresh app on a fresh phone and get all your totp fully working again. You are no more locked out than by having to reinstall a password manager app and access some copy of your password db to regain the ordinary passwords.
The only difference from a password is, the secret is not sent over the wire when you use it, something derived from it is.
Google authenticators particular built in cloud copy, or lack of, doesn't matter at all, and frankly I would not actually use that particular feature or that particular app. There are lots of totp apps on all platforms and they all work the same way, you enter the secret give it a name like your bank or whatever, select which algorithm (it's always the default, you never have to select anything) and instantly the app starts generating valid totp codes for that account the same as your lost device.
Aside from saving the actual seed, let's say you don't have the original qr code any more (you didn't print it or screenshot it or right-click save image?) there is yet another emergency recovery which is the 10 or 12 recovery passwords that every site gives you when you first set up totp. You were told to keep those. They are special single-use passwords that get you in without totp, but each one can only be used once. So, you are a complete space case and somehow don't have any other copiesbof your seeds in any form, including not even simple printouts or screenshots of the original qr code, STILL no problem. You just burn one of your 12 single-use emergency codes, log in, disable and re-enable totp on that site, get a new qr code and a new set of emergency codes. Your old totp seed and old emergency codes no longer work so thow those out. This time, not only keep the emergency codes, also keep the qr code, or more practical, just keep the seed value in the qr code. It's right there in the url in the qr code. Sometimes they even display the seed value itself in plain text so that you can cut & paste it somewhere, like into a field in keepass etc.
In fact keepass apps on all platforms also will not only store the seed value but display the current totp for it just like a totp app does. But a totp app is a more convenient.
And for proper security, you technically shouldn't store both the password and the totp seed for an account in the same place, so that if someone gains access to one, they don't gain access to both. That's inconvenient but has to be said just for full correctness.
I think most sites do a completely terrible job of conveying just what totp is when you're setting it up. They tell you to scan a qr code but they kind of hide what that actually is. They DO all explain about the emergency codes but really those emergency codes are kind of stupid. If you can preserve a copy of the emergency codes, then you can just as easily preserve a copy of the seed value itself exactly the same way, and then, what's the point of a hanful of single-use emergency passwords when you can just have your normal fully functional totp seed?
Maybe one use for the emergency passwords is you could give them to different loved ones instead of your actual seed value?
Anyway if they just explained how totp basically works, and told you to keep your seed value instead of some weird emergency passwords, you wouldn't be screwed when a device breaks, and you would know it and not be worried about it.
Now, if, because of that crappy way sites obscure the process, you currently don't have your seeds in any re-usable form, and also don't have your emergency codes, well then you will be F'd when your phone breaks.
But that is fixable. Right now while it works you can log in to each totp-enabled account, and disable & reenable totp to generate new seeds, and take copies of them this time. Set them up on some other device just to see that they work. Then you will no longer have to worry about that.
It emphasizes that TOTP seeds, like passwords, can be copied and securely stored in multiple ways, ensuring access even if a device is lost or breaks. The text criticizes the common misunderstanding and undercommunication regarding the nature of TOTP seeds and emergency recovery codes provided during setup, suggesting that proper management and backup of these seeds eliminate the risk of losing access to accounts protected by TOTP. It also touches on security practices, like not storing TOTP seeds and passwords together, to prevent simultaneous compromise.
But if you forgot to do it on day one, you can't do it on day two because there is no way of getting them out other than rooting the phone.
Giving how your premise was wrong, I won't bother to read that novel you wrote. I'll just assume it's all derived from the wrong premise.
The fact that you did not know this does not change this fact.
I acknowledged that web sites don't explain this well, even actively hide it. So it's understandable not to know this.
But I also reminded that this doesn't actually matter because you WERE also given emergency recovery passwords, and told to keep them, and told why, and how important they were.
You were never at risk of being locked out from a broken device EVEN THOUGH you didn't know about saving the seed values, UNLESS you also discarded the emergency codes, which is not a 2fa problem, it's an "I didn't follow directions" problem.
And even if all of that happened, you can still, right now, go retroactively fix it all, and get all new seed values and save them this time, as long long as your one special device happens to be working right now. It doesn't matter what features google authenticator has today, or had a year ago. It's completely and utterly irrelevant.
My premis remains correct and applicable. Your statement that 2fa places you at at risk was incorrect. You may possibly be at risk, but if so you did that to yourself, 2fa did not do that to you.
Ah yes those… the codes I must go to a public library to print, on a public computer, public network and public printer. I can't really see any problem with the security of this.
And then I must never forget where I put that very important piece of paper. Not in 10 years and after moving 3 times…
What in the world is this library drama?
No one is this obtuse, so your arguments are most likely disingenuous.
But if they are sincere, then find a nephew or someone to teach you how your computer works.
Libraries? Remembering something for 10 years? Moving? Oh the humanity!
So I can keep them on the same device that I keep my passwords, right?
> Or just keep them in a few copies of a password manager db in a few different places.
Great now you no longer have 2FA but just a longer password.
Or not. You decide how much effort you want and where you want to place the convenience vs security slider.
Yes, if you keep both factors not only on the same device but in the same password manager, then both factors essentially combine into nothing but a longer password.
I did say from the very first, that the seeds are nothing other than another password.
Except there is still at least one difference which I will say for at least the 3rd time... the totp secret is not transmitted over the wire when it is used, the password is. That is actually a significant improvement all by itself even if you do everything else the easy less secure way.
And you do not have to store the seeds the convenient less secure way. You can have them in a different password app with a different master password on the same device, or on seperate devices, or in seperate physical forms. You can store them any way you want, securely, or less securely.
The point is that even while opting to do things all the very secure way, you are still not locked out of anything when a single special device breaks, because you are not limited to only keeping a single copy of the seeds or the emergency passwords in a single place like on a single device or a single piece of paper.
You are free to address any "but what about" questions you decide you care about in any way you feel like.
The only way you were ever screwed is by the fact that the first time you set up 2fa for any site, most sites don't explain the actual mechanics but just walk you through a sequence of actions to perform without telling you what they actually did, and so at the end of following those directions you ARE left with the seeds only stored in a single place. And in the particular case of Google Authenticator, stored in a more or less inaccessible place in some android sqlite file you can't even manually get to without rooting your phone probably. And were never even told about the seed value at all. You were given those emergency passwords instead.
That does leave you with a single precious drvice that must not break or be lost. But the problem is only a combination of those bad directions given by websites, and the limitations of one particular totp app when that app didn't happen to display or export or cloud-backup the seeds until recently.
Even now Googles answer is a crap answer, because Google can see the codes unencrypted on their server, and Google can kill your entire gooogle account at sny time and you lose everything, email, drive , everything, instantly, no human to argue with. That is why I said even today I still would not use Google Authenticator for totp.
Except even in that one worst case, you still had the emergency passwords, which you were always free to keep in whatever way works for you. There is no single thing you must or must not do, there is only what kinds of problems are the worst problems for you.
Example: if what you are most concerned about is someone else getting ahold of a copy of those emergency passwords, then you want to have very few copies of them and they should be off-line and inconvenient to access. IE a printed hard copy in a safe deposit box in switzerland.
If what you are most concerned about is accidentally destroying your life savings by losing the password and the investment site has no further way to let you prove your ownership, then keep 10 copies in 10 different physical forms and places so that no matter what happens, you will always be able to access at least one of them. One on goggle drive, one on someone else's google drive in case yours is killed, one on onedrive, one on paper at home, one on paper in your wallet, one on your previous phonr that you don't use but still works, etc etc.
You pick whichever is your biggest priority, and address that need however you want, from pure convenience to pure security and all possible points in between. The convenient way has security downsides. The secure way has convenience downsides. But you are not forced to live with the downsides of either the convenient way or the secure way.
You don't like long full detailed explainations, and you ignore short explainations. Pick a lane!
A friend of mine a long time ago used to have a humorous classification system, that people fell into 3 groups: The clued, The clue-able, The clue-proof.
Some people already understand a thing. Some people do not understand a thing, but CAN understand it. Some people exist in a force bubble of their own intention that actively repels understanding.
In your quest to convince me you forgot to even stop to ponder if you're right at all. And in my view, you aren't.
Perhaps the problem isn't that I don't understand you. Perhaps I understand you perfectly well but I understand even more, to realise that you're wrong :)
No one is stopping you.
This is a silly thing to argue about but hey I'm silly so let's unpack your critique of the classification system
There is no 4th classification. It only speaks of understanding not agreeing.
Things that are matters of opinion may still be understood or not understood.
Whether a thing is a matter of opinion or a matter of fact, both sides of a disagreement still slot into one of those classes.
If a thing is a matter of opinion, then one of the possible states is simply that both sides of a disagreement understand the thing.
In this case, it is not a matter of opinion, and if you want to claim that I am the one who does not understand, that is certainly possible, so by all mrans, show how. What fact did I say that was not true?
Keep trying solier. You never know. (I mean _I_ know, but you don't. As far as you know, until you go find out, I might be wrong.)
Whatever you do, don't actually go find out how how it works.
Instead, continue avoiding finding out how it works, because holy cow after you've gone this far... it's one thing to just be wrong about something, everyone always has to start out not understanding something, that's no failing, but to have no idea what you're talking about yet try to argue about it, in error the whole time..., I mean they (me) were such an insufferable ass already trying to lecture YOU, but for them (me) to turn out to have been simply correct in every single fact they spoke, without even some technicality or anything to save a little face on? Absolutely unthinkable.
Definitely better to save yourself from that by just never investigating.
You are too busy writing novels and raging at me to read what I wrote with an open mind.
Because if you don't use weak passwords MFA doesn't add value. I do recommend MFA for most people because for most people their password is the name of their dog (which I can look up on social media) followed by "1!" to satisfy the silly number and special character rules. So yes please use MFA.
But if your (like my) passwords are 128+bits out of /dev/random, MFA isn't adding value.
With MFA even if somebody has your password if they don't have your physical authenticator too then you're relatively safe.
There are plenty of scenarios where MFA is more secure than just a strong password.
> There are plenty of scenarios where MFA is more secure than just a strong password.
And how realistic are they? Or are they just highly specific scenarios where all the stars must align, and are almost never going to happen?
The point is also that you as an individual can make choices and assess risk. As a large service provider, you will always have people who reuse passwords, store them unencrypted, fall for phishing, etc. There is a percentage of users that will get their account compromised because of bad password handling which will cost you, and by enforcing MFA you can decrease that percentage, and if you mandate yubikeys or something similar the percentage will go to zero.
For a typical person, maybe, but for a tech-minded individual who understands security, data entropy and what /dev/random is?
And I don't see how MFA stops phishing - it can get you to enter a token like it can get you to enter a password.
I'm also looking at this from the perspective of an individual, not a service provider, so the activities of the greater percentage of users is of little interest to me.
That's why I qualified it with "certificate-based". The private key never leaves the device, ideally a yubikey-type device.
Except that phishing doesn't require the private key - it just needs to echo back the generated token. And even if that isn't possible, what stops it obtaining the session token that's sent back?
Sure, you can probably come up with some non-HTTPS scheme that can address this, but I don't see any site actually doing this, so you're back to the unrealistic scenario.
If I were trying to phish someone, I wouldn't attack the public key crypto part, so how domains come into play during authentication doesn't matter. I'd just grab the "unencrypted" session token at the end of the exchange.
Even if you somehow protected the session token (sounds dubious), there's still plenty a phisher could do, since it has full MITM capability.
There's also the issue of how many sites actually use it, as well as how it handles the loss of or inability to access private keys etc. I generally see stuff like 'recovery keys' being a solution, but now you're just back to a password, just with extra steps.
Most people use their phones most of the time now, meaning the MFA device is the same device they're using.
Of the people who aren't using a phone, how many are using a laptop with a built in keyboard? It's pretty obvious if you have a USB dongle hanging off your laptop.
If you're using a desktop, it's going to be in a relatively secure environment. Bluetooth probably doesn't even reach outside. No one's breaking into my house to plant a keylogger. And a wireless keyboard seems kind of niche for a desktop. It's not going to move, so you're just introducing latency, dropouts, and batteries into a place where they're not needed.
Long, random, unique passwords are phishing resistant. I don't know my passwords to most sites. My web browser generates and stores them, and only uses them if it's on the right site. This has been built in functionality for years, and ironically it's sites like banks that are most likely to disable auto fill and require weak, manual passwords.
This is part of why MFA just to log in is a bad idea. It's much more sensible if you use it only for sensitive actions (e.g. changing password, authorizing a large transaction, etc.) that the user almost never does. But you need everyone to treat it that way, or users will think it's just normal to be asked to approve all the time.
no. a second factor of authentication is completely orthogonal to password complexity.
I don't have strong opinions about making it mandatory, but I turned on 2FA for all accounts of importance years ago. I use a password manager, which means everything I "know" could conceivably get popped with one exploit.
It's not that much friction to pull out (or find) my phone and authenticate. It only gets annoying when I switch phones, but I have a habit of only doing that every four years or so.
You sound like you know what you're doing, that's fine, but I don't think it's true that MFA doesn't add security on average.
Right. I don't ever want to tie login to a phone because phones are pretty disposable.
> I don't think it's true that MFA doesn't add security on average
You're right! On average it's better, because most people have bad password and/or reuse them in more than one place. So yes MFA is better.
But if your password is already impossible to guess (as 128+ random bits are) then tacking on a few more bytes of entropy (the TOTP seed) doesn't do much.
Plus, the server/provider side remains a huge weak point too. And the effort of enrolling/giving the user the initial seed is suspect.
This is why the FIDO/hardware passkeys/etc are so much better because is basically hardware enforced two way public key auth, done correctly there isn't any way to leak the private keys and its hard has hell to MITM. Which is why loss of the hw is so catastrophic. Most every other MFA scheme is just a bit of extra theater.
Exactly, that's it. Two parties have a shared secret of, say 16 bytes total, upon which authentication depends.
They could have a one byte long password but a 15 byte long shared secret used to compute the MFA code. The password is useless but the MFA seed is unguessable. Maybe have no password at all (zero length) and 16 byte seed. Or go the other way and a 16 byte password and zero seed. In terms of an attacker brute forcing the keyspace, it's always the same, 16 bytes.
We're basically saying (and as a generalization, this is true) that the password part is useless since people will just keep using their pets name, so let's put the strenght on the seed side. Fair enough, that's true.
But if you're willing to use a strong unique password then there's no real need.
(As to keyloggers, that's true, but not very interesting. If my machine is already compromised to the level that it has malicious code running logging all my input, it can steal both the passwords and the TOTP seeds and all the website content and filesystem content and so on. Game's over already.)
> This is why the FIDO/hardware passkeys/etc are so much better
Technically that's true. But in practice, we now have a few megacorporations trying to own your authentication flow in a way that introduces denial of service possibilities. I must control my authentication access, not cede control of it to a faceless corporation with no reachable support. I'd rather go back to using password123 everywhere.
It's hard to get a software keylooger installed on a corp. machine. It's easy to get physical access to the office or even their homes and install keyloggers all over the place and download the data via BT.
You are of course correct.
This is where threat modeling comes in. To really say if something is more secure or less secure or a wash, threat modeling needs to be done, carefully considering which threats you want to cover and not cover.
I this thread I'm talking from the perspective of an average individual with a personal machine and who is not interesting enough to be targeted by corporate espionage or worse.
Thus, the threat of operatives breaking into my house and installing hardware keyloggers on my machines is not part of my threat model. I don't care about that at all, for my personal use.
For sensitive company machines or known CxOs and such, yes, but that's a whole different discussion and threat model exercise.
Maybe someone can disrupt the open source funding problem by brokering exploit bounties /s
I'd much rather see passwords entirely replaced by key-based authentication. That would improve security. Adding 2FA to my password is just patching a fundamentally broken system.
Source: worked at all the major banks, all the wealthy clients use hardware MFA
Get better banks people :)
This is the default for all their customers, wealthy or not.
https://www.abnamro.nl/en/commercialbanking/internetbanking/...
For the longest time the max password size was 8 characters and the csr knew what your password was.
Heck I've had Chase security tell me they'd call me back.. dude that's exactly how people get compromised.
They do require 2FA, though.
Now I have to wait for an SMS. Great...
I don't think it's a thing that happens that often in UK etc.; but, it doesn't happen that frequently in the US either. It's just a thing that can potentially happen.
“I pay the bills there” is barely better than nothing, though. We do this in Canada too. It is what I used for a driver’s license one renewal.
See the sibling comment.
This happened the other day while I was on a conference call with perfect audio and video using my phone’s mobile data.
A few weeks back, had some shop which sends out an SMS to inform you the job’s done tell me this is usually hit and miss when I complained about not hearing from them.
And, by the way, the SMS in question never arrived. I don't know if there's some kind of timeout happening, and the network gives up after a while. Some 15 years ago I remember getting texts after an hour or two if I only had spotty reception. This may of course have changed in the meantime, plus this is a different provider.
Ideally they’d just implement passkeys (webauthn/fido). More secure, and it works with iOS, android, 1password, and yubikeys
I pushed YubiKey as a solution and explained in detail why SMS was an awful choice, but they went with SMS anyway.
It mostly came down to cost. SMS was the cheapest option. YubiKey would involve buying and sending the keys to customers, and they having the pain/cost of supporting them. There was also the feeling that YubiKeys were too confusing for customers. The nail in the coffin was "SMS is the standard solution in the industry" plus "If it's good enough for VISA it's good enough for us".
> support
You answered your own question.
https://www.bankofamerica.com/security-center/online-mobile-...
Some will provide and require them for top customers to ensure they are safe.
Here's the thing about SMS: your great aunt who doesn't know what a JPEG is, knows what a text is. Ok, she might not fully "get it" but she knows where to find a text message in her phone. My tech-literate fiancée struggles to get her YubiKey to work with her phone, and I've tried it with no more luck than she's had. YubiKeys should be supported but they're miles away from being usable enough to totally supplant other 2FA flows.
I have a feeling this won't hold true forever. Microsoft has their own authenticator now, Steam has another one, Google has their "was this you?" built into the OS.
Monetization comes next? "View this ad before you login! Pay 50c to stay logged in for longer?"
It's not completely closed, but in practice no one on that list is a small independent open source project, those are all the kind of entrenched corporate security companies you'd expect
Maybe a pubkey system where you choose your own client would be what you’re looking for?
I’m not even sure it is difficult. Most people I’ve talked to in tech don’t even realize it is a possibility. Certificates are “complicated” as they put it.
Not only that, but it's completely impossible to disable or remove that functionality or even make TOTP the primary option. Every single time I try to sign in, Google prompts my phone first, giving me a useless notification for later, and I have to manually click a couple of buttons to say "no I am not getting up to grab my phone and unlock it for this bullshit, let me enter my TOTP code". Every single time.
It's a good spec. I wish more people who spread FUD about it being a "tech-giant" only thing would instead focus on the productive things like demanding proper import/export between providers.
Password manager turns something you know into something you own. If also the something you own is in the password manager itself… it's the same as requiring extra long passwords.
All very fair points.
I've never understood how key-based systems are considered better. I understand the encryption angle, nobody is compromising that. But now I have a key I need to personally shepherd? where do I keep it, and my backups, and what is the protection on those places? how many local copies, how many offsite? And I still need a password to access/use it, but with no recourse should I lose or forget. how am I supposed to remember that? It's all just kicking the same cans down the same roads.
True story.
In gh you can generate a limited one, but it's not really clear on what the permissions actually mean, so it's trial and error… which means most people will get tired and grant random stuff to have them working.
(But you are right that a sleeper would be affordable for them.)
Even a team of 10 people working on this - the code and social aspect - would be a drop in the bucket for any nation-state.
Anyway. This team got caught. What are the odds that this state-actor that did this, that this was the only project / team / library that they decided to attack?
As a state sponsored project. What makes you think this is their only project and that this is a big setback? I am paranoid myself to think yesterdays meeting went like : "team #25 has failed/been found out. Reallocate resources to the other 49 teams."
This is a very strong argument for FOSS to pick up the good habit of ditching/un-mainlining projects where they are sitting around for state actors to volunteer injecting commits to, and dep-stripping active projects from this cruft.
Who wants to maintain on a shitty compression format? Someone who is dephunting, it turns out.
Okay so your pirate-torrent person needs liblzma.so Offer it in the scary/oldware section of the package library that you need to hunt down the instructions to turn on. Let the users see that it's marked as obsolete, enterprises will see that it should go on the banlist.
At the same time, XZ became a cornerstone of major Linxus distributions, being systemd dependency and loaded, in particular, as part of sshd. What could go wrong?
In hindsight, the commercial idea of Red Hat, utilizing the free work of thousands of developers working "just for fun", turned out to be not so brilliant.
A lot of comments in this thread seem to be missing the forest for the trees: this was a multiyear long operation that targeted a vulnerable developer of a heavily-used project.
This was not the work of some lone wolf. The amount of expertise needed and the amount of research and coordination needed to execute this required hundreds of man-hours. The culprits likely had a project manager....
Someone had to stalk out OSS developers to find out who was vulnerable (the xz maintainer had publicly disclosed burnout/mental health issues); then the elaborate trap was set.
The few usernames visible on GitHub are like pulling a stubborn weed that pops up in the yard... until you start pulling on it you don't realize the extensive reality lying beneath the surface.
The implied goal here was to add a backdoor into production Debian and Red Hat EL. Something that would take years to execute. This was NOT the work of one person.
https://hachyderm.io/@joeyh/112180715824680521
This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.
Example of what this user JiaT75 did so far:
https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...
pull requests mentioning xz, 5.6 without downgrade, cve being mentioned in the last 60 days:
https://play.clickhouse.com/play?user=play#U0VMRUNUIGNyZWF0Z...
If there were a bunch of people who adopted it abnormally fast compared to usual, might point to there being more "bad actors" in this operation (said at the risk of sounding paranoid if this turns out to be a state run thing)
https://www.redhat.com/en/blog/urgent-security-alert-fedora-...
We don't have a security problem
The security problem isn't affecting anyone
The people affected are only few
We're sorry about the security problem, please change your password
The thing about enterprise Linux distros is that they have a long support period. Bug fixes and security patches pile up.
Fortunately though, xz doesn't seem to have a lot of backported patches.
https://git.centos.org/rpms/xz/blob/c8s/f/SPECS/xz.spec https://git.centos.org/rpms/xz/blob/c7/f/SPECS/xz.spec
But take glibc for example. The amount of patches makes my head spin.
https://git.centos.org/rpms/glibc/blob/c8s/f/SPECS/glibc.spe...
After ~x.4 things slow down and only "important" fixes get backported but no new features.
After ~x.7 or so different processes and approvals come into play and virtually nothing except high severity bugs or something that "important customer" needs will be backported.
The goal is that 8.6, 9.2 and 9.4 will have releases at least every two weeks.
Maybe soon all Z streams will have a similar release cadence to keep up with the security expectations, but will keep a very similar expectations that you outlined above.
https://web.archive.org/web/20110831134700/http://tukaani.or...
> XZ Embedded is a relatively small decompressor for the XZ format. It was developed with the Linux kernel in mind, but is easily usable in other projects too.
> *Features*
> * Compiled code 8-20 KiB
> [...]
> * All the required memory is allocated at initialization time.
This is targeted at embedded and real-time stuff. Could even be part of boot loaders in things like buildroot or RTEMS. And this means potentially millions of devices, from smart toasters or toothbrushes to satellites and missiles which most can't be updated with security fixes.
One of my complaints about so many SciFi stories is the use of seemingly conventional weapons. I always thought that with so much advanced technology that weapons would be much more sophisticated. However if the next "great war" is won not by the side with the most destructive weapons but by the side with the best kill switch, subsequent conflicts might be fought with weapons that did not rely on any kind of computer assistance.
This is eerily similar to Einstein's (purported) statement that if World War III was fought with nuclear weapons, World War IV would be fought with sticks and stones. Similar, but for entirely different reasons.
I'm trying to understand why the characters in Dune fought with swords, pikes and knives.
Because the slow blade penetrates the shield. (And personal shields are omnipresent)
At least part of the reason is that the interaction between a lasgun and a shield would cause a powerful explosion that would kill the shooter too. No one wants that and no one will give up their shield, so they had to go back to melee weapons.
> However, a great reaction against computers has resulted in a ban on any "thinking machine", with the creation or possession of such punishable by immediate death.
tl;dr - Machine intelligences existed in Dune history, were discovered to be secretly controlling humanity (through abortion under false pretenses, forced sterilization, emotional/social control, and other ways), then were purged and replaced with a religious commandment: "Thou shalt not make a machine in the likeness of a human mind"
The reason nobody tries to use the lasgun-shield interaction as a weapon is because the resulting explosion is indistinguishable from a nuclear weapon, and the Great Convention prohibits the use of nukes on human targets.
Just the perception of having used a nuclear device would result in the House which did so becoming public enemy #1 and being eradicated by the Landsraad and Sardaukar combined.
@Potro: If you liked the movie, read the books. I don't read a lot anymore, but during sick leave I started with the first book. Didn't stop until I finished the main story, including the sequels by Frank Herbert's son about a month later. That's like... uh... nine books?
Because the author wanted a pseudo-medieval setting.
(The shields and the prohibition against computers, nukes etc were just clever plot devices to make advanced weapons unusable).
There is a way for programs to implement the systemd readiness notification protocol without using libsystemd, and thus without pulling in liblzma, which is coupled to libsystemd even though the readiness notification protocol does not require any form of compression. libsystemd provides a wide range of things which have only weak relationships to each other.
There are in fact two ways, as two people independently wrote their own client code for the systemd readiness notification protocol, which really does not require the whole of libsystemd and its dependencies to achieve. (It might be more than 2 people nowadays.)
* https://jdebp.uk/FGA/unix-daemon-readiness-protocol-problems...
The reality is that it is not systemd specifically but our modern approach to software design where we tend to rely on too much third party code and delight in designing extremely flexible, yet ultimately extremely complex pieces of software.
I mean this is even true as far as the various CPU attack vectors have shown in recent years, that yes speculative execution is a neat and 'clever' optimization and that we rely on it for speed, but that maybe that was just too clever a path to go down and we should've stuck with simpler designs that would maybe led to slower speedups but a more solid foundation to build future CPU generations on.
BeOS isn't getting a lot of CVEs attached to it, these days. That doesn't mean its good or secure, though.
There’s no evidence Lasse did anything “wrong” beyond looking for / accepting co-maintainers, something package authors are taken to task for not doing every time they have life catching up or get fed up and can’t / won’t spend as much time on the thing.
If this is a coordinated long-term effort by a state entity, there is no reason to trust the supposed creator of the project, especially given what it was targeting from the start.
Yes.
Without evidence to the contrary there is no reason to believe Lasse has been anything other than genuine so all you're doing is insulting and slandering them out of personal satisfaction.
And conspiratorial witch hunts are actively counter-productive, through that mode of thinking it doesn't take much imagination to figure out you are part of the conspiracy for instance.
1. An important project has an overburdened / burnt out maintainer, and that project is taken over by a persona who appears to help kindly, but is part of a campaign of a state actor.
2. A state actor is involved in setting up such a project from the start.
The first possibility is not only being an asshole to the original maintainer, but it is also more risky - that original maintainer surely feels responsible for his creation and could ring alarm bells. This is not unlikely because he knows the code. And alarm bells is something that state actors do not like.
The second possibility has the risk of the project not being successful, which would mean a serious investment in resources to fail. But that could be countered by having competent people working on that. And in that case, you don't have any real persons,just account names.
What happened here? I don't know.
The original maintainer has said in the past, before Jia Tan's increased involvement and stepping up as a maintainer, that he couldn't put as much into the project due to mental health and other reasons [1]. Seems to fit possibility number one rather well.
If you suspect that Lasse Collin was somehow in it from the start, that'd mean the actor orchestrated the whole thing about mental health and not being able to keep up with sole maintainership. Why would they even do that if they had the project under their control already?
Of course we don't know what's really been happening with the project recently, or who's behind the backdoor and how. But IMO creating suspicions about the original maintainer's motives based entirely on speculation is also a bit assholey.
edit: [1] https://www.mail-archive.com/[email protected]/msg00567.h...
More layers of obfuscation. For example in order to be able to attribute the backdoor to a different party.
It is of course also possible that Lasse Collins is a nice real person who just has not been able to review this. Maybe he is too ill,or has to care for an ill spouse, or perhaps he is not even alive any more. Who knows him as a person (not just an account name) and knows how he is doing?
They don't even need plausible deniability, groups like the NSA have been caught spying on everyone and it doesn't hurt them all that much. The publicity isn't ideal. But it only confirms what we already new - turns out the spies are spying on people! Who knew.
There are probably dozens if not hundreds of this sort of attempt going on right now. I'd assume most don't get caught. Or go undetected for a many years which is good enough enough. If you have government money on the budget, it makes sense to go with large-volume low-effort attempts rather than try some sort of complex good-cop-bad-cop routine.
But to establish a significant contributor to a key piece of software, not unlike xz, is an ideal position for a state actor. The developer doesn't even need to know who/why, but they could be financially/ideologically aligned. This is what intelligence officers do. They manage real human assets who exist naturally. But to have someone long-established as an author of a project is the exact type of asset they want. Even if they push the code, people immediately start considering how it could have been done by someone else. Yes, it's conspiratorial/paranoid thinking but there's nothing more paranoid than state intelligence trade craft.
https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14de...
The downvotes on this and unwillingness to consider the original maintainer may be malicious is disturbing and doesn't inspire trust in the OSS community.
This brings up some integrity questions about you and other people bringing forth accusations in order to make the original maintainer feel pressure to bring on someone else to replace the one that inserted a backdoor after several years of ostensibly legitimate commits.
Hopefully this helps you see that these sorts of accusations are a slippery slope and unproductive. Heck, you could then turnaround and accuse me of doing something nefarious by accusing you.
It's probably straight out of many playbooks.
And, as stated above, I don't think he's malicious, it's still something that must be considered. Sweeping the possibility away is weird.
The possibility can be kept in mind and considered even if it isn’t being actively discussed. I think in this case, most people think he is not malicious — and feel that unless new compelling evidence to show otherwise appears, potentially starting a harmful rumor based on speculation is counterproductive.
> I don't stalk your socials
I mentioned it because you called my intent into question.
Why are people running cover for the maintainer of a repo that just tried to backdoor sshd when others are asking legitimate questions?
No one is running cover, just that most information so far points to the original maintainer not knowing that the person brought on to help out had ulterior motives, and likely wasn’t even who they purported to be. If you were running an open source project and facing burnout as the sole maintainer, I’d imagine you’d exercise perfect judgement and do a full background check on the person offering to help? I think many of us would like to believe we’d do better, but the reality is, most of us would have fallen for the same trick. So now imagine having to deal with the fallout not just on the technical side, but also the never-ending questions surrounding your professional reputation that people just keep bring up — sounds like a recipe for depression, possibly even suicidal thoughts.
No questions. Anyone can become a victim to social engineering — I believe the short answer to your question about all the downvotes is that a lot of people recognize how they could have fallen for something similar, and empathize that Lasse is likely now going through a rather difficult time.
As for motivation… https://xkcd.com/386/ enough said :)
At any rate, this person has failed their cause and has actually made me double down on the conspiracy theory :)
If I didn’t know any better, I’d say you’re enjoying this spirited conversation ;)
Yes, nothing points to the inventor of the format and maintainer for decades has done anything with the format to make it suspect. If so, the recent backdoor wouldn't be needed.
It's good to be skeptic, but don't drag people through the mud without anything to back it up.
Also, the exploit shows a high effort, and a high level of competence, and a very obvious willingness to play a long game. These are not circumstances for applying Hanlon's razor.
It's weird to have one set of standards to a maintainer since 2009 or so, and different standards for others. This witch hunt is just post-hoc smartassery.
And this is in part because I can not even tell for sure that he even exists. If I had met him a few times in a bar, I would be more inclined to believe he is not involved.
Uh, because it's a compression library?
https://git.tukaani.org/?p=xz.git;a=blob;f=README;h=ac812ff1...
See what I did there?
Also do you mean back up?
Antonio literally used to go around mailing lists asking for lzip support and complaining about xz:
- https://gcc.gnu.org/legacy-ml/gcc/2017-06/msg00044.html
- https://lists.debian.org/debian-devel/2017/06/msg00433.html
Also, https://web.archive.org/web/20190605225651/http://octave.159...
I can understand wanting your project to succeed, it's pretty natural and human, but it's flagrant Antonio had a lot of feels about the uptake of xz compared to lzip, as both are container formats around raw lzma data streams and lzip predates xz by 6 months. His complaint article about xz is literally one of the "Introductory links" of lzip.
Neither is lzip since it doesn't contain error correction codes. You can add those with an additional file (to any archive) e.g. via par2 but then most of the points in the linked rant become irrelevant.
Care to provide some evidence to back this statement?
Also, Lasse has not been accused of any wrong-doings.
Why are you trying to discredit Lasse?
Here are recent examples:
1. https://news.ycombinator.com/item?id=39872919
2. https://news.ycombinator.com/item?id=39873552
This thread is about an exploit that does not rely on any potential security problems in the DESIGN of the xz FORMAT. Therefore your point, even if valid as a general one, is not really relevant to the exploit we're discussing.
Further, there's some proof needed that any potential suboptimal aspects of the security design of the xz FORMAT was designed such so that it could be exploited later or simply because no programmer is an expert on every aspect of security ever. I mean you could be the most security conscious programmer and your chain could still be compromised.
Security today is such a vast field and it takes so little to get you compromised that proclaiming anything 'secure design' these days is practically impossible.
I bet you an audit of lzip would find plenty of security issues, would those be intentional?
Then the code should not be complex. Low-level hacks and tricks (like pointer juggling) should be not allowed and simplicity and readability should be preferred.
To be clear, I have no idea how to solve this problem; I just don’t think saying that all code must be non-hacky is the right approach.
Performant code needn’t be unclean; it’s just often using deeper parts of the language.
I have a small project that became absolute spaghetti. I rewrote it to be modular, using lots of classes, inheritance, etc. It was then slower, but eminently more maintainable and extensible. I’m addressing that by using more advanced features of the language (Python), like MemoryView for IPC between the C libraries it calls. I don’t consider this unclean, but it’s certainly not something you’re likely to find on a Medium article or Twitter take.
I value performant code above nearly everything else. I’m doing this for me, there are no other maintainers, and it’s what I enjoy. You’re welcome to prioritize something else in your projects, but it doesn’t others objectively worse.
I maintain ML libraries that run on microcontrollers with kilobytes of memory, performance is a friend of mine ;)
I hate this argument. If current hardware promises you a theoretical throughput of 100 MB/s for an operation, someone will try to hit that limit. Your program that has no hard to understand code but gives me 5 MB/s will loose in the face of a faster one, even if that means writing harder to understand code.
Another favorite of mine is bitshifting / bitwise operators. Clear and obvious? Depends on your background. Fast as hell? Yes, always. It isn’t always needed, but when it is, it will blow anything else out of the water.
Bitwise is highly context dependent. There are simple usages like shifts to divide/multiply by 2. Idiomatic patterns that are clean when wrapped in good reusable and restricted macros, like for common registers manipulation in microcontrollers. And other uses that are anything from involuntary obfuscation to competition grade obfuscation.
Clean code should not do that as the compiler will do that.
Clean code should just say what it wants to do, not replace that with low-level performance optimizations. (Also wasn't performance to be obtained from newer hardware?)
I never said performance should come only from newer hardware. Only that it is possible to trade vs hardware/costs - unlike correctness and trust.
1) Are there no legit code reviews from contributors like this? How did this get accepted into main repos while flying under the radar? When I do a code review, I try to understand the actual code I'm reviewing. Call me crazy I guess!
2) Is there no legal recourse to this? We're talking about someone who managed to root any linux server that stays up-to-date.
Any government which uses GNU/Linux in their infrastructure can pitch this as an attempt to backdoor their servers.
The real question is: will we ever even know who was behind this? If it was some mercenary hacker intending to resell the backdoor, maybe. But if it was someone working with an intelligence agency in US/China/Israel/Russia/etc, I doubt they'll ever be exposed.
So you review would need to guess from 2 new test files that those are, decompressed, a backdoor and could be injected which was never in the git history.
This was explicitly build to evade such reviews.
OK, that is absolutely devious.
And? You never do any mistakes? Google "underhanded C contest"
In a large tech company (including ones I have worked at), sometimes you have policy where every change has to be code reviewed by another person. This kind of stuff isn't possible when the whole project only has 1-2 maintainers. Who's going to review your change other than yourself? This is the whole problem of OSS right now that a lot of people are bringing up.
I maintain a widely used open source project myself. I would love it if I could get high quality code review for my commits similar to my last workplace lol, but very very few people are willing to roll up their sleeves like that and work for free. Most people would just go to the Releases page and download your software instead.
This is also not a new insight. In the beginning of the naughties, there was a web site named kuro5hin.org, which experiemented with user ratings and trust networks. It turned out impossible to prevent take-overs.
It considers trust to be an individual metric instead of leaning more into the graph.
(There are other issues, e.g. the fact that "trust" isn't a universal metric either, but context dependent. There are folks whom you'd absolutely trust to e.g. do great & reliable work in a security context, but you'd still not hand them the keys to your car)
At least kuro5hin modeled a degradation of trust over time, which most models still skip.
It'd be a useful thing, but we have a long way to go before there's a working version.
Kuro5hin had a system which didn't work at all, as you mentioned.
But the best was probably Raph Levien's Advogato. That had a web of trust system which actually worked. But had a pretty limited scope (open source devs).
Now everyone just slaps an upvote/downvote button on and calls it a day.
Nation states will go to long lengths to disguise their identity. Using broken Russian English when they are not Russian, putting comments in the code of another language, and all sorts of other things to create misdirection.
https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.co...
It looks like someone may have noticed a unmaintained or lightly maintained project related to various things, and moved to take control of it.
Otherwhere in the discussion here someone mentions the domain details changed; if you have control of the domain you have control of all emails associated with it.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
pipeing into this shell script which now uses "eval"
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
i guess this will be revisited and removed soon
I don’t actually see an issue with that `eval`. Why would one consider running `xz` followed by `eval`-ing its output more insecure than just running `xz`? If `xz` wants to do shenanigans with the privileges it already has, then it wouldn’t need `eval`’s help for that.
then try to understand the pattern. they backdoored by modifying the build process of packages. now consider the $XZ is also from a backdoored build and the call recognizes in the same way with parameters --robot --version and the shell environment with the hint "xz_wrap.sh" from the piped process. a lot stuff to recognize for the $XZ process that it run as part of a kernel build.
Maybe they put advanced stuff in a backdoored $XZ binary to modify the kernel in a similar way they modified lzma based packages in the build process.
xz --version
I understand it's unlikely, but is there anything I can do to check if the backdoor was used? Also any other steps I should take after "brew upgrade"?
>> Looks like that Homebrew users (both macOS and Linux, both Intel and ARM) are unlikely affected?
> Correct. Though we do not appear to be affected, this revert was done out of an abundance of caution.
xz 5.6.1 -> 5.4.6(or SHAs, etc.)
(EDIT: 5.6.0 and 5.6.1 ?)
(EDIT 2: Ooof, looks like the nix unstable channel uses xz 5.6.1 at this time)
I use Nix to manage this stuff on Mac, not Homebrew...
[0]: https://www.debian.org/doc/debian-policy/ch-controlfields.ht...
Or it could in theory be malware authors (ransomware, etc). However these guys tend to aim at the low hanging fruits. They want to make a buck quickly. I don't think they have the patience and persistence to infiltrate an open source project for 2 long years to finally gain enough trust and access to backdoor it. On the other hand, a state actor is in for the long term, so they would spend that much time (and more) to accomplish that.
So that's my guess: Jia Tan is an employee of some intelligence agency. He chose to present an asian persona, but that's not necessarily who he truly represents. Could be anyone, really: Russia, China, Israel, or even the US, etc.
Edit: given that Lasse Collin was the only maintainer of xz utils in 2022 before Jia Tan, I wouldn't be surprised if the state actor interfered with Lasse somehow. They could have done anything to distract him from the project: introduce a mistress in his life, give him a high-paying job, make his spouse sick so he has to care for her, etc. With Lasse not having as many hours to spend on the project, he would have been more likely to give access to a developer who shows up around the same time and who is highly motivated to contribute code. I would be interested to talk to Lasse to understand his circumstances around 2022.
https://www.mail-archive.com/[email protected]/msg00567.h...
> With your current rate, I very doubt to see 5.4.0 release this year. The only progress since april has been small changes to test code. You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo. Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?
https://www.mail-archive.com/[email protected]/msg00568.h...
The last two sentences really make it look as if he were trying to pressure the original author.
"Your efforts are good but based on the slow release schedule it will unfortunatly be years until the community actually gets this quality of life feature."
"Patches spend years on this mailing list. 5.2.0 release was 7 years ago. There is no reason to think anything is coming soon."
"With your current rate, I very doubt to see 5.4.0 release this year. The only progress since april has been small changes to test code. You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo. Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?"
"Progress will not happen until there is new maintainer. XZ for C has sparse commit log too. Dennis you are better off waiting until new maintainer happens or fork yourself. Submitting patches here has no purpose these days. The current maintainer lost interest or doesn't care to maintain anymore. It is sad to see for a repo like this."
"Is there any progress on this? Jia I see you have recent commits. Why can't you commit this yourself?"
"Over 1 month and no closer to being merged. Not a suprise."
People could also just get tired after years of active maintainership or become busier with life. Being the sole maintainer of an active open source project on top of work and perhaps family takes either a lot of enthusiasm or a lot of commitment. It's not really a given that people want to (or can) keep doing that forever at the same pace.
Someone then spots the opportunity.
I have no idea what the story is here but it might be something rather mundane.
I agree that this is likely a state actor, or at least a very large & wealthy private actor who can play the long game…
Most likely this is not the first backdoor, just the first one to be discovered, so it wasn't two years of work until there were results.
But I still agree that he's probably a state actor.
In fact, that'd be the best form of deep cover. It'll be interested to watch as people more knowledgable than I pour over every single commit and change.
There could be other backdoors for other targets.
(1) A backdoor like this one, which isn't really about its core functions, but about the fact that it's a library linked into critical code, so that you can use it to backdoor _other things_. Those are complex and tricky because you have to manipulate the linking/GOT specifically for a target.
(2) Insert an exploitable flaw such as a buffer overflow so that you can craft malicious .xz files that result in a target executing code if they process your file. This is a slightly more generic attack vector but that requires a click/download/action.
Not every machine or person you want to compromise has an exposed service like ssh, and not every target will download/decompress a file you send to them. These are decently orthogonal attack vectors even though they both involve a library.
(Note that there's as yet no evidence for #2 - I'm just noting how I'd try to leverage this to maximum effect if I wanted to.)
these files are also useful to check that the library we just built works correctly. but they aren't necessary for installation.
we may have more sophisticated procedures that will allow us to use some parts of distribution only for tests. This may significantly reduce an attack vector - many projects have huge, sophisticated testing infrastructure where you can hide the entire Wikipedia.
Yeah, the actor part seems unnecessary now.
The stuxnet malware, which compromised Siemens industrial controls to attack specific centrifuges in uranium enrichment plants in Iran, is a counterexample to that.
But, anyway, I'm sure we can find other counter-examples.
If a government went to this much effort to plant this vulnerability, they absolutely have targets in mind - just like they did when they went to the effort of researching (or acquiring) four separate Windows zero-days, combining them, and delivering them...
Couldn't the account that committed the backdoor have been compromised recently?
You say that as if members of US government agencies didn't plot terror attacks on Americans (Operation Northwood), steal the medical records of American whistleblowers (Ellsberg), had to be prevented from assassinating American journalists (Gordon Liddy, on Jack Anderson), collude to assassinate American political activists (Fred Hampton), spy on presidential candidates (Watergate), sell weapons to countries who'd allegedly supported groups who'd launched suicide bombing attacks on American soldiers (Iran-Contra), allow drug smugglers to flood the USA with cocaine so that they could supply illegal guns to terrorists abroad on their return trip (Iran-Contra again) and get caught conducting illegal mass-surveillance on American people as a whole (Snowden). Among others.
It's super-naive to suggest that government agencies wouldn't act against the interest of American citizens and companies because there might be consequences if they were caught. Most of the instances above actually were instances where the perpetrators did get caught, which is why we know about them.
You kind of lost the thread when you say, “act against the interests of American citizens and companies”. Bro, literally anyone could be using xz, and anyone could be using Red Hat. You’re only “acting against Americans” if you use it against Americans. I don’t know who was behind this, but a perfectly plausible scenario would be the NSA putting the backdoor in with an ostensibly Chinese login and then activating on machines hosted and controlled by people outside of the US.
Focusing on a specific distro is myopic. Red Hat is popular.
There's a term for that: NOBUS (https://en.wikipedia.org/wiki/NOBUS). It won't surprise me at all if this backdoor can only be exploited if the attacker has the private key corresponding to a public key contained in the injected code. It also won't surprise me if this private key ends up being stolen by someone else, and used against its original owner.
And that is exactly why backdoored encryption is bad.
You can discount Japan. This level of patience, sophistication, and precision attack is far beyond the (non-existent) competency of Japanese developers.
The HN crowd has come a long way from practically hero-worshipping Snowden to automatically assuming that 'state actor' must mean the countries marked evil by the US.
I can see some arguments that might persuade the NSA to run an attack like this
- gathers real world data on detection of supply attacks
- serves as a wake-up call for a software community that has grown complacent on the security impact of dependencies
- in the worst case, if no one finds it then hey, free backdoorThere's an implicit "always" in their second sentence, if you're confused by the wording. They aren't positing the equivalent of the guard that only lies.
> It is naive to think that US intelligence agencies will act in the best interest of US citizens or companies.
With an example of them doing exactly that.
Is there something more productive that I could have replied with? (I know I could have been less snippy, but I think being snippy is fair there.)
You coulda just pointed out that just because they did right in the case of DSA, doesn't mean we should actually ever trust them, which I would agree is the correct stance.
Mostly I think that story is neat and wanted people to know about it, so I asked a question as a performative writing technique.
"If you're confused by the wording" was definitely condescending, but I think interpreting guinea-unicorn's post that way doesn't make sense. Even in your reply you didn't say you think it's the right interpretation, just that someone might believe the NSA could "only be up to evil". That followup gives the impression you were giving an FYI for readers. Which is nice to do, but then the "what about" doesn't fit.
So all of that is to say the words "what about" felt like you were deciding to read their post in an unfair way.
I'm happy to listen to an alternate explanation! But you ignored my request for why you said that, and I'm honestly kind of confused as to why that's what set you off.
So overall I think I think my first post can come across as fighty but I don't think the followups should suggest I'm making things fighty. I think my response to 2OEH8eoCRo0 was fine given the way they were ignoring half of the four sentences I had typed.
To be clear, the method of attack was something that had been described in a paper years earlier, the NSA literally had a program (BULLRUN) around compromising and attacking encryption, and there were security researchers at NIST and other places that raised concerns even before it was implemented as a standard. Oh, and the NSA paid the RSA $10 million to implement it.
Heck, even the chairman of the RSA implies they got used by the NSA:
In an impassioned speech, Coveillo said RSA, like many in industry, has worked with the NSA on projects. But in the case of the NSA-developed algorithm which he didn’t directly name, Coviello told conference attendees that RSA feels NSA exploited its position of trust. In its job, NSA plays two roles, he pointed out. In the information assurance directorate (IAD) arm of NSA, it decides on security technologies that might find use in the government, especially the military. The other side of the NSA is tasked with vacuuming up data for cyber-espionage purposes and now is prepared to take an offensive role in cyber-attacks and cyberwar.
“We can’t be sure which part of the NSA we’re working with,” said Coviello with a tone of anguish. He implied that if the NSA induced RSA to include a secret backdoor in any RSA product, it happened without RSA’s consent or awareness.
https://www.networkworld.com/article/687628/security-rsa-chi...
I've never heard anyone claim that Dual_EC_DRBG is most likely not intentionally backdoored, but there's literally no way to confirm because of how its written. If we can't analyze intention from the code, we can look at the broader context for clues. The NSA spent an unusual amount of effort trying to push forward an algorithm that kept getting shot down because it was slower than similar algorithms with no additional benefits (the $10 million deal specified it as a requirement [1]). If you give the NSA the benefit of the doubt, they spent a lot of time and money to... intentionally slow down random number generation?!
As an American, I'd prefer a competent NSA than an incompetent NSA that spends my tax dollars to make technology worse for literally no benefit...
[1] https://www.reuters.com/article/us-usa-security-rsa-idUSBRE9...
I think the best reason to doubt USG involvement is the ease with which somebody discovered this issue, which is only a month or two old. I feel like NSA etc. knows not to get caught doing this so easily.
By comparison America is actually quite timid compared to other countries e.g. UK and the widespread CCTV network.
Now, GCHQ is no better than the NSA for that either, but I don't think CCTV is a good comparison.
And yes, most of modern supporters of Wikileaks / Assange / Snowden / etc, chanting 'release Assange' and 'pardon Snowden' are useful idiots in hands of tyrannies like BRICS club.
Edit: Also, Github has suspended both accounts. Perhaps they know something we don't.
Are you looking at the same repositories I am? He's made 88 commits to xz in that time period, two-thirds of the total.
Lol, what
> wants to cast a wide net to attack as many as possible. So that fits the profile of a government intelligence agency
That's quite backwards. Governments are far more likely to deploy a complex attack against a single target (see also: Stuxnet); other attackers (motivated primarily by money) are far more likely to cast a wide net.
Governments are well known to keep vulnerabilities hidden (see EternalBlue). Intentionally introducing a vulnerability doesn’t seem that backwards tbh
Looks more likely a fake identity than compromised account.
https://char.tw/blog/post/24397301
- All the posts are from 2004/2006. - "jiat" can be abbreviation for many common Chinese names.
That, and I used to contribute to various games (forks of ioquake3) when I was a teen and I wanted to keep my real name private.
That's just what someone with a false identity would say.. get him boys!
The biggest /S
Regardless of how likely you think it is, finding a social media footprint would be useful information. Seek information first, reach conclusions second.
carrd.co [email protected] business https://[email protected]
eBay JiaT75 shopping https://www.ebay.com/usr/JiaT75
giters jiat0218 coding https://giters.com/jiat0218
giters JiaT75 coding https://giters.com/JiaT75
GitHub jiat0218 coding https://github.com/jiat0218
GitHub JiaT75 coding https://github.com/JiaT75
Mastodon-meow.so.. [email protected] social https://meow.social/@[email protected]
https://twitter.com/JiaTan1337/status/1774931375994319244
kind of interesting also to see this account was set up ~2 months ago. if it's a troll, it's a somewhat poor joke.
It looks like gettext may be containing a part of their attack infrastructure.
https://github.com/microsoft/vcpkg/pull/37199#pullrequestrev...
https://github.com/microsoft/vcpkg/pull/37356/files#diff-e16...
This is from Gnulib, which is used by Gettext and other GNU projects. Using 'setlocale (0, NULL)' is not thread-safe on all platforms. Gnulib has modules to work around this, but not all projects want the extra locking. Hence the name '-unsafe'. :)
See: https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg001...
Timeline matches and there is a sudden switch of maintainer. And they add dependency to xz!
[0]: https://git.alpinelinux.org/aports/stats/?period=y&ofs=10
(note: not referring to fedora here, a current fix is required. But just generally. As in, everyone is rolling out this fix, but... I mean, this codebase is poison in my eyes without a solid audit)
> Versions 5.2.12, 5.4.3 and later have been signed with Jia Tan's OpenPGP key . The older releases have been signed with Lasse Collin's OpenPGP key .
It must be assume that before acquiring that privilege, they also contributed code to project. Probably most was to establish respectable record. Still could be malicious code going back someways.
I hope authors of all these projects have been alerted.
STest - Unit testing framework for C/C++. Easy to use by simply dropping stest.c and stest.h into your project!
libarchive/libarchive - Multi-format archive and compression library
Seatest - Simple C based Unit Testing
Everything this account has done should be investigated.
Woha, is this legit or some sort of scam on Google in some way?:
https://github.com/google/oss-fuzz/pull/11587
edit: I have to be missing something, or I'm confused. The above author seems to be primary contact for xz? Have they just taken over?? Or did the bad commit come from another source, and a legit person applied it?
A bit confused here.
Maybe their account is compromised, maybe the username borrows the identity of an innocent person with the same name.
Focus on the code, not people. No point forming a mob.
(e: post above was edited and is no longer directed at the person. thanks for the edit.)
An account that has introduced a backdoor is not the same thing as an account who committed a bug.
Sometimes the distinction is not meaningful, but better safe than sorry.
I would now presume this person to be a hostile actor and their contributions anywhere and everywhere must be audited. I would not wait for them to cry 'but my bother did it', because an actual malicious actor would say the same thing. The 'mob' should be pouring over everything they've touched.
Audit now and audit aggressively.
$ host xz.tukaani.org
host xz.tukaani.org is an alias for tukaani-project.github.io.
And originally it was not:
$ host tukaani.org
tukaani.org has address 5.44.245.25 (seemingly in Finland)
It was moved there in Jan of this year, as per the commit listed in my prior post. By this same person/account. This means that instead of Lasse Collin's more restrictive webpage, an account directly under the control of the untrusted account, is now able to edit the webpage without anyone else's involvement.
For example, to make subtle changes in where to report security issues to, and so on.
So far I don't see anything nefarious, but at the same time, isn't this the domain/page hosting bad tarballs too?
commit af071ef7702debef4f1d324616a0137a5001c14c (HEAD -> master, origin/master, origin/HEAD)
Author: Jia Tan <[email protected]>
Date: Tue Mar 26 01:50:02 2024 +0800
Docs: Simplify SECURITY.md.
diff --git a/.github/SECURITY.md b/.github/SECURITY.md
index e9b3458a..9ddfe8e9 100644
--- a/.github/SECURITY.md
+++ b/.github/SECURITY.md
@@ -16,13 +16,7 @@ the chance that the exploit will be used before a patch is released.
You may submit a report by emailing us at
[[email protected]](mailto:[email protected]), or through
[Security Advisories](https://github.com/tukaani-project/xz/security/advisories/new).
-While both options are available, we prefer email. In any case, please
-provide a clear description of the vulnerability including:
-
-- Affected versions of XZ Utils
-- Estimated severity (low, moderate, high, critical)
-- Steps to recreate the vulnerability
-- All relevant files (core dumps, build logs, input files, etc.)
+While both options are available, we prefer email.
This project is maintained by a team of volunteers on a reasonable-effort
basis. As such, please give us 90 days to work on a fix before
Seems like an attempt to get 90 days of "use" of this vulnerability after discovery. If they only had checked performance before!
Hetzner?
route: 5.44.240.0/21
descr: Zoner Oy
origin: AS201692
mnt-by: MNT-ZONER
created: 2014-09-03T08:09:00Z
last-modified: 2014-09-03T08:09:00Z
source: RIPEFor example, their email is only registered to GitHub and Twitter. They haven't even logged into their Google account for almost a year. There's also no history of it being in any data breaches (because they never use it).
Burn the witch.
They made themselves the primary contact for xz for Google oss-fuzz about one year ago: https://github.com/google/oss-fuzz/commit/6403e93344476972e9...
- Jia Tan <[email protected]>
- jiat75 <[email protected]>
``` amap = generate_author_map("xz")
test_author = amap.get_author_by_name("Jia Cheong Tan")
self.assertEqual(
test_author.names, {"Jia Cheong Tan", "Jia Tan", "jiat75"}
)
self.assertEqual(
test_author.mail_addresses,
{"[email protected]", "[email protected]"}
)
I don't see anything at https://sourcegraph.com/search?q=context:global+author:jiat0...
(I still think it's like... 60% a typo? don't know)
Anyhow, other people called the CCing of JiaT75 by Lasse suspicious:
https://news.ycombinator.com/item?id=39867593
https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.co...
Someone pointed out the "mental health issues" and "some other things"
https://news.ycombinator.com/item?id=39868881
https://www.mail-archive.com/[email protected]/msg00567.h...
Lasse is of course a Nordic name, and the whole project has a finnish name and hosting
https://news.ycombinator.com/item?id=39866902
If I wanted to go rogue and insert a backdoor in a project of mine, I'd probably create a new sockpuppet account and hand over management of the project to them. The above is worringly compatible with this hypothesis.
OTOH, JiaT75 did not reuse the existing hosting provider, but rather switched the site to github.io and uploaded there old tarballs:
https://github.com/tukaani-project/tukaani-project.github.io...
If JiaT75 is an old-timer in the project, wouldn't they have kept using the same hosting infra?
There are also some other grim possibilities: someone forced Lasse to hand over the project (violence or blackmailing? as farfetched as that sounds)... or maybe stole Lasse devices (and identity?) and now Lasse is incapacitated?
Or maybe it's just some other fellow scandinavian who pretended to be chinese and got Lasse's trust. In which case I wish Lasse all the best, and hope they'll be able to clear their name.
Is the same person sockpuppeting Hans Jansen? It's amusing (but unsurprising) that they are using both german-sounding and chinese-sounding identities.
That said, I don't think it's unreasonable to think that Lasse genuinely trusted JiaT75, genuinely believed that the ifunc stuff was reasonable (it probably isn't: https://news.ycombinator.com/item?id=39869538 ) and handed over the project to them.
And at the end of the day, the only thing linking JiaT75 to a nordic identity is a nordic racist joke which could well be a typo. People already checked the timezone of the commits, but I wonder if anyone has already checked the time-of-day of those commits... does it actually match the working hours that a person genuinely living (and sleeping) in China would follow? (of course, that's also easy to manipulate, but maybe they could've slip up)
Anyhow, I guess that security folks at Microsoft and Google (because of JiaT75 email account) are probably going to cooperate with authorities on trying to pin down the identity of JiaT75 (which might not be very useful, depending on where they live).
No, it doesn't:
https://play.clickhouse.com/play?user=play#U0VMRUNUIHRvSG91c...
The vast majority of their Github interactions are between 12.00 UTC and 18.00 UTC
https://news.ycombinator.com/item?id=39874621
> He came on IRC, he seemed ok. He did some cleanup of access and signed off for easter.
That project just includes some metadata about a bunch of sample projects, and it links directly to a mirror of the xz project itself:
https://github.com/se-sic/VaRA-Tool-Suite/blob/982bf9b9cbf64...
I assume it downloads the project, examines the git history, and the test then ensures that the correct author name and email addresses are recognized.
(that said, I haven't checked the rest of the project, so I don't know if the code from xz is then subsequently built, and or if this other project could use that in an unsafe manner)
The google account: "Couldn't find your Google Account"
The email: "50 5.1.1 The email account that you tried to reach does not exist"
But then when you try to register it says it's taken.
Was it disabled?
https://github.com/bytecodealliance/wasmtime/commits?author=...
They've submitted little documentation tweaks to other projects, too; for example:
https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...
I don't know whether this is a formerly-legitimate open source contributor who went rogue, or a deep-cover persona spreading innocuous-looking documentation changes around to other projects as a smokescreen.
He could be doing the same thing for other reasons; nobody really digs into anything very deep so I could see someone handing over co-maintenance to a project based on a decent looking Github graph and some reasonability.
https://github.com/search?q=repo%3Alibarchive%2Flibarchive+j...
It does look innocent enough though. Let's hope there's no unicode trickery involved...
https://github.com/libarchive/libarchive/commit/e37efc16c866...
When the trap is in place deploy a crafted package file that appears invalid on the surface level triggers this trap. In that moment fetch the payload from the (already opened) archive file descriptor, execute it, but also patch the internal state of libarchive so that it will process the rest of the archive file as if nothing happened, and the desired outcome also appearing in the system.
tar.exe was added to Windows this January, sourced from libarchive: https://learn.microsoft.com/en-us/virtualization/community/t...
Unlike the GNU tar I'm used to, it's actually a "full fat" command line archiving tool, compressing & decompressing zip, xz, bz2 on the command-line - really handy :-O
The PR is pretty devious.
JiaT75 claims is "Added the error text when printing out warning and errors in bsdtar when untaring. Previously, there were cryptic error messages" and cites this as fixing a previous issue.
https://github.com/libarchive/libarchive/pull/1609
However it doesn't actually do that!
The PR literally removes a new line between 2 arguments on the first `safe_fprintf()` call, and converts the `safe_fprintf()` to unsafe direct calls to `fprintf()`. In all cases, the arguments to these functions are exactly the same! So it doesn't actually make the error messages any different, it doesn't actually solve the issue it references. And the maintainer accepted it with no comments!
It does remove the safe prefixes... But it also adds one print statement to "strerror()", which could plausibly give better explanations for the error code...
The only suspicious thing here is the lack for safe_ prefix (and the potential for the strerror() function to already be backdoored elsewhere in another commit)
I work on OSS-Fuzz.
As far as I can tell, the author's PRs do not compromise OSS-Fuzz in any way.
OSS-Fuzz doesn't trust user code for this very reason.
Fuzzing isn't really the best tool for catching bugs the maintainer intentionally inserted though.
After all, if it hadn't had a performance regression (someone could submit a PR fixing whatever slowed it down, heh) it still wouldn't be known.
Discussing commits that the other author has since reverted, IFUNC change with Project Zero tests, a focus on embedded, etc.:
https://www.mail-archive.com/[email protected]/msg00642.h...
Trimming security reporting details:
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=af071ef7702...
https://github.com/snappyJack/CVE-request-XZ-5.2.5-has-denia...
He understood the software architecture quite early on while working on the following repository. He connected the dots from his other projects and went rogue. (probably to benefit from crypto?). Take a look at his other repositories and code style and recent likes on github. Is he our Jia Tan?
Secondly, the use of English is not consistent in what should be from typical Indian. He should be from a foreign background or a very reputed English medium.
The language though seemingly simple for a native English speaker but it seems in this case; a person whose first language: likely is not English.
It is possible that Grammarly or auto correct could have been used to write these. But can't be certain of anything stated above.
I do think that this is a sabotage account with 60% chances unless Mr. Kumar comes out clean, publicly. He is likely a state sponsored actor.
> Thanks to Hans Jansen for the original patch.
https://github.com/tukaani-project/xz/pull/53
There were a ton of patches by these two subsequently because the ifunc code was breaking with all sorts of build options and obviously caused many problems with various sanitizers. Subsequently the configure script was modified multiple times to detect the use of sanitizers and abort the build unless either the sanitizer was disabled or the use of ifuncs was disabled. That would've masked the payload in many testing and debugging environments.
The hansjans162 Github account was created in 2023 and the only thing it did was add this code to liblzma. The same name later applied to do a NMU at Debian for the vulnerable version. Another "<name><number>" account (which only appears here, once) then pops up and asks for the vulnerable version to be imported: https://www.mail-archive.com/search?l=debian-bugs-dist@lists...
Also seeing this bug. Extra valgrind output causes some failed tests for me. Looks like the new version will resolve it. Would like this new version so I can continue work.
--
Wow.
(Edited for clarity.)
From https://salsa.debian.org/users/hjansen/activity
Author: Hans Jansen <[email protected]>
- [Debian Games / empire](https://salsa.debian.org/games-team/empire): opened merge request "!2 New upstream version 1.17" - March 17, 2024
- [Debian Games / empire](https://salsa.debian.org/games-team/empire): opened merge request "!1 Update to upstream 1.17" - March 17, 2024
- [Debian Games / libretro / libretro-core-info](https://salsa.debian.org/games-team/libretro/libretro-core-i...): opened merge request "!2 New upstream version 1.17.0" - March 17, 2024
- [Debian Games / libretro / libretro-core-info](https://salsa.debian.org/games-team/libretro/libretro-core-i...): opened merge request "!1 Update to upstream 1.17.0" - March 17, 2024
- [Debian Games / endless-sky](https://salsa.debian.org/games-team/endless-sky): opened merge request "!6 Update upstream branch to 0.10.6" - March 17, 2024
- [Debian Games / endless-sky](https://salsa.debian.org/games-team/endless-sky): opened merge request "!5 Update to upstream 0.10.6" - March 17, 2024
- [Debian / Xz Utils](https://salsa.debian.org/debian/xz-utils): opened merge request "!1 Update to upstream 5.6.1" - March 17, 2024
for example, https://github.com/google/oss-fuzz/pull/10667
An internal call via ifunc is not magic — it’s just a call via the GOT or PLT, which boils down to function pointers. An internal call through a hidden visibility function pointer (the right way to do this) is also a function pointer.
The even better solution is a plain old if statement, which implements the very very fancy “devirtualization” optimization, and the result will be effectively predicted on most CPUs and is not subject to the whole pile of issue that retpolines are needed to work around.
Are they really two people conspiring?
Unless proven otherwise, it is safe to assume one is just a pseudonym alias of the other.
Jia Tan getting maintainer access looks like it is almost certainly to be part of the operation. Lasse Colling mentioned multiple times how Jia has helped off-list and to me it seems like Jia befriended Lasse as well (see how Lasse talks about them in 2023).
Also the pattern of astroturfing dates back to 2022. See for example this thread where Jia, who has helped at this point for a few weeks, posts a patch, and a <name><number>@protonmail (jigarkumar17) user pops up and then bumps the thread three times(!) lamenting the slowness of the project and pushing for Jia to get commit access: https://www.mail-archive.com/[email protected]/msg00553.h...
Naturally, like in the other instances of this happening, this user only appears once on the internet.
I bet they intended for their back door to eventually be merged into the base Amazon Linux image.
So the really strange thing is why they put so little effort into making this undetectable. All they needed was to make it use less time to check each login attempt.
It just requires the SSH port to be reachable unless there is also a callout function (which is risky as people might see the traffic). And with Debian and Fedora covered and the change eventually making its way into Ubuntu and RHEL pretty much everything would have this backdoor.
1. His machine was compromised, he wasn't at fault past having less than ideal security (a sin we are all guilty of). His country or origin/residence is of no importance and doxing him isn't fair to him.
2. This account was malicious. There's no reason we should believe that the identity behind wasn't fabricated. The country of origin/residence is likely falsified.
In neither case is trying to investigate who he is on a public forum likely to be productive. In both cases there's risk of aiming an internet mob at some innocent person who was 'set up'.
1. You don't actually know what has been done by whom or why. You don't know if the author intended all of this, or if their account was compromised. You don't know if someone is pretending to be someone else. You don't know if this person was being blackmailed, forced against their will, etc. You don't really know much of anything, except a backdoor was introduced by somebody.
2. Assuming the author did do something maliciously, relying on personal reputation is bad security practice. The majority of successful security attacks come from insiders. You have to trust insiders, because someone has to get work done, and you don't know who's an insider attacker until they are found out. It's therefore a best security practice to limit access, provide audit logs, sign artifacts, etc, so you can trace back where an incursion happened, identify poisoned artifacts, remove them, etc. Just saying "let's ostracize Phil and hope this never happens again" doesn't work.
3. A lot of today's famous and important security researchers were, at one time or another, absolute dirtbags who did bad things. Human beings are fallible. But human beings can also grow and change. Nobody wants to listen to reason or compassion when their blood is up, so nobody wants to hear this right now. But that's why it needs to be said now. If someone is found guilty beyond a reasonable doubt (that's really the important part...), then name and shame, sure, shame can work wonders. But at some point people need to be given another chance.
If it were me I'd be doing damage control to clear my name if my account was hacked and abused in this manner.
Otherwise if I was doing this knowing full well what would happen then full, complete defederation of me and my ability to contribute to anything ever again should commence -- the open source world is too open to such attacks where things are developed by people who assume good faith actors.
Mitnick reformed after he was convicted (whether you think that was warranted or not). Here if these folks are Mitnick’s or bad actors etc let’s get all the facts on the table and figure this out.
What’s clear is that we all need to be ever vigilant: that seemingly innocent patch could be part of a more nefarious thing.
We’ve seen it before with that university sending patches to the kernel to “test” how well the core team was at security and how well that went over.
Anyways. Yeah. Glad you all allowed me to grow. And I learned that I have an emotional connection to open source for better or worse: so much of my life professional and otherwise is enabled by it and so threats to it I guess I take personally.
There is no requirement to use your real name when contributing to open source projects. The name of the backdoor author ("Jia Tan") might be fake. If it isn't, and if somehow they are found to be innocent (which I doubt, looking at the evidence throughout the thread), they can create a new account with a new fake identity.
Anyways, yes it is an interesting question whether he/she is alone or they are a group. Conway's law probably applies here as well. And my hunch in general is that these criminal mad minds operate individually / alone. Maybe they are hired by an agency but I don't count that as a group effort.
"great" for whom? I've seen enough of the industry to immediately feel suspicious when someone uses that sort of phrasing in an attempt to persuade me. It's no different from claiming a "better experience" or similar.
I have dreamed about an automated LLM system that can "diff" the changes out of the binary and provide some insight. You know give back a tiny bit of power to the user. I'll keep dreaming.
> We tuned up the engine and gave the interiors a thorough clean. Everything is now running smoothly again.
Yeah nah mate, if every release is the first release where everything is running smoothly, I'm not going to believe it this time either.
Makes me wonder if the team has some release quota to fill and will push a build even if nothing meaningful has actually changed.
I don't know how you can be missing the essence of the problem here or that comments point.
Vague claims are meaningless and valueless and are now even worse than that, they are a red flag.
Please don't tell me that you would accept a pr that didn't explain what it did, and why it did it, and how it did it, with code that actually matched up with the claim, and was all actually something you wanted or agreed was a good change to your project.
Updating to the next version of a library is completely unrelated. When you update a library, you don't know what all the changes were to the library, _but the librarys maintainers do_, and you essentially trust that librarys maintainers to be doing their job not accepting random patches that might do anything.
Updating a dependency and trusting a project to be sane is entirely a different prospect from accepting a pr and just trusting that the submitter only did things that are both well intentioned and well executed.
If you don't get this then I for sure will not be using or trusting your library.
don't miss out on the quality code, like the line that has: i += 4 - 2;
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=50255feeaab...
That's confirmed
From https://www.openwall.com/lists/oss-security/2024/03/29/4:
> The files containing the bulk of the exploit are in an obfuscated form in
> tests/files/bad-3-corrupt_lzma2.xz
> tests/files/good-large_compressed.lzma
> committed upstream. They were initially added in
> https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf...
// The "-2" is included because the for-loop will
// always increment by 2. In this case, we want to
// skip an extra 2 bytes since we used 4 bytes
// of input.
i += 4 - 2;https://github.com/JiaT75 was suspended for a moment, but isn't anymore?
The following page for each other show both accounts suspended indeed.
Super frustrating when trying to develop automation. :(
Simply showing one giant page saying "This respository is disabled" is not helpful in any way.
E.g.: I have a specific JPEG committed into a repository because it triggers a specific issue when reading its metadata. It's not just _random_ data, but specific bogus data.
But yeah, if the test blob is purely random, then you can just commit a seed and generate in during tests.
EDIT: Lasse Collin's account @Larhzu has also been suspended.
--
EDIT: Just did a bit of poking. xz-embedded was touched by Jia as well and it appears to be used in the linux kernel. I did quick look and it doesn't appear Jia touched anything of interest in there. I also checked the previous mirror at the tukaani project website, and nothing was out of place other than lagging a few commits behind:
https://gist.github.com/Qix-/f1a1b9a933e8847f56103bc14783ab7...
--
Here's a mailing list message from them ca. 2022.
https://listor.tp-sv.se/pipermail/tp-sv_listor.tp-sv.se/2022...
--
MinGW w64 on AUR was last published by Jia on Feb 29: https://aur.archlinux.org/cgit/aur.git/log/?h=mingw-w64-xz (found by searching their public key: 22D465F2B4C173803B20C6DE59FCF207FEA7F445)
--
pacman-static on AUR still lists their public key as a contributor, xz was last updated to 5.4.5 on 17-11-2023: https://aur.archlinux.org/cgit/aur.git/?h=pacman-static
EDIT: Actually the sources list 5.6.1, which is pulling the XZ specifically (not the auto-generated GZ): https://aur.archlinux.org/packages/pacman-static
--
Alpine was patched as of 6 hours ago.
https://git.alpinelinux.org/aports/commit/?id=982d2c6bcbbb57...
--
OpenSUSE is still listing Jia's public key: https://sources.suse.com/SUSE:SLE-15-SP6:GA/xz/576e550c49a36... (cross-ref with https://web.archive.org/web/20240329235153/https://tukaani.o...)
--
Arch appears to still list Jia as an approved publisher, if I'm understanding this page correctly.
https://gitlab.archlinux.org/archlinux/packaging/packages/xz...
EDIT: Just sent an email to the last committer to bring it to their attention.
EDIT: It's been removed.
--
jiatan's Libera info indicates they registered on Dec 12 13:43:12 2022 with no timezone information.
-NickServ- Information on jiatan (account jiatan):
-NickServ- Registered : Dec 12 13:43:12 2022 +0000 (1y 15w 3d ago)
-NickServ- Last seen : (less than two weeks ago)
-NickServ- User seen : (less than two weeks ago)
-NickServ- Flags : HideMail, Private
-NickServ- jiatan has enabled nick protection
-NickServ- *** End of Info ***
Either way, I do hope LE will get into this. They better cooperate.
I respect them for that.
Violating that code is just as bad as the bad actor slipping backdoors.
https://git.alpinelinux.org/aports/log/main/gettext
libunistring could also be affected as that has also been pushed there
No.
> libunistring could also be affected as that has also been pushed there
What do you mean by "that"?
Why? Isn't it better to freeze them and let as many people as possible analyze the code?
1. They don't have the ability to freeze repos (i.e. would require some engineering effort to implement it), as I've never seen them do that before.
2. Many distros (and I assume many enterprises) were still linking to the GitHub releases to source the infected tarballs for building. Disabling the repo prevents that.
The infected tarballs and repo are still available elsewhere for researchers to find, too.
It looks like one of Jia Tan's commits (328c52da8a2) added a stray "." character to a piece of C code that was part of a check for sandboxing support, which I guess would cause the code to fail to compile, causing the check to fail, causing the sandboxing to be disabled.
> Those days are pretty much behind us. Sure, you can compile code and tweak software configurations if you want to--but most of the time, users don't want to. Organizations generally don't want to, they want to rely on certified products that they can vet for their environment and get support for. This is why enterprise open source exists. Users and organizations count on vendors to turn upstreams into coherent downstream products that meet their needs.
> In turn, vendors like Red Hat learn from customer requests and feedback about what features they need and want. That, then, benefits the upstream project in the form of new features and bugfixes, etc., and ultimately finds its way into products and the cycle continues.
"and when the upstream is tainted, everyone drinks poisoned water downstream, simple as that!"
A feature which allowed the exploit to take place, let's put it that way.
Over here: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
> The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf. The version of build-to-host.m4 in the release tarballs differs wildly from the upstream on GitHub.
Multiple suggestions on that thread on how that's a legacy practice that might be outdated, especially in the current climate of cyber threats.
Someone even posted a more thorough gist on what could be done to increase transparency and reduce discrepancies between tarballs and repos: https://gist.github.com/smintrh78/97b5cb4d8332ea4808f25b47c8...
git pull git@github:all the deps to make my startup work development practices will never be secured. Too many layers of leaky abstraction.
I anticipate such obliviousness and so far, indifference, by the “go fast, disrupt” industry will motivate governments to push for more software on chip.
He has been part of the xz project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.