11–20 of 482 posts
I have found JiaT75 - Jia Tan mentioned in Microsoft C++, C, and Assembler as an community contributor ... https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp... Also check this... https://www.abuseipdb.com/check/64.23.252.16
I have found JiaT75 - Jia Tan mentioned in Microsoft C++, C, and Assembler as an community contributor ... https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp... Also check this... https://www.abuseipdb.com/check/64.23.252.16
So all binaries built with a Microsoft compiler must be considered compromised?
How do you get "Jigar Kumar"'s email address? I can't seem to find it in the (web version of) the maillist. Another question: What is the typo exactly in this commit? I can't seem to find it. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=a100f9111c8...
How do you get "Jigar Kumar"'s email address? I can't seem to find it in the (web version of) the maillist. Another question: What is the typo exactly in this commit? I can't seem to find it. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=a100f9111c8...
What stands out to me is this particular justification: > 2024-02-23: Jia Tan merges hidden backdoor binary code well hidden inside some binary test input files. The associated README claims “This directory contains bunch of files to test handling of .xz, .lzma (LZMA_Alone), and .lz (lzip) files in decoder implementations. Many of the files have been created by hand with a hex editor, thus there is no better "source…
It sort of makes sense, since at the end of the day it could just be statically linked or implement B's behaviour itself and do whatever it wants, but it's not really what you expect is it.
So much for the folks advocating for binary (driver) blobs in OSS t support otherwise unsupported hardware.
It's either in source form and reproducable or it's not there.
I think this analysis is more interesting if you consider these two events in particular: 2024-02-29: On GitHub, @teknoraver sends pull request to stop linking liblzma into libsystemd.[1] (not in the article) 2024-03-20: The attacker is now a co-contributor for a patchset proposed to the Linux kernel, with the patchset adding the attacker as a maintainer and mirroring the attacker's activity with gaining the trust ov…
I don't understand how this could have worked. If you compile and build your own image, would that be able to trigger the backdoor? You can of course change an existing image to something that triggers the backdoor, but with that level of access you won't really need a backdoor, do you?
1. A new "test" is added to the xz-utils repository, and when xz is being built by a distribution such as Debian, the backdoor from the "test" is included into the xz binary.
2. The backdoored xz is distributed widely, including to a target vendor who wishes to from a Debian development environment compile a kernel for an embedded device that is usually used in a specific industry and/or set of countries.
3. When backdoored xz is then asked to compress a file, it checks whether the file is a kernel image and checks whether the kernel image is for the intended target (e.g. includes specific set of drivers).
4. If the backdoored xz has found its target kernel image, search for and modify random number generation code to effectively make it deterministic. Or add a new module which listens on PF_CAN interfaces for a particular trigger and then sends malicious CAN messages over that interface. Or modify dm_crypt to overwrite the first 80% of any key with a hardcoded value. Plenty of nasty ideas are possible.
> merges hidden backdoor binary code well hidden inside some binary test input files. [...] Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves. So much for the folks advocating for binary (driver) blobs in OSS t support otherwise unsupported hardware. It's either in source form and reproducable or it's not there.