3 ms·
Wouldn't the next malware use a different way to embed itself
by ape4 1y ago
Wouldn't the next malware use a different way to embed itself
- xmodem 1y agoWhy would they bother if we don't act on any of the learnings from this one?
- bluGill 1y agoMaybe - but original ideas are hard, ideas without flaws are rare: there are reasonable odds someone will try this again.
- citbl 1y agoThe next one probably won't be caught by running noticeably slower than usual. It was a pure fluke that it got discovered _this early_.
- ApolloFortyNine 1y agoIf I remember correctly it's days were numbered as soon as that redhat bug report on the valgrind errors piling up was made. They weren't the ones to find the cause first (that's the person who took a deeper look due to the slowness), but the red flags had been raised.
- paulf38 1y agoYes indeed. The backdoor author did try to claim that it was a false positive (and I’m sure that a very depressingly large number of people would happily go along with such a claim even without a scrap of evidence). The error was related to the use of the frame pointer. Optimised code does not use RBP as the frame pointer, only using RSP for stack addresses. The XZ backdoor code assumed that the stack used this layout. The RedHat regression tests use debug builds that do use the frame pointer. The result was the backdoor code writing below the bottom of the stack. I suspect also that Valgrind is unique in finding issues like this. Other tools do not check all memory accesses before main. Valgrind loads and runs the test binary from the very beginning and thus it detected errors in the ifunc code used by XZ that executed very early on during ld.so loading and symbol resolution.