This is a scary one ... CVE-2024-3094 - Page 1
Forum section: electronics / general

author: bingo600
author_rank: Super Contributor
timestamp: March 30, 2024, 06:12:55 am
content: DammmThis one is scary- Malicious code in liblzma upsream code detected.https://www.openwall.com/lists/oss-security/2024/03/29/4https://nvd.nist.gov/vuln/detail/CVE-2024-3094Especially because itmightbe "An inside job"Multistage planned, and "impressingly well done"Right now ... Prob only bleeding edge installs are affected.But since it was in upstream, if not detected. It would have propagated.My Ubu 22.04 or Deb12 arent affected.Edit:Just beggining to look at this one - Doesn't look nice toohttps://pwning.tech/nftables/

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 30, 2024, 07:51:43 am
content: Wow.Note that the official github account on which the repo was hosted has been taken down:https://github.com/tukaani-project/xzThis is serious stuff here.

author: bingo600
author_rank: Super Contributor
timestamp: March 30, 2024, 08:33:49 am
content: Quote from: SiliconWizard on March 30, 2024, 07:51:43 amYuppBut if correct ... Then "adding" "extra key-sigs" to SSH ...IS SERIOUSOne can only wonder :WHY did the Author(s) do it ?- Especially if it's an inside job ...Smells somewhat of "3 letters" from whatever country.

author: madires
author_rank: Super Contributor
timestamp: March 30, 2024, 09:45:29 am
content: FAQ on the xz-utils backdoor:https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27Debian:https://lists.debian.org/debian-security-announce/2024/msg00057.htmlopenSUSE:https://news.opensuse.org/2024/03/29/xz-backdoor/The first affected version is 5.6.0.

author: voltsandjolts
author_rank: Unknown
timestamp: March 30, 2024, 10:08:29 am
content: https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/

author: bingo600
author_rank: Super Contributor
timestamp: March 30, 2024, 12:07:03 pm
content: From comments in the above faq:

author: madires
author_rank: Super Contributor
timestamp: March 30, 2024, 01:02:16 pm
content: Quote from: bingo600 on March 30, 2024, 08:33:49 amIt wasn't the original maintainer, but someone called 'Jia Tan' (joined the project two years ago).Quote from: bingo600 on March 30, 2024, 08:33:49 amIndeed! From all the information available I see many hints pointing to a long term covert operation of a state actor. And in this case the collateral damage would have been HUGE. Luckily Andres came across the backdoor early before the new xz-util version could go mainstream. They even tried to push v5.6.1 for several linux distributions. We have to be more cautious and diligent with checking code commits, no matter if its a large and critical project or some tiny and boring one.

author: Bud
author_rank: Super Contributor
timestamp: March 30, 2024, 01:42:55 pm
content: Every time an exploit or attack happens that receives wide attention we are told it was "very sophisticated" one created by an army of uniformed people from an evil state. After the hype dies it turnes out that it was done by a bored 16 year old kiddy in grandmo's basement.

author: madires
author_rank: Super Contributor
timestamp: March 30, 2024, 01:45:04 pm
content: Interesting timeline (work in progress) with details about who did what and when:Everything I Know About the Xz Backdoor:https://boehs.org/node/everything-i-know-about-the-xz-backdoor

author: bingo600
author_rank: Super Contributor
timestamp: March 30, 2024, 02:33:08 pm
content: Fromhttps://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006017#gistcomment-5006017https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024Unofficial discussions on Debian downgrading to 5.3.1If 5.4.x is hit too by something ...Theycommitted 700+ patches "there"Then my DEB12's are at risk ....And i just upgraded from 11 to 12 , like 3 weeks agoCode:$xz --versionxz (XZ Utils) 5.4.1liblzma 5.4.1I'm glad i haven't got any linuxes exposed directly on @All are behind a firewall (not linux)Well mailserver has Port 25 open (portforwarded via fwall) ... That's allAnd my mailserver is still at Deb11Code:$ xz --versionxz (XZ Utils) 5.2.5liblzma 5.2.5

author: madires
author_rank: Super Contributor
timestamp: March 30, 2024, 02:40:55 pm
content: Quote from: Bud on March 30, 2024, 01:42:55 pmI don't have that impression. Most attacks or exploits don't make it into mainstream media anyway, and stay in the admin or security world. At the moment mainstream media reports primarily about new victims of crypto trojans. There were only a few reports about recent Microsoft disasters (in reality MS needs to be considered totally compromised). I'd say that the largest chunk of attacks is performed by cybercriminals, followed by state actors or state sponsored groups, some hackers (for fun and fame), script kiddies trying to become hackers, and at last the odd 16 year old. I can hardly imagine a 16 year old kiddy playing with m4 (a macro language, well known to sendmail users, used for the xz-utils backdoor).

author: bingo600
author_rank: Super Contributor
timestamp: March 30, 2024, 02:57:07 pm
content: Quote from: madires on March 30, 2024, 02:40:55 pmMe neitherI'm using sendmail.And after reading the "Bat book" ... Istillthink that when Stallman wrote m4 he must have been "on mushrooms" ... (Read as a joke)

author: madires
author_rank: Super Contributor
timestamp: March 30, 2024, 02:57:19 pm
content: Quote from: bingo600 on March 30, 2024, 02:33:08 pmNo need to panic! Let's wait and see what code reviews will dig up. Those 700+ commits could be real fixes, improvements, added features and so on. And we also don't know yet what the concrete impact on sshd is. But I agree that a reasonable precaution would be to limit ssh access.

author: shapirus
author_rank: Super Contributor
timestamp: March 30, 2024, 03:41:14 pm
content: Debian team was quick to push a fix.I love the version number:Code:$ apt show xz-utilsPackage: xz-utilsVersion: 5.6.1+really5.4.5-1changelog:Code:xz-utils (5.6.1+really5.4.5-1) unstable; urgency=critical* Non-maintainer upload by the Security Team.* Revert back to the 5.4.5-0.2 version-- Salvatore Bonaccorso <carnil@debian.org> Thu, 28 Mar 2024 15:59:38 +0100

author: bingo600
author_rank: Super Contributor
timestamp: March 30, 2024, 03:52:00 pm
content: Quote from: shapirus on March 30, 2024, 03:41:14 pmIf it's 5.4.5.x+ that's affected.Then my Deb12'sCode:xz --versionxz (XZ Utils) 5.4.1liblzma 5.4.1Are in the clear ... for now

author: shapirus
author_rank: Super Contributor
timestamp: March 30, 2024, 04:11:09 pm
content: Quote from: bingo600 on March 30, 2024, 03:52:00 pm5.6.0+, as far as the backdoor in question is considered.Quote from: bingo600 on March 30, 2024, 03:52:00 pmYes, for now. It remains to be seen if any of the code committed by that person has other vulnerabilities. As far as I understand, the original author is currently reviewing all of those commits.I wonder if force pushes were allowed on that repo. If they were, it'll make audit much more complicated.

author: golden_labels
author_rank: Super Contributor
timestamp: March 30, 2024, 06:15:07 pm
content: The attacker was very focused at what they did, so many distributions may be unaffected even if they ship 5.6 branch. For example on Arch Linux sshd is not even using liblzma. The author might’ve hidden more surprises, but for now there is no indication other commits were malicious. It’s possible they either used them to build reputation or the identity was stolen.It’s also worth noting that xz was affected, but the person was active elsewhere too. Code they experimented with included LZ4, libarchive, zstd (Meta) and Microsoft docs. They didn’t commit to these repos, but the bullets might’e missed us by inches. They also worked with many unspecified proprietary repositories.In general I’d say it’s best to let the dust settle and wait for the news from people, who are currently working on resolving the issue. Sensationalism isn’t serving anybody in this case. At worst it may open opportunities for FUD or be noticed by general population media.Quote from: Bud on March 30, 2024, 01:42:55 pmThese two are not mutually exclusive. Perhaps wearing an uniform in grandma’s basement may be inconvenient, but don’t get carried away with the perfection level achieved in government agencies. It’s primarily a matter of organisation, funding and coördination, not personal skills.The sophistication level is in this case in plain sight too. That’s not an opinion of anonymous TV expert: what the attacker done has been outlined and you can compare that to baseline.

author: bingo600
author_rank: Super Contributor
timestamp: March 30, 2024, 06:22:34 pm
content: Now there's "apparently" a bit on the exploit "payload"https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006538#gistcomment-5006538leads tohttps://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2bSeems to be an RCE exploit , not auth bypass.

author: Bud
author_rank: Super Contributor
timestamp: March 30, 2024, 06:28:44 pm
content: "Apparently". Yes, a good one to my collection of "seems to", "we speculate", "potentially", "could be", and such.Show me the MEAT, not your creative thinking.

author: bingo600
author_rank: Super Contributor
timestamp: March 30, 2024, 06:46:40 pm
content: Quote from: Bud on March 30, 2024, 06:28:44 pmWhat got in to you ?Did you even read the link'sApparently was chosen as the wording, because it has not been confirmed by others yet (single source)

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: March 30, 2024, 07:16:04 pm
content: Quote from: bingo600 on March 30, 2024, 06:12:55 amI used buildroot a few days ago for an embedded target, and when I read about the xzutils CVE, I checked and the version reported is 5.4.4. My understanding is that buildroot pulls sources from the project's repos so would qualify as bleeding edge. Target is an iMX6, if that matters.

author: madires
author_rank: Super Contributor
timestamp: March 30, 2024, 08:57:09 pm
content: A nice explanation how the backdoor payload is obfuscated:xz/liblzma: Bash-stage Obfuscation Explained:https://gynvael.coldwind.pl/?lang=en&id=782

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 30, 2024, 10:04:07 pm
content: Quote from: golden_labels on March 30, 2024, 06:15:07 pmYes, I'm on Arch, and xz did get affected. They let the 5.6.0 and 5.6.1 slip with this issue. It was quickly fixed though. So xz-5.6.0 is affected, xz-5.6.1-1 is affected, xz-5.6.1-2 is fixed. Check if you're concerned and if so, just update your system.

author: Nominal Animal
author_rank: Super Contributor
timestamp: March 30, 2024, 10:51:40 pm
content: A good reminder that the human in the security chain is always the weakest link. And that when you collaborate with someone on a widely-used project, make sure you know the actual human, including real-world traceability and contact when this kind of crap occurs. A single e-mail address and connections via VPN is definitely not that.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 30, 2024, 10:55:14 pm
content: Yeah. And people wonder/complain about why it's so "difficullt" to contribute to projects such as Linux kernel or GCC. Maybe now you realize why.Thing is, this kind of event may trigger the requirement to share one's identity in full for contributing to any open-source software, at some point. Which is something I'm not sure I like either.So, I don't know how to tackle this other than by strict review processes, which are very time-consuming.

author: golden_labels
author_rank: Super Contributor
timestamp: March 30, 2024, 11:31:06 pm
content: Trust is not trivial and neither knowing the person, nor credentials are foolproof either. I remind you of theUniversity of Minnesota incidentorFreenode takeover.Quote from: SiliconWizard on March 30, 2024, 10:04:07 pmNo worries:Code:[2024-03-29T08:10:22+0100]  upgraded xz (5.6.1-1 -> 5.6.1-2)And a hint: compare the update time with when Phoronix announced the bug.Arch recommends updating 5.6.1-2 and I strongly suggest doing the same. But that’s an advice. Advices are not trying to accurately describe reality.If you want to, and until then not figure it out yourself, in a few days I will tell the details.(1)It’s not a secret, but I don’t want to make somebody not follow the recommendation or argue with it based on what I wrote. This would be very unfortunate.(1)c8e7d38a7257c23d1b035f8012c265d87ab12479ddbde60761f1e4c221851271

author: 44kgk1lkf6u
author_rank: Regular Contributor
timestamp: March 31, 2024, 02:38:14 am
content: Quote from: SiliconWizard on March 30, 2024, 10:55:14 pmWhy would verifying one's identity help at all?

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 31, 2024, 05:17:38 am
content: Quote from: 44kgk1lkf6u on March 31, 2024, 02:38:14 amAgain, not saying I like the idea either. For a number of reasons.But the rationale would be making contributors of open-source software, especially software that is widely used, liable. Unfortunately, complete anonymity prevents any kind of liability. If a contributor, just like in this very story, injects something malicious and nobody even knows how to go after them, that can be considered a serious issue. Particularly if the consequences were severe. If the full identity of this guy was known, I doubt he would have pushed this malicious stuff.So, that's just the idea. Not saying it's a solution, but I doubt it won't be raised at some point.I find it fun that someone the nickname of which is just a code would be the one to ask this question, though.Probably just a coincidence.

author: Nominal Animal
author_rank: Super Contributor
timestamp: March 31, 2024, 09:09:06 pm
content: Quote from: 44kgk1lkf6u on March 31, 2024, 02:38:14 amWhen the real-world human behind the actions is contactable/trackable, the two main things are:Social pressure, lack of cover, lack of anonymity.Do not underestimate how much more difficult it is to pull this kind of thing off, especially more than once, when your identity is known to the target.It is easy to exploit people you do not know, but much harder to exploit people you do know. Most people are not suited for police and intelligence undercover work, and those that are, usually need actual training to pull it off; and even then, some people get "turned" simply due to the close interaction.Legal action.While this kind of shenanigans are unlikely to lead to a court case, if the identity of the perpetrator is known, their international movements and even bank transfers will be monitored by Interpol and intelligence services, because this kind of thing is a security risk at the governmental level.I do not know if "liability" is the correct term for this here –– it might;Ido not know –– but the above two are the "realistic" effects in my opinion.I slightly disagree with SiliconWizard in that I don't mind the requirement of revealing ones identity in full; I mind any kind of requirement ofpublishingcontributors identities (in full, or in sufficient detail to be targeted by others who don't like your output, or would like to, uh, "entice" you to introduce some security hole or another).That is, I do not see a problem having to reveal ones identity in full to a projectmaintaineror a small group of maintainers. Because of their position in the project, they are already in a position of trust. That is also sufficient to "trigger" my points above.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 31, 2024, 09:36:51 pm
content: Quote from: golden_labels on March 30, 2024, 11:31:06 pmYes, the situation is not all rosy as the issue is, actually, not really "fixed" as I got it. But at least the last package update should, for now, avoid running into it. That is, if xz doesn't contain yet other problems that haven't been detected yet. Who knows. I think they are currently analyzing all commits made by this guy.xz has been criticized for a number of other reasons anyway, so maybe time to drop it altogether.On Arch, it wasn't used by sshd, but xz can be used for compressing the kernel image, and it may even have been the default compression at some point. The last Arch install I did, xz was used for that, but I had switched to zstd, because it was much faster and I didn't care for the small difference in compression ratio for that.But I'm guessing that using it for the kernel image could potentially cause a whole range of nasty issues too. Not sure yet.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 01, 2024, 01:07:07 am
content: A bit of history for the whole affair here:https://unicornriot.ninja/2024/xz-utils-software-backdoor-uncovered-in-years-long-hacking-plot/Another one:https://boehs.org/node/everything-i-know-about-the-xz-backdoorYeah.

author: radiolistener
author_rank: Super Contributor
timestamp: April 01, 2024, 01:24:08 am
content: here is the page with description, it has the bash script at the end which checks if your system is vulnerable for this issue.https://www.openwall.com/lists/oss-security/2024/03/29/4And here is the page with update about this issue from Lasse Collin (original author of xz):https://tukaani.org/xz-backdoor/

author: mfro
author_rank: Regular Contributor
timestamp: April 01, 2024, 01:13:02 pm
content: Really smells like an attack from a three letter organization.Let alone the fact that the backdoor wasn't implemented in the main code but in the tarball packaging (boring stuff and probably not under close inspection of the most knowledgeable developers). Then the infiltration of the spy/saboteur over years - could be right from an espionage thriller.The very same thing can/will happen (or happened already) at commercial vendors. The only difference: we'll probably never come to know.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 01, 2024, 09:32:00 pm
content: Yes, just the way it was all prepared over a couple years, patiently, the guy gaining trust until he got more responsibilities, that's pretty nasty and is unlikely to come from just a lone wolf.Now one lesson to learn is not to rely on pieces of software that are just maintained by one person for anything critical, that's just insane. Here it's malicious, but it could just as well have come from an unintentional security hole. (Reminds me a bit of the log4j debacle, in that sense.) It's like almost every Linux distro has been using xz without even knowing exactly what it did (the specs themselves are a mess), who was behind it, and whether it was actually a good idea to use it.The xz format (not even its implementation) has been studied and is known to have severe flaws. Sure, you got better compression ratios with it that most other compression tools (although that's not always the case depending on the content), but was it worth using it blindly?

author: golden_labels
author_rank: Super Contributor
timestamp: April 01, 2024, 10:10:39 pm
content: If only we gave control to some large company, they would provide us with security. Not some filthy amateurs not able to maintain their own projects. If that was Microsoft, such a situation would never happen. They would never let Jia Tan’s code slip into their flagship product. Neve… oh, oops!Are you people sober? On one hand you believe this was done by a state actor. On the other you act as if that was a problem on Lasse Collin’s end. I just wait to see Diaz’s 2016 article, because suddenly everybody needs a rationalization for xz being the issue. Secondary victimization never dies. This is really getting disgusting. 🤦

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 01, 2024, 11:53:59 pm
content: Quote from: SiliconWizard on April 01, 2024, 09:32:00 pmYou mean like CVE-2021-3560 (polkit privilege escalation), which was missed for only seven years, and exploitable trivially using a shell script?Of course, the difference here is that because the affected projected was not part of the blessed SystemD, it is okay (and not hateful) to blame xz as a project.(And that the xz one is a remote execution bug and CVE-2021-3560 is a privilege escalation one.)Quote from: golden_labels on April 01, 2024, 10:10:39 pmMy three-letter agency can beat your three-letter agency, so there! Besides, Ineedbranding to validate my feelings of security, now that nationalism and preference for non-POC/non-DEI-based culture is universally condemned as colonialistic and evil.I think Lasse Collin acted irresponsibly for not verifying the identity of the person they handed control of the project over to. Everything else is the distributions' and software developers own damn fault, for not giving a shit about the stuff they rely on.

author: hans
author_rank: Super Contributor
timestamp: April 04, 2024, 11:29:14 am
content: Quote from: SiliconWizard on March 30, 2024, 10:55:14 pmI think another key take away is that any discussion that becomes emotional can become a security hijack by design.Things like: "Please hurry up, we need this fixed" or "doing things XYZ like you did is absolutely stupid" or "this project deserves more"Ironically this would make some other key figures in OSS a major security hazard as well.When it comes to review processes.. the use of binary blobs appears to be another puzzle piece: I've seen elsewhere people saying that blobs should never appear in [open source] code. But I disagree.. for compression libraries, its necessary to test malformed streams. You could generate or manipulate malformed streams, but such tests can quickly escalate into integration tests instead. It can become a real mess to manage..Fortunately there are not that many repo's out there where binary blobs are a relative need, though, so that is hopefully a slight relief. I don't think this backdoor would have been possible for every repository. It is compounded by compression libraries being looked at with very few people.. If you don't have sound theoretical knowledge its unlikely you can contribute very much to them. I don't think its fair to then blame that every repo with only 2 maintainers is bad, because that's reality I'm afraid.I don't think an ID will help much. It would probably also repel many genuine privacy focused developers. We can't say for sure if this was the work of a solo hacker, an underground group or a gov agency. In the latter, they also have spies and can probably arrange any ID they need. I don't think Jia Tan even exists. At best, asking for IDs would provide a false sense of security and perhaps an unnecessary hurdle. Besides.. many security/intel agency also had their own share of whistleblowers or moles..

author: nctnico
author_rank: Super Contributor
timestamp: April 04, 2024, 12:43:36 pm
content: Quote from: Nominal Animal on March 30, 2024, 10:51:40 pmTrue, but this case is also an example open source as a concept to develop software in a large scale collaboration works due to the many eyes looking at the software. For sure it is not the first time something like this happens on purpose or by mistake but it gets out in the open. And most importantly, it gets fixed.How many planted security exploits are there in closed source software?

author: mfro
author_rank: Regular Contributor
timestamp: April 04, 2024, 01:26:20 pm
content: Quote from: nctnico on April 04, 2024, 12:43:36 pmUmm. In this specific case it appears it still was not enough eyes on the code.I think the main culprit was that the attack was targeted against the source package (probably something no interested and skilled main developer really wants to spend too much time on, so even less eyes). A simple "fix" to that could be if distributions would build upon the released git checkout instead?What I still don't get is how Andres Freund found the issue. He wrote he had seen unusual high cpu load from ssh connection attempts that failed during performance testing of a Postgres database. Did he really do tests using a testing OS version on a publicly accessible machine?

author: madires
author_rank: Super Contributor
timestamp: April 04, 2024, 02:00:26 pm
content: Not much info about that.Fomhttps://mastodon.social/@AndresFreundTec/112180406142695845:QuoteFromhttps://www.openwall.com/lists/oss-security/2024/03/29/4:Quote

author: Bud
author_rank: Super Contributor
timestamp: April 04, 2024, 02:44:21 pm
content: This story does not pass a BS sniff test. Do you "state actor" theory proponents really think a state actor would leave such stupidly obvious indicators behind?

author: shapirus
author_rank: Super Contributor
timestamp: April 04, 2024, 03:00:18 pm
content: Quote from: Bud on April 04, 2024, 02:44:21 pmEasy.

author: golden_labels
author_rank: Super Contributor
timestamp: April 04, 2024, 06:49:38 pm
content: Quote from: Bud on April 04, 2024, 02:44:21 pmThe question is apparently to proponents of the state actor explanation, so I’m not the one asked, but I’ll respond nonetheless.Not sure what indicators you’re talking about, but whatever they left: yes, a state actor would leave “stupidly obvious indicators” behind. I don’t know, how you imagine operations carried out by state agencies. But reality is not spy fiction and action movies.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 04, 2024, 09:13:37 pm
content: Quote from: hans on April 04, 2024, 11:29:14 amYes, of course. Note that this one happens frequently in for-profit companies too. That's how engineers are pressured. Manipulated.Quote from: hans on April 04, 2024, 11:29:14 amProbably.Quote from: hans on April 04, 2024, 11:29:14 amBinary blobs *purely for testing purposes* are "fine", the issue is with whatever code uses them. Binary blobs should be used *only* for testing known good outputs vs. actual outputs and the code for testing should be as simple and straightforward as possible. Period. Anything looking remotely "clever" for this should be banned. Also, the testing phase should be checked to have absolutely zero impact on the built artefacts themselves.In this xz case, the testing code was so ridiculously convoluted that it should have triggered suspicion immediately, even if it wasn't malicious. The issue is that nobody looked at it until it was too late.

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 04, 2024, 11:37:13 pm
content: It is also a good reminder of how true security has to be baked in to the entire design, entire development chain, entire process; and not just added on top as an afterthought.This particular vulnerability/exploit shows how dynamic linking mechanisms can be used via a library required by a library required by the actual target binary. Theifuncmechanism allows this without using an interposingconstructorfunction using thedllibrary; it was mostly used for obfuscation. Renaming the target function and using aweakrefalias would have raised eyebrows.As an attack pattern, it means thatevery library is security sensitivewhen a binary executed with privileges is considered.As it is not realistic to expect every single library to be fully vetted for security –– we do not have enough willing eyeballs for that –– the only viable approach isprivilege separation. That requiresmodularity, and when combined, directly leads tominimalismto limit the security sensitive surfaces, including library dependencies (direct and indirect). Add theKISS principleas a reminder, and you get theUnix philosophy.Which is why I so snarkily referenced CVE-2021-3560, which was a seven-year wide open privilege escalation flaw, resulting exactly from rejecting the points in the above paragraph. Security is not athingyou can add, it is a fundamental approach to the entire task chain.

author: shapirus
author_rank: Super Contributor
timestamp: April 05, 2024, 01:10:37 am
content: ...systemd esse delendam.

author: Nominal Animal
author_rank: Super Contributor
timestamp: April 05, 2024, 02:16:26 am
content: Quote from: shapirus on April 05, 2024, 01:10:37 amFor me, it is only an example of widespread use of an obvious security and single point failure risk (with a track record proving that), resulting from a deliberate rejection of privilege separation, modularity, and minimalism; and how good PR and social interaction and community management can convince otherwise smart people to acquiesce to stupid stuff.(Consider the case where instead of an untraceable pseudonym, the changes to xz were made by a well-known, well-trusted developer. There would be huge social pressure on their side, claiming inexcusable racist/ideological/personal accusations without any foundation. That is what makes it so enticing forsecurity actorsto turn key developers. In my opinion, the only workable solution is totrust no-one any more than you absolutely have to, and suspect everyone, even yourself; the key point in privilege separation.)Another similar point is the entire security scheme used to implement interactive websites (including this one) under Apache or Nginx. The idea of running scripts under the same user account that owns the scripts or the directories they lie in is exactly opposite to everything we know about multi-user security from the last fifty years or more.None of these rants is new to anyone who has read my posts on similar subjects. If only I had thecharismaorreputationto convince anyone and make a difference...

author: shapirus
author_rank: Super Contributor
timestamp: April 05, 2024, 09:02:04 am
content: Quote from: Nominal Animal on April 05, 2024, 02:16:26 amThat's why, when I had to run WordPress in production, I implemented it in a way that: a) it does not have write access to the local file system whatsoever; b) there is no block storage volume or other file system mount point other than the container image's tree; c) the containers that it runs in are completely ephemeral.No in-place plugin updates. No way to overwrite any PHP code on local drive. No way for wp admins (yes some stuff unfortunately requires to grant admin privileges to regular editors) to screw up anything on the local fs. Reproducible builds. Easy to make changes and roll back.It made it, of course, somewhat of a pain in the ass to manage, at times, since a great number of WP plugin developers have horse shit in place of their brains (including big ones like Elementor -- and I do loosely guess that it can be said aboutmostof plugins), which makes them assume that there is always a writable location under the WP root directory -- not only under wp-uploads/, but, sometimes, even other locations! But the long-term gains outweigh that.That's an example of how it can sometimes be possible to mitigate the inherent security risks of poorly designed software.

author: golden_labels
author_rank: Super Contributor
timestamp: April 07, 2024, 05:53:41 pm
content: I believe a week is enough. Aspromised, an explanation. The full shell-ed explanation at the bottom. A shorter explanation here:Arch Linux never included the patch, which was pulling liblzma into OpenSSH, so “/usr/bin/sshd” on Arch was never touched by this vulnerability.xz-5.6.1-1 was built from the affected tar with malicious build instructions, but these instructions — as far as it’s known — were not executed against Arch Linux. xz-5.6.1-2 and xz-5.6.1-3 are built directly from a repo tag, not including the malicious instructions.The policy is to update to at least 5.6.1-2and I will stand by that despite what I write below. Advisory statements and positive statements about factual state are, however, very different beasts.5.6.1-1 and 5.6.1-2 actually produce the same liblzma, bit-to-bit identical regarding any executable path. There are two tiny differences in.note.gnu.build-idand.gnu_debuglinksections. Neither of which is meant to be executed and doesn’t even make sense as code.5.6.1-3 is an unrelated rebuild, which coincidently alsodoesn’t permit Jia Tan’s keysanduses Tukaani repo instead of GitHub, but the resulting liblzma is identical.Code:$ printf 'sshd in arch does not use liblzma. 5.6.1-2 is bit-to-bit identical to 5.6.1-1 except two dozen non-code bytes.\n\n' | sha256sumc8e7d38a7257c23d1b035f8012c265d87ab12479ddbde60761f1e4c221851271 -$ find . -name 'xz-*.pkg.tar.zst' -exec pacman-key --verify {}.sig {} \;==> Checking ./xz-5.6.1-2-x86_64.pkg.tar.zst.sig... (detached)gpg: Signature made Thu 28 Mar 2024 22:08:25 CETgpg: using EDDSA key 05C7775A9E8B977407FE08E69D4C5AA15426DA0Agpg: Note: trustdb not writablegpg: Good signature from "Frederik Schwan <frederik.schwan@linux.com>" gpg: aka "Frederik Schwan <frederik@schwan.it>" gpg: aka "Frederik Schwan <frederik@tty42.de>" gpg: aka "Frederik Schwan <freswa@archlinux.org>" gpg: aka "Frederik Schwan <frederik@schw4n.de>" gpg: aka "Frederik Schwan <frederik.schwan@mailbox.org>" ==> Checking ./xz-5.6.1-1-x86_64.pkg.tar.zst.sig... (detached)gpg: Signature made Sat 09 Mar 2024 21:00:37 CETgpg: using EDDSA key 0429897DE5F3BDAC537A30696D42BDD116E0068Fgpg: Note: trustdb not writablegpg: Good signature from "Christian Hesse <eworm@archlinux.org>" ==> Checking ./xz-5.6.1-3-x86_64.pkg.tar.zst.sig... (detached)gpg: Signature made Mon 01 Apr 2024 22:41:01 CESTgpg: using EDDSA key 0429897DE5F3BDAC537A30696D42BDD116E0068Fgpg: Note: trustdb not writablegpg: Good signature from "Christian Hesse <eworm@archlinux.org>" $ sha256sum xz-*.pkg.tar.zst63b219db0b2f0b6215cc4e4ca64f3fa59b914e7b15bde17c36bf2b21e459c13e xz-5.6.1-1-x86_64.pkg.tar.zst17e95679c62d901fc7fe27879ec241d3566603a4eaa6a7a38ccc0e6c28ef60a6 xz-5.6.1-2-x86_64.pkg.tar.zst609db91285658f0ba12fa472407f0b583fceb6741654fcf0cf0e26312dc46cd0 xz-5.6.1-3-x86_64.pkg.tar.zst$ for n in 1 2 3; do tar -xOf xz-5.6.1-$n-x86_64.pkg.tar.zst usr/lib/liblzma.so.5.6.1 >liblzma.so.5.6.1-"$n"; done$ sha256sum liblzma.so.5.6.1-*e47d67ec12cb43715d5ce42ded202f4acea6a1d0172edf58523a3e6d444a5c45 liblzma.so.5.6.1-1c1a58591631a5bdeff4bd9ac1eae16b6ae392f9c96f17aedae3664448c290f0b liblzma.so.5.6.1-2c1a58591631a5bdeff4bd9ac1eae16b6ae392f9c96f17aedae3664448c290f0b liblzma.so.5.6.1-3$ diff <(xxd liblzma.so.5.6.1-1) <(xxd liblzma.so.5.6.1-2)48,49c48,49< 000002f0: 0300 0000 474e 5500 71f9 a255 f686 4e44 ....GNU.q..U..ND< 00000300: c325 3a10 dc37 9c25 c8bf b302 0000 0000 .%:..7.%........---> 000002f0: 0300 0000 474e 5500 69df 3c77 1c62 8668 ....GNU.i.<w.b.h> 00000300: 86ef f245 d5b1 5834 540d f808 0000 0000 ...E..X4T.......12804c12804< 00032030: 2e36 2e31 2e64 6562 7567 0000 82fd 6f66 .6.1.debug....of---> 00032030: 2e36 2e31 2e64 6562 7567 0000 4ad1 cc28 .6.1.debug..J..($ objdump -h liblzma.so.5.6.1-{1,2}liblzma.so.5.6.1-1: file format elf64-x86-64Sections:Idx Name Size VMA LMA File off Algn0 .note.gnu.property 00000040 00000000000002a8 00000000000002a8 000002a8 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA1 .note.gnu.build-id 00000024 00000000000002e8 00000000000002e8 000002e8 2**2CONTENTS, ALLOC, LOAD, READONLY, DATA2 .gnu.hash 00000624 0000000000000310 0000000000000310 00000310 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA3 .dynsym 00000ea0 0000000000000938 0000000000000938 00000938 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA4 .dynstr 00000bc4 00000000000017d8 00000000000017d8 000017d8 2**0CONTENTS, ALLOC, LOAD, READONLY, DATA5 .gnu.version 00000138 000000000000239c 000000000000239c 0000239c 2**1CONTENTS, ALLOC, LOAD, READONLY, DATA6 .gnu.version_d 000000ec 00000000000024d8 00000000000024d8 000024d8 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA7 .gnu.version_r 000000b0 00000000000025c8 00000000000025c8 000025c8 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA8 .rela.dyn 00000870 0000000000002678 0000000000002678 00002678 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA9 .relr.dyn 00000030 0000000000002ee8 0000000000002ee8 00002ee8 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA10 .init 0000001b 0000000000003000 0000000000003000 00003000 2**2CONTENTS, ALLOC, LOAD, READONLY, CODE11 .text 00021049 0000000000003020 0000000000003020 00003020 2**4CONTENTS, ALLOC, LOAD, READONLY, CODE12 .fini 0000000d 000000000002406c 000000000002406c 0002406c 2**2CONTENTS, ALLOC, LOAD, READONLY, CODE13 .rodata 00006c28 0000000000025000 0000000000025000 00025000 2**5CONTENTS, ALLOC, LOAD, READONLY, DATA14 .eh_frame_hdr 00000a34 000000000002bc28 000000000002bc28 0002bc28 2**2CONTENTS, ALLOC, LOAD, READONLY, DATA15 .eh_frame 00004540 000000000002c660 000000000002c660 0002c660 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA16 .init_array 00000008 00000000000313f0 00000000000313f0 000313f0 2**3CONTENTS, ALLOC, LOAD, DATA17 .fini_array 00000008 00000000000313f8 00000000000313f8 000313f8 2**3CONTENTS, ALLOC, LOAD, DATA18 .data.rel.ro 00000718 0000000000031400 0000000000031400 00031400 2**5CONTENTS, ALLOC, LOAD, DATA19 .dynamic 00000200 0000000000031b18 0000000000031b18 00031b18 2**3CONTENTS, ALLOC, LOAD, DATA20 .got 000002e8 0000000000031d18 0000000000031d18 00031d18 2**3CONTENTS, ALLOC, LOAD, DATA21 .data 00000008 0000000000032000 0000000000032000 00032000 2**3CONTENTS, ALLOC, LOAD, DATA22 .bss 00000008 0000000000032008 0000000000032008 00032008 2**0ALLOC23 .comment 0000001b 0000000000000000 0000000000000000 00032008 2**0CONTENTS, READONLY24 .gnu_debuglink 0000001c 0000000000000000 0000000000000000 00032024 2**2CONTENTS, READONLYliblzma.so.5.6.1-2: file format elf64-x86-64Sections:Idx Name Size VMA LMA File off Algn0 .note.gnu.property 00000040 00000000000002a8 00000000000002a8 000002a8 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA1 .note.gnu.build-id 00000024 00000000000002e8 00000000000002e8 000002e8 2**2CONTENTS, ALLOC, LOAD, READONLY, DATA2 .gnu.hash 00000624 0000000000000310 0000000000000310 00000310 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA3 .dynsym 00000ea0 0000000000000938 0000000000000938 00000938 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA4 .dynstr 00000bc4 00000000000017d8 00000000000017d8 000017d8 2**0CONTENTS, ALLOC, LOAD, READONLY, DATA5 .gnu.version 00000138 000000000000239c 000000000000239c 0000239c 2**1CONTENTS, ALLOC, LOAD, READONLY, DATA6 .gnu.version_d 000000ec 00000000000024d8 00000000000024d8 000024d8 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA7 .gnu.version_r 000000b0 00000000000025c8 00000000000025c8 000025c8 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA8 .rela.dyn 00000870 0000000000002678 0000000000002678 00002678 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA9 .relr.dyn 00000030 0000000000002ee8 0000000000002ee8 00002ee8 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA10 .init 0000001b 0000000000003000 0000000000003000 00003000 2**2CONTENTS, ALLOC, LOAD, READONLY, CODE11 .text 00021049 0000000000003020 0000000000003020 00003020 2**4CONTENTS, ALLOC, LOAD, READONLY, CODE12 .fini 0000000d 000000000002406c 000000000002406c 0002406c 2**2CONTENTS, ALLOC, LOAD, READONLY, CODE13 .rodata 00006c28 0000000000025000 0000000000025000 00025000 2**5CONTENTS, ALLOC, LOAD, READONLY, DATA14 .eh_frame_hdr 00000a34 000000000002bc28 000000000002bc28 0002bc28 2**2CONTENTS, ALLOC, LOAD, READONLY, DATA15 .eh_frame 00004540 000000000002c660 000000000002c660 0002c660 2**3CONTENTS, ALLOC, LOAD, READONLY, DATA16 .init_array 00000008 00000000000313f0 00000000000313f0 000313f0 2**3CONTENTS, ALLOC, LOAD, DATA17 .fini_array 00000008 00000000000313f8 00000000000313f8 000313f8 2**3CONTENTS, ALLOC, LOAD, DATA18 .data.rel.ro 00000718 0000000000031400 0000000000031400 00031400 2**5CONTENTS, ALLOC, LOAD, DATA19 .dynamic 00000200 0000000000031b18 0000000000031b18 00031b18 2**3CONTENTS, ALLOC, LOAD, DATA20 .got 000002e8 0000000000031d18 0000000000031d18 00031d18 2**3CONTENTS, ALLOC, LOAD, DATA21 .data 00000008 0000000000032000 0000000000032000 00032000 2**3CONTENTS, ALLOC, LOAD, DATA22 .bss 00000008 0000000000032008 0000000000032008 00032008 2**0ALLOC23 .comment 0000001b 0000000000000000 0000000000000000 00032008 2**0CONTENTS, READONLY24 .gnu_debuglink 0000001c 0000000000000000 0000000000000000 00032024 2**2CONTENTS, READONLY# Neither of the sections with differences contain executable code, but# just to make it clear it would be garbage: disassembled contents of each.$ objdump -Sj .note.gnu.build-id liblzma.so.5.6.1-{1,2}liblzma.so.5.6.1-1: file format elf64-x86-64Disassembly of section .note.gnu.build-id:00000000000002e8 <.note.gnu.build-id>:2e8:04 00add $0x0,%al2ea:00 00add %al,(%rax)2ec:14 00adc $0x0,%al2ee:00 00add %al,(%rax)2f0:03 00add (%rax),%eax2f2:00 00add %al,(%rax)2f4:47rex.RXB2f5:4e 55rex.WRX push %rbp2f7:00 71 f9add %dh,-0x7(%rcx)2fa:a2 55 f6 86 4e 44 c3movabs %al,0x3a25c3444e86f655301:25 3a303:10 dcadc %bl,%ah305:37(bad)306:9cpushf307:25 c8 bf b3 02and $0x2b3bfc8,%eaxliblzma.so.5.6.1-2: file format elf64-x86-64Disassembly of section .note.gnu.build-id:00000000000002e8 <.note.gnu.build-id>:2e8:04 00add $0x0,%al2ea:00 00add %al,(%rax)2ec:14 00adc $0x0,%al2ee:00 00add %al,(%rax)2f0:03 00add (%rax),%eax2f2:00 00add %al,(%rax)2f4:47rex.RXB2f5:4e 55rex.WRX push %rbp2f7:00 69 dfadd %ch,-0x21(%rcx)2fa:3c 77cmp $0x77,%al2fc:1c 62sbb $0x62,%al2fe:86 68 86xchg %ch,-0x7a(%rax)301:efout %eax,(%dx)302:f2 45repnz rex.RB304:d5 b1 58 34 54addps (%r28,%r18,2),%xmm6309:0d.byte 0xd30a:f8clc30b:08.byte 0x8$ objdump -Sj .gnu_debuglink liblzma.so.5.6.1-{1,2}liblzma.so.5.6.1-1: file format elf64-x86-64Disassembly of section .gnu_debuglink:0000000000000000 <.gnu_debuglink>:0:6cinsb (%dx),%es:(%rdi)1:69 62 6c 7a 6d 61 2eimul $0x2e616d7a,0x6c(%rdx),%esp8:73 6fjae 79 <XZ_5.0@@XZ_5.0+0x79>a:2e 35 2e 36 2e 31cs xor $0x312e362e,%eax10:2e 64 65 62 75 67 00(bad)17:0018:82(bad)19:fdstd1a:6foutsl %ds:(%rsi),(%dx)1b:66data16liblzma.so.5.6.1-2: file format elf64-x86-64Disassembly of section .gnu_debuglink:0000000000000000 <.gnu_debuglink>:0:6cinsb (%dx),%es:(%rdi)1:69 62 6c 7a 6d 61 2eimul $0x2e616d7a,0x6c(%rdx),%esp8:73 6fjae 79 <XZ_5.0@@XZ_5.0+0x79>a:2e 35 2e 36 2e 31cs xor $0x312e362e,%eax10:2e 64 65 62 75 67 00(bad)17:0018:4a d1 ccrex.WX ror $1,%rsp1b:28.byte 0x28

author: radiolistener
author_rank: Super Contributor
timestamp: April 10, 2024, 01:03:32 am
content: Quote from: SiliconWizard on April 04, 2024, 09:13:37 pmBinary blob may exploit some code vulnerability, like stack overflow to execute some raw code from the binary blob...And the code which uses it will be clean...So, I don't think this is fine...

author: golden_labels
author_rank: Super Contributor
timestamp: April 10, 2024, 04:21:43 pm
content: Executable blobs are something I despise. But data blobs? Ignoring testing for a moment: you need image, audio, game-specific data for programs. One might argue their place is not in the main repository. But in practice this is a common situation. And for many tests data, including invalid data, is a requirement. Generating it at test time from code is not a solution: the code becomes opaque for any more complicated case and it’s equally trivial to hide malicious payload in it. Or, under a pretense of dynamically generating invalid cases from an trusted blob, cut and stich fragments to get the desired result.I wouldn’t focus on blob’s presence. This part of the attack was the first to be detected too, early enough to not cause harm. Focus more on what led to it. Careful, long-term execution. Building reputation. Social engineering, including sockpuppeting, brutally exploiting health situation of Lasse Collin. Having commits accepted by two of top-5 technology companies, and nobody noticing anything.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 10, 2024, 08:48:40 pm
content: Binary data that is not executable can't execute anything on its own. If it leads to code execution, this is by exploiting some other code that reads said data and has a bug. (Or does so intentionally.)So when using binary data for testing purposes, you basically have 2 cases:- Known good outputs: the tests execute the tested code under various known conditions and its binary output is compared to the "binary blob" - usually with the simplest tool possible, such as 'diff', which has no exploit that I know of (but not claiming it has none, who knows, and I didn't fully check that). In the case of a compression library, for instance, you'd compare the output of the compression for known inputs to the expected binary output. End of the story.- Inputs: similarly, you may need to test your code with known binary inputs. In the case of a compression library, again, that may be the input data that you want to compress as a test. Binary inputs *may* trigger an exploit in the tested code, if said code has any. But this would happen only while testing, and if it happens at this test stage, that would normally be good news (as long as you can detect it.)"Unacceptable" uses of binary blobs include: executables, and third-party *code* that may extract nasty code from said blobs (which was the case in the xz affair). But either of these cases are, IMO, obvious issues. (Not saying that they are always obvious to see, although again in the xz case, just properly reviewing the build and test scripts would have shown it quickly.)But not using any binary data, I don't know how you can if you're testing code that is meant to read or write binary data itself. At some point you need to test it with actual inputs and check that the outputs are what's expected. If you know how to properly test, say again as an example, a compression library without using any binary data, let me know.

author: golden_labels
author_rank: Super Contributor
timestamp: April 10, 2024, 10:51:18 pm
content: In this case the blob wasn’t included as something to be executed. It was data for tests. And, if I understand correctly, inclusion binary data for tests is being discussed. Am I wrong?

author: madires
author_rank: Super Contributor
timestamp: April 17, 2024, 06:40:18 am
content: Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects:https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/Quote