>patient three year infiltration and planning period
>threat actor crafted a meticulous fake identity, there's even a Jia Tan on LinkedIn
>obfuscated, sofisticated backdoor
>threat actor faked his timezone and was careful not to dox himself at any point (Only time they caught his IP, it was to a Singapore VPN)
>good at social engineering as well
>almost managed to get his backdoor onto every Debian, OpenSUSE and RedHat PC out there, we are talking about millions of compromised computers, billions in potential revenue
>discovered almost by accident, because some guy got curious that his SSH was slower by 0.5 seconds
>Jia Tan's edits spanned numerous important repos: XZ, liblzma, oss-fuzz, libarchive... introducing minor undetectable vulnerabilities here and there, nobody suspected any wrongdoing
Three conclusions:
1. This looks like a sofisticated attack by a State actor.
2. Got detected by chance, there's a high chance there have been other attacks like these that haven't been detected.
3. Needless complexity is a major threat to open source transparency.
 UFOs Are A Psyop Shirt $21.68 |
 |
UFOs Are A Psyop Shirt $21.68 |
If it was so sophisticated, it wouldn't have added a detectable delay.
The real sophisticated malware is out there right now, infecting windows, mac, and linux, and it's written by some isreali guy working for some ""cybersecurity"" company
>almost managed to get his backdoor onto every Debian, OpenSUSE and RedHat PC
Almost is the operative word, but even that is seriously misleading. It wouldn't have hit Debian stable, CentOS, RHEL, or SUSE Leap for at least a couple of years.
>obfuscated
Sure. What else would it be?
>sofisticated
A. ESL
B. No.
>meticulous fake identity
Any moron here could do the same. He was patient, sure, and but he certainly wasn't a genius about it.
>introducing minor undetectable vulnerabilities here and there
Source: Your anus.
>only israelites are smart enough to write good malware
Frick off Chaim.
>1. This looks like a sofisticated attack by a State actor.
Probably true, few others have this level of patience.
>2. Got detected by chance, there's a high chance there have been other attacks like these that haven't been detected.
Over on /cyb/ this was pointed out, especially another project where the maintainer is tired and is looking for someone to join in.
>3. Needless complexity is a major threat to open source transparency.
Clearly.
>If it was so sophisticated, it wouldn't have added a detectable delay.
The detectable delay came about only when running with debug settings.
>No, state actors are moronic
Perhaps. They are at least patient.
it feels amazing to be the only person who knows who jia tan is in real life
https://github.com/xz-mirror/xz
the information is here
attention is all you need
happen to also have a clone STest?
no, not even archives have it before the exploit publication
I'm sorry it was me
>This looks like a sofisticated attack by a State actor
No, state actors are moronic
>Got detected by chance
Wrong, someone investigated an anomaly very shortly after it was introduced
>Needless complexity is a major threat to open source transparency
Hard to disagree with this, but how is this a lesson in this case?
>No, state actors are moronic
While this is too smart for glowies, this plan was also moronic. You should infiltrate something relatively obscure and infested with normies, like a game console emulator. Instead, he chose libraries used by professionals who neutralized 3 years of work in 30 days.
If your goal was corporate / industrial espionage (high-value targets), it makes perfect sense to target Debian and Red Hat though, as opposed to some gaming consolte emulator.
i think if the attacker was a sophisticated person at a government level, they would have set the exploit to sleep until it made its way into stable distros.
#include <time.h>
#define twoMonthsLater ...
time_t t = time(NULL);
if(t >= twoMonthsLater) {
// exploit
}
else {
// normal operation
}
There's are rare chance of people running a server on rolling release so he had the right precaution. It was purely by chance he got caught.
Again, it wasn’t by chance. Someone noticed a problem.
the guys who do debian testing did ofc
No anon it’s like this
>burglar breaks into home
>homeowner tells him to get the frick out or be shot
>caught purely by remote chance that someone would be home and not tolerate burglary
idk man 500 ms delay is insane regardless
there's a rare chance someone will use cooking oil as sunscreen
Ideally, perhaps, but it would have been more difficult to hide that code in the plain source that he obfuscated the code that loaded and ran the script.
And if it were in the script there would still have been a performance penalty.
he didn't have problems with hiding a public key in that code
>there would still have been a performance penalty
1 million if(time(NULL) > c) calls take 2.8 milliseconds on my shitbox
He hid a public key in a binary file test file that he was like "lol don't worry about it" for the contents.
Which needed the script to be loaded.
the test files also contain the backdoor code.
if he had added
if(time(NULL) < t) return;
to the first line, it could stay unnoticed until its in stable distros.
>Needless complexity is a major threat to open source transparency.
OHNONONO systemdsisters, how do we respond to this?
The actual problem in our end times is the Antichrist
Thank you for the breakdown, Joe Rogan.
https://en.wikipedia.org/wiki/Tian_Ji
chinese attack.
>introducing minor undetectable vulnerabilities here and there
Is this confirmed?
yes, in one commit he broke code testing for sandboxing feature by placing a . in a way that usually gets missed in the long diffs
Yes, all of his commits are under close review though, most being reversed out of caution.
Check out for example, how he replaced a safe_fprint function with an unsafe fprint here, under the excuse of "fixing an error message":
https://github.com/libarchive/libarchive/pull/1609
How he disabled this oss-fuzz function:
https://github.com/google/oss-fuzz/pull/10667
This suspicious llvm change:
https://github.com/llvm/llvm-project/issues/63957
Or how he disabled the landlock sandbox function with one sneaky dot.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7
Most of these changes went unnoticed for months if not years.
imagine how bad it is at microsoft, full of chinese spies "acfidentially" breaking security all of the time
Everything propietary can be assumed to be compromised by one actor or another. That's why they are going after Open Source now.
All modern x86 hardware is compromised.
Thanks. Only the libarchive thing seems unrelated to xh, and for that one I'm actually unclear on how it would be exploitable—the only difference between safe_fprintf and fprintf seems to be how they handle nonprintable characters. So it could mislead somebody reading terminal output but you can't get arbitrary code execution that way or anything.
I still dunno that they inserted other vulnerabilities besides the big one, no smoking gun here.
>How he disabled this oss-fuzz function:
This is testing infrastructure for xz itself.
>This suspicious llvm change:
This isn't a change at all, it's a bug report. And I think it's actually a valid one, though they only filed it because clang was accidentally drawing attention to an obscure feature that the exploit used.
>safe_fprint function with an unsafe fprint here
stop spreading FUD. there's nothing "unsafe" about fprint and the "safe" version has nothing to do with safety, it just filters out non printable characters which they moronicly decided to name "safe" and so no coder are looking at the name and spreading FUD for no reason.
Nice try Jia
OK, you got us.
Not that we care. We still have plenty more 0dayz up our sleeves 🙂
it was psyop from Microsoft
All that and they still failed.
>making portable build systems is unnecessary
Typical suck"""less""" user.
portage is the only good build system but noone cares besides me
Portage is not a build system at all, but everybody knows except you.
that's enough low IQ cope for today
>doesn't know the difference between a package manager and a build system
>calls anyone else low IQ
cute
absolutely and utterly incompetent. See you tomorrow at work.
holy shit, jia tan just flew over my house
it's true i was the house
this is why you should use the operating system that actually review their code
name ONE
>he thinks every commit of every package in an operating system is meticulously looked over for sophisticated backdoors
why don't they though
>People think it was the chinese.
Why would a supposed chinese state actor use a chinese sounding name. Ergo it wasn't Chinese.
>But but but
If the chinaman wanted to compromise a large chunk of code, they'd botnet one of the main popular pieces of software from companies like tencent (for example rapidjson) and use some American sounding names. They already have access to this shit, so no need to be so sneaky.
Immigrant approached by state actor to be paid to do naughty things.
It’s the Chinese way.
>china could just botnet the most popular piece of software..
Don’t tencent’s most popular western games require the installation of kernel-level anti-cheat?
What could possibly go wrong?
“PC” is misplaced since they were totally targeting the largest subset of machines running the got dam internet itself. I don’t think they were interested in people’s workstations
You wanted troonix to be popular?
You got it
wasnt it hogging CPU cycles and thus instantly detectable in htop?
yes this was a great feat but it would have been discovered quickly (which it was)
You're right, but no one around here actually reads anything
>3. Needless complexity is a major threat to open source transparency.
This. Also aesthetics.
Good blog post here:
https://nibblestew.blogspot.com/2024/04/aesthetics-matter.html
CHECKED!
>3. Needless complexity is a major threat to open source transparency.
openbsd chads rise up
captcha j8 XZ at
>there's a high chance there have been other attacks like these that haven't been detected.
It seems that every day that passes without a new one being disclosed the less likely there are others that have gotten in.
All the big Linux players are combing their packages now looking for anything suspect. And you can bet that binary blobs that they don't know exactly how they were built and what's in them would have been the first thing they looked for.
not a single unique or new thought has been posted in this thread
Why is it whenever anyone shows any level of competence they think its a state actor?
You think governments actually hire competent people?
>Long post about complexity
Its not complexity its just stallman was right. His whole trick depended on a "trust me this is just for a test" binary. We should normalize compiling a binary for a test. That way the source code for the test is in the repo. Also this is a wakeup call for everyone developing open source to move towards reproducible builds and build systems. There is too much trust for the people managing the repos. They ship binaries that no one is able to validate. If they created reproducible builds using something like guix or nix then all we would need to verify is a checksum and to compile.
The real problem is that the build process has any access to the test folder or data it contains. If you can configure and build a release binary and get a different hash depending on if you deleted the test folder first then your build process is broken, simple as
>The real problem
I think that's definitely part of the problem, but I think reproducible builds has to be the target. If we can reproduce our builds validation becomes instantly that much eaiser.
whaddap bai hou
it's ya boy jia tan
ama