111–120 of 862 posts
[flagged]
Also, given that Go binaries are statically linked, if you can't rebuild from source, you're screwed. You need to get good at building from source.
Earlier quoted context omitted.
Sure they do. Getting the perpetrator into your jurisdiction is the tough part. Putin is, for example, unlikely to go anywhere willing to execute an ICC arrest warrant.
Nah, the CIA assassinates people in MLAT zones all the time. The laws that apply to you and I don’t apply to the privileged operators of the state’s prerogatives. We don’t even know that this specific backdoor wasn’t the NSA or CIA. Assuming it was a foreign intelligence service because the fake name was asian-sounding is a bit silly. The people who wrote this code might be sitting in Virginia or Maryland already.
Eastern Europe, suggest the timestamp / holiday analysts. https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...
Earlier quoted context omitted.
[flagged]
based on what?
However, the times don't make sense: It looks like he works mostly at 2am: https://files.catbox.moe/6mdtez.png (hours in the +0800 timezone). I understand this to be indicative of using a different timezone on the computer than where he actually worked, possibly knowing that git commits include the timezone.
If you shift the timezone to US East Coast -0400, it suddenly looks like a very comfortable full-time job, including a fall in commit rate right where the lunch break should be: https://files.catbox.moe/dtvjzr.png
To me, considering that this appears to be a nation-state tier attack, heavily indicates that it was the Americans. Obviously not conclusive proof, but I think it is useful evidence.
Earlier quoted context omitted.
They also used social engineering to disable fuzzing which would have caught the discrepancy: https://github.com/google/oss-fuzz/pull/10667
It’s pretty funny how a bunch of people come piling reaction emojis onto the comments in the PR, after it has all become publicly known. I’m like.. bro, adding reaction emojis after the fact as if that makes any sort of difference to anything.
Earlier quoted context omitted.
> The math of the lzma algorithm doesn't change. The library was "done" and that's ok. Playing devil's advocate: the math doesn't change, but the environment around it does. Just off the top of my head, we have: the 32-bit to 64-bit transition, the removal of pre-C89 support ( https://fedoraproject.org/wiki/Changes/PortingToModernC ) which requires an autotools update, the periodic tightening of undefined behaviors,…
> the 32-bit to 64-bit transition Lzma is from 2010. Amd64 became mainstream in the mid 2000s. > removal of pre-C89 support Ibid. Also, at the library API level, c89 compatible code is still pretty familiar to c99 and later. > new architectures like RISC-V Shouldn't matter for portable C code? > the increasing amount of cores and a slowdown in the increase of per-core speed, Iirc parallelism was already a focus of th…
No matter how smart you are, you cannot forecast the future. Now many CPUs have a heterogeneous configuration, which means they have big cores and little cores. But do all the cores have the same capabilities? Is possible that a CPU instruction only available on some of the CPU cores? What does it mean for a multithreaded application? Would it be possible that 64-bit CPUs may drop the support for 32-bit at hardware level? Tens years ago you cannot predict what's going to happen today.
Windows has a large compatibility layer, which allows you running old code on the latest hardware and latest Windows. It needs quite a lot efforts. Many applications would crash without the compatibility patches.
One have question on this is, if the backdoor would not been discovered due to performance issue (which was as I understood it purely an oversight/fixable deficiency in the code), what are the chances of discovering this backdoor later, or are there tools that would have picked it up? Those questions are IMO relevant to understand if this kind of backdoor is the first one of the kind, or the first one that was uncove…
At least for some comic relief I'd like to imagine Jia's boss slapping him and saying something like "you idiot, we worked on this for so many years and you couldn't have checked for any perf issues?" But seriously, we could have found ourselves with this in all stable repos: RHEL, Debian, Ubuntu, IoT devices 5 years from now and it would have been a much larger shit show.
Where is the law enforcement angle on this? This individual/organization needs to be on the top of every country's most wanted lists.
[flagged]
One have question on this is, if the backdoor would not been discovered due to performance issue (which was as I understood it purely an oversight/fixable deficiency in the code), what are the chances of discovering this backdoor later, or are there tools that would have picked it up? Those questions are IMO relevant to understand if this kind of backdoor is the first one of the kind, or the first one that was uncove…
I expect a lot of people will be doing a whole lot of thinking along these lines over the next months. Code review? Some kind of behavioral analysis? IMO the call to system() was kind of sloppy, and a binary capabilities scanner could have potentially identified a path to that.
Games and proprietary software will sometimes ship with DRM protection layers that do insane things in the name of obfuscation, making it hard to distinguish from malware.
But (with only a couple exceptions) there's no reason for a binary or library in a Debian package to ever try to write the PLT outside of the normal mechanism, to try to overwrite symbols in other modules, to add LD audit hooks on startup, to try to resolve things manually by walking ELF structures, to do anti-debug tricks, or just to have any kind of obfuscation or packing that free software packaged for a distro is not supposed to have.
Some of these may be (much) more difficult to detect than others, some might not be realistic. But there are several plausible different ways a scanner could have detected something weird going on in memory during ssh startup.
No one wants a Linux antivirus. But I think everyone would benefit from throwing all the behavioral analysis we can come up with at new Debian package uploads. We're very lucky someone noticed this one, we may not have the same luck next time.
Earlier quoted context omitted.
> However, since this is an RCE in the context of e.g. an sshd process itself, this means that sshd running as root would allow the payload to itself run as root. With the right sandboxing techniques, SELinux and mitigations could prevent the attacker from doing anything with root permissions. However, applying a sandbox to an SSH daemon effectively is very difficult.
Another reason to adopt OpenBSD style pledge/unveil in Linux.
The pledge/unvail system is pretty great, but my understanding is that it do not do anything that the linux equivalent interfaces(seccomp i think) cannot do. It is just a simplified/saner interface to the same problem of "how can a program notify the kernel what it's scope is?" The main advantage to pledge/unveil bring to the table is that they are easy to use and cannot be turned off, optional security isn't.
