3 ms·

> The first difference is that the script makes sure (very sure!) to exit if not being run on Linux. The repeated check is indeed mysterious. My only hypothesi

> The first difference is that the script makes sure (very sure!) to exit if not being run on Linux. The repeated check is indeed mysterious. My only hypothesis is that the attacker may have thought that it should look plausible as a test input to a compression library, hence repetition.

TheBlight 3y ago
Is it though? The attacker probably has Linux x86 target(s) in mind and IFUNC support isn't guaranteed to work with other platforms.
- sanxiyn 3y ago
  Checking for Linux makes sense. Doing the exact same check for Linux five times in a row is mysterious.
  - tamimio 3y ago
    It would be an interesting plot twist if the whole thing was an AI hallucination.
    - neffy 3y ago
      ...or a stalking horse by somebody in Microsoft's marketing division.
    - ddalex 3y ago
      How about an AI trying to make itself some spare CPU cycles available ?
  - dboreham 3y ago
    Perhaps expected a very fast machine that might blast straight through the first few checks. Like how you needed two STOP statements in a Cray Fortran program in case it blew through the first one at 80MIPS.
- ycombinatrix 3y ago
  why doesn't IFUNC work on Linux ARM64?
  - bodyfour 3y ago
    IFUNC is supported on several architectures, including ARM64. The malicious code that the xz backdoor inserts into the library is a compiled x86_64 object file so it only is targeting one platform.
    - ycombinatrix 3y ago
      yea i know the backdoor is AMD64 only. the parent comment said IFUNC isn't supported on ARM64 which is incorrect.
mercurialuser 3y ago
It can be to make space for script changes: you may overwrite the first bytes of the script. Or just add some laziness.
fsniper 3y ago
Can it be to enlarge/or obfuscate parts of the compressed test file? Perhaps without the repetitions the compressed file has some strange binary triggering some security or antivirus software?
codezero 3y ago
[flagged]
- ycombinatrix 3y ago
  anyone know any examples of malware which have affected uname results?
  - codezero 3y ago
    ChatGPT could not provide any, fwiw, but it's an enticing idea.
    - Intralexical 3y ago
      Maybe a machine designed specifically to produce "enticing" and "very plausible"-seeming ideas with no basis in reality is a bad idea. [1] The mention to other "malware" is spurious. This was a highly engineered/targeted attack. Mentioning "malware" just sounds plausible because your brain files the word in the same region as "RCE". Running `strace` shows `/usr/bin/uname` just calls `uname()`, which just reads out some string literals in the kernel. It is unlikely to be randomized accidentally. And deliberately signalling the presence of other hacks by making the `uname` syscall non-deterministic would be highly inefficient (Return 8 strings just for one bit of data?), highly unreliable (Check how many times to be sure?), highly visible (Human-readable, and human-targeted.), and unnecessarily difficult (Kernel-level hack?). …And now you see how much effort it takes, to even start to examine/debunk an implausible and unfounded idea that cost you seconds to prompt and OpenAI fractions of pennies to generate, which took root and seemed "plausible" and "enticing" specifically because GPT was trained in an adversarial way to exploit how us humans can fall for bullshit if it's packaged in the right way… --- 1: The word for that is "Lying". ChatGPT is a Lying Machine. Sometimes the lies line up with parts of reality, but that's more luck than intent. And it's usually still lying even in those cases, just in smaller, subtler, or less blatant ways.
      - codezero 3y ago
        You can call it what you like but I’ve had plenty of hypothetical conversations with people and we never accused each other of lying. I think you are assuming that I treat GPT like an oracle rather than as a sci-fi author tripping on acid. I’m not going to submit a paper to a scientific journal treating the information as a fact but this is a public discussion forum on the Internet, so I’m happy to speculate in the open using the hallucinations of an algorithm if they seem interesting.
m3kw9 3y ago
Maybe if run on non Linux it could be found out either by crashing or leaving some trace because of OS differences
Hakkin 3y ago
I also thought it was odd. There's also different random bytes (not random text, actual random bytes) prefixed to the start the scripts, but the bytes are prefixed by a hash symbol, which comments them out, so they don't affect the script. It seems intentional, but I can't think of why they would be there. I thought maybe xz would skip compression if the input was short/not complex enough or something, so they were added to pad the size, but removing them and re-compressing with xz seems to properly compress it, none of the original plaintext is in the compressed archive bytes. One thing I noticed while trying to reproduce the exact bytes included in the .xz file committed to git is that the script's xz stream doesn't seem to be compressed by any of the default xz presets, I was only able to reproduce it by using `xz --lzma2=dict=65536 -c stream_2`. All the default numbered presents chose a different dictionary size. Another odd seemingly intentional choice, but again I don't understand the reasoning.
- Hakkin 3y ago
  Ah, I think I understand the random bytes at the start of the script now. They're prepended to make the partial output of the "corrupted" (pre-tr'd) test stream look like random data. Without those random bytes, you will see part of the start of the script if you observe the partially decompressed output before xz throws an error. They really thought quite carefully about hiding this well. Still not sure about the repeated lines, though now I'm convinced there must be some reason for it.

TheBlight 3y ago

Is it though? The attacker probably has Linux x86 target(s) in mind and IFUNC support isn't guaranteed to work with other platforms.

sanxiyn 3y ago
Checking for Linux makes sense. Doing the exact same check for Linux five times in a row is mysterious.
- tamimio 3y ago
  It would be an interesting plot twist if the whole thing was an AI hallucination.
  - neffy 3y ago
    ...or a stalking horse by somebody in Microsoft's marketing division.
  - ddalex 3y ago
    How about an AI trying to make itself some spare CPU cycles available ?
- dboreham 3y ago
  Perhaps expected a very fast machine that might blast straight through the first few checks. Like how you needed two STOP statements in a Cray Fortran program in case it blew through the first one at 80MIPS.
ycombinatrix 3y ago
why doesn't IFUNC work on Linux ARM64?
- bodyfour 3y ago
  IFUNC is supported on several architectures, including ARM64. The malicious code that the xz backdoor inserts into the library is a compiled x86_64 object file so it only is targeting one platform.
  - ycombinatrix 3y ago
    yea i know the backdoor is AMD64 only. the parent comment said IFUNC isn't supported on ARM64 which is incorrect.

mercurialuser 3y ago

It can be to make space for script changes: you may overwrite the first bytes of the script. Or just add some laziness.

fsniper 3y ago

Can it be to enlarge/or obfuscate parts of the compressed test file? Perhaps without the repetitions the compressed file has some strange binary triggering some security or antivirus software?

codezero 3y ago

[flagged]

ycombinatrix 3y ago
anyone know any examples of malware which have affected uname results?
- codezero 3y ago
  ChatGPT could not provide any, fwiw, but it's an enticing idea.
  - Intralexical 3y ago
    Maybe a machine designed specifically to produce "enticing" and "very plausible"-seeming ideas with no basis in reality is a bad idea. [1] The mention to other "malware" is spurious. This was a highly engineered/targeted attack. Mentioning "malware" just sounds plausible because your brain files the word in the same region as "RCE". Running `strace` shows `/usr/bin/uname` just calls `uname()`, which just reads out some string literals in the kernel. It is unlikely to be randomized accidentally. And deliberately signalling the presence of other hacks by making the `uname` syscall non-deterministic would be highly inefficient (Return 8 strings just for one bit of data?), highly unreliable (Check how many times to be sure?), highly visible (Human-readable, and human-targeted.), and unnecessarily difficult (Kernel-level hack?). …And now you see how much effort it takes, to even start to examine/debunk an implausible and unfounded idea that cost you seconds to prompt and OpenAI fractions of pennies to generate, which took root and seemed "plausible" and "enticing" specifically because GPT was trained in an adversarial way to exploit how us humans can fall for bullshit if it's packaged in the right way… --- 1: The word for that is "Lying". ChatGPT is a Lying Machine. Sometimes the lies line up with parts of reality, but that's more luck than intent. And it's usually still lying even in those cases, just in smaller, subtler, or less blatant ways.
    - codezero 3y ago
      You can call it what you like but I’ve had plenty of hypothetical conversations with people and we never accused each other of lying. I think you are assuming that I treat GPT like an oracle rather than as a sci-fi author tripping on acid. I’m not going to submit a paper to a scientific journal treating the information as a fact but this is a public discussion forum on the Internet, so I’m happy to speculate in the open using the hallucinations of an algorithm if they seem interesting.

m3kw9 3y ago

Maybe if run on non Linux it could be found out either by crashing or leaving some trace because of OS differences

Hakkin 3y ago

I also thought it was odd. There's also different random bytes (not random text, actual random bytes) prefixed to the start the scripts, but the bytes are prefixed by a hash symbol, which comments them out, so they don't affect the script. It seems intentional, but I can't think of why they would be there. I thought maybe xz would skip compression if the input was short/not complex enough or something, so they were added to pad the size, but removing them and re-compressing with xz seems to properly compress it, none of the original plaintext is in the compressed archive bytes. One thing I noticed while trying to reproduce the exact bytes included in the .xz file committed to git is that the script's xz stream doesn't seem to be compressed by any of the default xz presets, I was only able to reproduce it by using `xz --lzma2=dict=65536 -c stream_2`. All the default numbered presents chose a different dictionary size. Another odd seemingly intentional choice, but again I don't understand the reasoning.

Hakkin 3y ago
Ah, I think I understand the random bytes at the start of the script now. They're prepended to make the partial output of the "corrupted" (pre-tr'd) test stream look like random data. Without those random bytes, you will see part of the start of the script if you observe the partially decompressed output before xz throws an error. They really thought quite carefully about hiding this well. Still not sure about the repeated lines, though now I'm convinced there must be some reason for it.