IRC channel logs
2024-04-03.log
back to list of logs
<oriansj>Googulator: fair enough perspective. Was a thought from the recent xz-utils autotools situation. <stikonas>well, but backdoor can be inserted into other build systems too <pabs3>and one of the malicious commits was to the cmake files, an extra dot was inserted to make sure the landlock build test code was invalid and thus landlock was disabled <oriansj>well yes, any build system could be used to create a backdoor (even kaem) the question I was pondering is what would make it harder and more obvious if possible. <stikonas>the whole backdoor was very elaborate but fragile <oriansj>which as I understand it, openssh never really needed systemd to function and without it xz would have never been pulled in. <pabs3>and if systemd had a proper libsystemd-notify instead of the monolithic libsystemd, that backdoor path wouldn't have been possible <pabs3>(they still refuse to split up libsystemd in that way) <stikonas>well, some distros didn't patch openssh... <stikonas>so e.g. gentoo had backdoored version but doesn't look like it was affected <pabs3>right, the backdoor wasn't compiled in when libsystemd was not used <oriansj>(and the openrc and shepard users rejoiced) <stikonas>pabs3: I guess it's not trivial to split it <oriansj>well systemd hasn't exactly taken too kindly to breaking up into smaller and easier to accept chunks. <pabs3>at first glance it looked like a small number of functions to implement notify to me <pabs3>but systemd devs are vehemently against splitting it <pabs3>there are various folks talking about implementing a third-party notify-only shared library now, to avoid libsystemd <pabs3>but anyways, probably all this is offtopic :) <oriansj>or on topic depending on if we are exploring the problem space in xz-utils and our trust models <oriansj>also wasn't there a proposed fork of systemd a few years back? <oriansj>the last commit was 2022, so it isn't highly active <Googulator>Looks like Lasse Collin at least got his GitHub account back <Googulator>no more suspended badge, unlike for the JiaT75 account <Googulator>(I'm intentionally not saying "Jia's" account, as there's evidence "Jia" is not a real person) <stikonas>well, there is some evidence that Jia might be from UTC+2 or UTC+3 (depending on DST) <pabs3>commit timezones come from the attacker, so that is probably fake <pabs3>(and IIRC when the author vs commit timezones are accounted for, it becomes clear that isn't the right timezone) <stikonas>pabs3: commit timezones (mostly UTC+8) do come from attacker, but there are 2 or 3 commits with UTC+2/UTC+3 <stikonas>(and provably not travelling, as it can be very close in time to UTC+8 commits) <pabs3>IIRC those come from the other maintainer, where the patch was sent via mail from the patch author to the patch committer <pabs3>ACTION not sure if github displays author times or committer times <pabs3>right, but the analysis in that article talks about github <pabs3>the stuff I mention about author vs committer times was discussed on the #tukaani channel <pabs3>ACTION wonders if GitHub also records git push times somewhere, and if they will ever support signed git pushes <pabs3>hmm, the post does mention author vs committer times <pabs3>I joined way too late, but apparently the channel went from 10 people to hundreds :) <stikonas>after all, that's what it displays in pull requests <stikonas>it would show last commit was done e.g. 5 minutes ago <stikonas>though I guess publicly announcing this xz vulnarebility also makes it harder to catch the person <stikonas>you could only hope on some opsec errors in the past <pabs3>IIRC the known IP addresses were of some VPN company in Singapore anyway, and the whole thing seems like a team of people at an org like the NSA <pabs3>so probably impossible to catch <pabs3>IIRC the event that sped up the timeline on it was that systemd was moving xz usage to dlopen, which would break the sshd backdoor <pabs3>very much looks like that rather than any other actor <pabs3>especially the pressure operations and the backdoor where you have to sign the payload with a particular key <stikonas>well, I guess nop in particular can be done in various ways <oriansj>pabs3: well doing strings in assembly that also function as executable code is a common trick; so it isn't surprising to find the reverse. <oriansj>(which is something auditing hex0 through M0 would need to keep in mind)