|
proprietary software vendors don’t have solutions to the issues exposed by this since it’s mostly a series of political issues, it’s sad that people are only proposing technical solutions
|
#
?
Mar 31, 2024 14:57
|
|
|
|
| # ? May 15, 2024 13:07 |
|
|
mmmmmm yea nah. the altruistic community has to catch this every single time, and it has been happenstance rather than designed safeguards that found issues so far. the bad guys only have to win once and it can be real real bad. like collapse of a federal reserve banking system bad.
|
|
#
?
Mar 31, 2024 14:59
|
|
|
fresh_cheese posted:mmmmmm yea nah.
|
|
#
?
Mar 31, 2024 15:00
|
|
|
fresh_cheese posted:mmmmmm yea nah. propeietary vendors are no less subject to the whims of state-sponsored apts
|
|
#
?
Mar 31, 2024 15:05
|
|
|
Backdoors have to snuck into open source at least, compared to a state just going to a company and telling them they'll insert a backdoor
|
|
#
?
Mar 31, 2024 15:06
|
|
|
im not saying proprietary software rulez im saying the oss community needs to be more skeptical about adding dependencies on rando libraries
|
|
#
?
Mar 31, 2024 15:08
|
|
|
fresh_cheese posted:im not saying proprietary software rulez
|
|
#
?
Mar 31, 2024 15:09
|
|
|
fresh_cheese posted:im not saying proprietary software rulez Agreed, but not just (or even mainly) because of security issues. Also, while I think this is primarily a political and/or social problem, there are also possible technical solutions, like capability systems and poo poo that prevents dependencies from doing completely arbitrary things. (Probably not really practical with our current knowledge of computers.)
|
|
#
?
Mar 31, 2024 15:10
|
|
|
when an oss project adds a dependency on some other oss project, the bullshit and bad practices of the included project rolls up and applies to the including project. at the moment, it seems like everybody just assumes their dependancies are on the up and up and have no bad practices so hell yea #include fart.h awesome if you are going to call somebody elses code from your code and their code turns out to be evil im saying thats on you if you did insufficient diligence in vetting that code and that communities practices. im blaming the sshd and systemd teams here, only slightly less than the actual xz bad actor.
|
|
#
?
Mar 31, 2024 15:21
|
|
|
fresh_cheese posted:when an oss project adds a dependency on some other oss project, the bullshit and bad practices of the included project rolls up and applies to the including project.
|
|
#
?
Mar 31, 2024 15:23
|
|
|
The sshd developers didn't have anything to do with this. The patch was added by distributions. And the patch itself added a completely unnecessary dependency on libsystemd; the systemd notification protocol is by sending a single datagram to a local socket. You're not expected to include all of libsystemd just to do that. This is simply poor craftsmanship in the sshd patch. I don't know whether libsystemd has a justified dependency on xz, but I don't really see a problem with an omnibus library needing to decompress poo poo. Athas fucked around with this message at 15:30 on Mar 31, 2024 |
|
#
?
Mar 31, 2024 15:24
|
|
|
fresh_cheese posted:im entitled to have programmers who also practice opensource as a hobby do due diligence that i don’t expect from anyone else, and furthermore
|
|
#
?
Mar 31, 2024 15:24
|
|
|
please please please read this post before you post anything else, fresh_cheese because the above poo poo is loving intolerable
|
|
#
?
Mar 31, 2024 15:26
|
|
|
tbf fresh_cheeses take is entirely compatible with the sensible "stop doing that" solution, which is also real good for preventing burnout
|
|
#
?
Mar 31, 2024 15:32
|
|
|
Cybernetic Vermin posted:tbf fresh_cheeses take is entirely compatible with the sensible "stop doing that" solution, which is also real good for preventing burnout
|
|
#
?
Mar 31, 2024 15:35
|
|
|
BlankSystemDaemon posted:doing the equivalent of a kid kicking up a fuzz, grabbing their toys, and going home no, im asking others to go home
|
|
#
?
Mar 31, 2024 15:36
|
|
|
BlankSystemDaemon posted:please please please read this post before you post anything else, fresh_cheese While the point of this post is true & appreciated, there is the twist that the ungrateful mailing list posters cited in that post are likely to be sock puppets of whichever bad actor decided to attack xz-tools, intended to pressure the original developer into adding a new evil maintainer.
|
|
#
?
Mar 31, 2024 15:36
|
|
|
Athas posted:While the point of this post is true & appreciated, there is the twist that the ungrateful mailing list posters cited in that post are likely to be sock puppets of whichever bad actor decided to attack xz-tools, intended to pressure the original developer into adding a new evil maintainer.
|
|
#
?
Mar 31, 2024 15:39
|
|
|
if im paying money for support and security fixes then the distro better be owning this vetting if nobody else in the community feels like its their problem
|
|
#
?
Mar 31, 2024 15:42
|
|
|
fresh_cheese posted:if im paying money for support and security fixes then the distro better be owning this vetting if nobody else in the community feels like its their problem if
|
|
#
?
Mar 31, 2024 15:45
|
|
|
fresh_cheese posted:if im paying money for support and security fixes then the distro better be owning this vetting if nobody else in the community feels like its their problem lol
|
|
#
?
Mar 31, 2024 15:46
|
|
|
a giant glaring security vulnerability appears, again the community participants collectively put their finger on their nose and say “not it” regarding whos responsibility it was to catch that all agree that its fine and nothing needs to be done because see we found it! lol
|
|
#
?
Mar 31, 2024 15:51
|
|
|
fresh_cheese posted:a giant glaring security vulnerability appears, again
|
|
#
?
Mar 31, 2024 15:52
|
|
|
fresh_cheese posted:a giant glaring security vulnerability appears, again i agree Someone needs to do Something
|
|
#
?
Mar 31, 2024 15:55
|
|
|
Athas posted:The sshd developers didn't have anything to do with this. The patch was added by distributions. And the patch itself added a completely unnecessary dependency on libsystemd; the systemd notification protocol is by sending a single datagram to a local socket. You're not expected to include all of libsystemd just to do that. This is simply poor craftsmanship in the sshd patch. i'm not sure anything has a justified dependency on liblzma, there's an independent lzma implementation (that is not vulnerable to this exploit since it executed in the build stage) in the kernel already. xz-utils is a bit different since you presumably need some sort of front-end for the archiver, but some cli wrapper around a compression library shouldn't be that complex anyway sb hermit posted:why not just stop development on these things unless it’s critically important yeah i think this position is where i'm at (with poo poo like liblzma anyway) now. like, was a supposedly slightly faster CRC32 implementation reeeeaaallly worth all this bullshit? Beeftweeter fucked around with this message at 16:08 on Mar 31, 2024 |
|
#
?
Mar 31, 2024 16:06
|
|
|
mystes and athas raise excellent points im just an email address on the internet tho, so not to be trusted by anyone whos opinion matters Ill have a conversation with the security weasel at work to see about what can be done
|
|
#
?
Mar 31, 2024 16:13
|
|
|
that's theoretically why oss projects have maintainers and code reviews and poo poo. the process breaks down when it's just one guy suffering extreme burnout though, making the project vulnerable to this kind of "benevolent" maintainer stepping in idk what a good solution to this might be. identify critical packages and have salaried employees review the code? seems like everyone's definition of critical might vary, and if you're paying someone to review or maintain the code then there's always the "well gently caress everyone else" incentive to just make it a closed source project but doing that would mean no visibility into the code at all, by anyone, and i think we can all agree that would be worse. so what's your better solution here?
|
|
#
?
Mar 31, 2024 16:39
|
|
|
i mean in some respects this is the system working, right? like in any kind of layered action model you can point to the layers that got bypassed before the one that caught it, and the luck of the specific layer that caught it, but the entire point of the many-eyes philosophy is an inversion of the classic attacker has to be right once, defender has to be right every time: the attacker has to get past all the defenders, and each individual defender only has to get lucky once. this code was not shipped in the lts distros. the distros that had incorporate in testing phase and unstable releases have to revert, which they are capable of doing. and the reason that it was caught and that this is possible and fast is that somebody could be doing perf testing, and could notice something wrong, and could go and look at the source for why. it is not perfect and it should be improved and step 0 of that improvement should be paying, but i think people leaping to an indictment of the oss model as a whole are kind of missing the forest for the trees
|
|
#
?
Mar 31, 2024 17:04
|
|
|
Phobeste posted:i mean in some respects this is the system working, right? like in any kind of layered action model you can point to the layers that got bypassed before the one that caught it, and the luck of the specific layer that caught it, but the entire point of the many-eyes philosophy is an inversion of the classic attacker has to be right once, defender has to be right every time: the attacker has to get past all the defenders, and each individual defender only has to get lucky once. this code was not shipped in the lts distros. the distros that had incorporate in testing phase and unstable releases have to revert, which they are capable of doing. and the reason that it was caught and that this is possible and fast is that somebody could be doing perf testing, and could notice something wrong, and could go and look at the source for why.
|
|
#
?
Mar 31, 2024 17:12
|
|
|
mystes posted:I mean it just barely got caught by chance because someone was profiling sshd or something and it had gotten pretty far so it is a little concerning but I don't know what the solution is in this particular case, reduce the number of nooks in which some shady poo poo can hide. there was something lurking in the tarball that wasn't in the git repository. this sort of story is the way in which engineering processes improve in practice, by writing the rules in blood.
|
|
#
?
Mar 31, 2024 17:23
|
|
|
I mean a dude spent two years of his state sponsored life to infiltrate a zip project only to have his payload get caught by a guy benchmarking software on a bleeding edge distribution that only crazies would use in an environment where they want safe data. How fast did the high fives stop, do you think? I’m in no way even reasonably informed how all this poo poo works but the idea that some smugdog using Arch btw interrupted what could have been a heist of the decade is very funny to me. Very 10,000 monkeys with a typewriter energy.
|
|
#
?
Mar 31, 2024 17:27
|
|
|
unironically burn autotools to the ground and replace it with meson leaving aside the "build everything from upstream tarballs" vs. "build everything from git" vs. "build everything from tarballs that are constructed only using the contents of the git repository" debate which is gonna play out in linux distros for the next few years there is no good reason why the build system needs to be several megabytes of unreadable, un- version controlled shell scripts so that linux developers can cosplay that they're writing portable code. "portable" now means your platform looks enough like linux that you can run linux code
|
|
#
?
Mar 31, 2024 17:35
|
|
|
a dude slipped a backdoor into a crack between what's in git and what's in a tarball. the solution to prevent this particular exploit from happening again is to have a stronger chain of custody from code reviews to source control to distribution build scripts, i.e. by tying build scripts to particular source control commit ids instead of a "dude trust me bro" tarball that is just assumed to reflect a particular git tag. this isn't new and we knew that we should be doing that to begin with, but nonetheless a bunch of distros (almost) got caught sleeping. this rule is part of the movement towards reproducible builds in general, but this rule is now written and underlined in blood. you learn from specific catastrophic or near-catastrophic incidents and devise specific rules to prevent them from happening again, that's how this sort of thing works in practice.
|
|
#
?
Mar 31, 2024 17:36
|
|
|
if anything it is a far more specifically teachable moment than something like heartbleed or the log4j catastrofuck. the latter was particularly awful because that library literally had rce as its documented albeit unintended behavior and somehow nobody noticed.
|
|
#
?
Mar 31, 2024 17:40
|
|
|
I wonder if there should also be some move to try to somehow simplify build processes in general so it's harder to hide stuff there? I don't know how that would look though
|
|
#
?
Mar 31, 2024 17:43
|
|
|
Would the xz attack have been found sooner if it had been present in the commit log? I think it is pretty easy to hide obfuscated things in build scripts.
|
|
#
?
Mar 31, 2024 17:43
|
|
|
it would have been much harder because then a diff to introduce a backdoor would need to pass code review and a plausible good-faith justification would have to be presented. of course, this assumes that people are actually looking at and participating in a key dependency's development and it isn't just a one-man show that every major cloud company silently mooches off. the main factor saving us from that aspect of the attack is the fact that the bar for inclusion into the base packages for debian is way higher than it is for publishing something to the npm or pypi trash heap. a change of upstream maintainer for a key dependency like that should be cause for scrutiny. we already follow this rule elsewhere: in the browser add-on world a change in maintainership for popular a add-on is immediately treated with great suspicion because of a repeated history of attacks like this. so we have one human-factors takeaway and one technological takeaway from this incident.
|
|
#
?
Mar 31, 2024 17:54
|
|
|
Athas posted:Would the xz attack have been found sooner if it had been present in the commit log? I think it is pretty easy to hide obfuscated things in build scripts. you mean, like, a commit with the comment "adds backdoor exploit to openssh"? yeah probably
|
|
#
?
Mar 31, 2024 17:54
|
|
|
Beeftweeter posted:you mean, like, a commit with the comment "adds backdoor exploit to openssh"? yeah probably so yeah, not using tarballs that can have stuff not tracked in git is definitely a start
|
|
#
?
Mar 31, 2024 17:55
|
|
|
|
| # ? May 15, 2024 13:07 |
|
|
most of the components of the attack were present in the git repository, for instance the compiled shell code was disguised as compression test data to detect that specific thing, you probably have to build some sort of data processing pipeline that emits the net new binary content added to the git repos of some however defined core set of open source repositories and then hand off the output to reviewers. essentially an anti-steganography problem then the obvious countermeasure would be to hex encode or base64 encode the payload so that it bypasses such a detection pipeline, so now you gotta recognize unusual text content as well
|
|
#
?
Mar 31, 2024 17:57
|
|