4 ms·

If you think of it as a state sponsored attack it makes a lot of sense to have a "secure" vulnerability in system that your own citizens might use. It looks li

by takeda 3y ago

If you think of it as a state sponsored attack it makes a lot of sense to have a "secure" vulnerability in system that your own citizens might use. It looks like the whole contribution to xz was an effort to just inject that backdoor. For example the author created the whole test framework where he could hide the malicious payload. Before he started work on xz, he made contribution to libarchive in BSD which created a vulnerability.

pxx 3y ago
The libarchive diff didn't create any vulnerability. The fprintf calls were consistent with others in the same repository.
- takeda 3y ago
  They still preferred to revert it as it looks very suspicious. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068047 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068047 https://github.com/libarchive/libarchive/pull/2101 https://github.com/libarchive/libarchive/pull/2101
  - asveikau 3y ago
    If I read that correctly the problem is that it prints a filename that might include terminal control sequences that come from an attacker-controlled file name. Comment in your second link: https://github.com/libarchive/libarchive/pull/1609#issuecomment-2028125584 https://github.com/libarchive/libarchive/pull/1609#issuecomm...
- jhugo 3y ago
  It did, actually: the filename can contain terminal control characters, which thanks to the change from safe_fprintf to fprintf, were printed without escaping, which allows the creator of the archive being extracted to control the terminal of the user extracting the archive.
  - pxx 3y ago
    That's (a) not exploitable without the existence of a much higher-severity exploit -- sure you can clear the screen, but that's low impact (b) possible to trigger on other extant paths; see https://github.com/libarchive/libarchive/issues/2107 https://github.com/libarchive/libarchive/issues/2107 so it seems nothing new was introduced (c) kind of contrived to get to execute; you have to somehow fail to extract the archive but on the happy path you'll see a bunch of weirdly-named files I think it's distinctly higher-probability that this change was just meant to build credibility for the GitHub account. The diff is a fairly trivial patch to a minor issue filed around the same time as the pull request.
    - CommitSyn 3y ago
      Is it possible it was part of a planned or current exploit chain, some other way it could have been utilized?
      - wholinator2 3y ago
        Yes, i think one thing we should learn from this is that suspicious code is suspicious code, and anyone asserting that some suspicious code cannot be exploited is suspicious themselves. I don't think we should inquisition half the industry, but i do think people should be a lot more careful about saying that one small exploitable thing definitely cannot be part of a larger exploit. It's obvious, basically no one knows what's going on in the _vast_ majority of code running out systems these days. And even if you know 99% the attackers only need to be right once

by takeda 3y ago

pxx 3y ago

The libarchive diff didn't create any vulnerability. The fprintf calls were consistent with others in the same repository.

takeda 3y ago
They still preferred to revert it as it looks very suspicious. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068047 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068047 https://github.com/libarchive/libarchive/pull/2101 https://github.com/libarchive/libarchive/pull/2101
- asveikau 3y ago
  If I read that correctly the problem is that it prints a filename that might include terminal control sequences that come from an attacker-controlled file name. Comment in your second link: https://github.com/libarchive/libarchive/pull/1609#issuecomment-2028125584 https://github.com/libarchive/libarchive/pull/1609#issuecomm...
jhugo 3y ago
It did, actually: the filename can contain terminal control characters, which thanks to the change from safe_fprintf to fprintf, were printed without escaping, which allows the creator of the archive being extracted to control the terminal of the user extracting the archive.
- pxx 3y ago
  That's (a) not exploitable without the existence of a much higher-severity exploit -- sure you can clear the screen, but that's low impact (b) possible to trigger on other extant paths; see https://github.com/libarchive/libarchive/issues/2107 https://github.com/libarchive/libarchive/issues/2107 so it seems nothing new was introduced (c) kind of contrived to get to execute; you have to somehow fail to extract the archive but on the happy path you'll see a bunch of weirdly-named files I think it's distinctly higher-probability that this change was just meant to build credibility for the GitHub account. The diff is a fairly trivial patch to a minor issue filed around the same time as the pull request.
  - CommitSyn 3y ago
    Is it possible it was part of a planned or current exploit chain, some other way it could have been utilized?
    - wholinator2 3y ago
      Yes, i think one thing we should learn from this is that suspicious code is suspicious code, and anyone asserting that some suspicious code cannot be exploited is suspicious themselves. I don't think we should inquisition half the industry, but i do think people should be a lot more careful about saying that one small exploitable thing definitely cannot be part of a larger exploit. It's obvious, basically no one knows what's going on in the _vast_ majority of code running out systems these days. And even if you know 99% the attackers only need to be right once