That seems to be fine. safe_fprintf() takes care of non-printable characters. It's used for archive_entry_pathname, which can contain them, while "unsafe" fprintf is used to print out archive_error_string, which is a library-provided error string, and strerror(errno) from libc.

We know there's long-cons in action here, though. This PR needn't be the exploit. It needn't be anywhere _temporally_ close to the exploit. It could just be laying groundwork for later pull requests by potentially different accounts.

Exactly. If we assume the backdoor via liblzma as a template, this could be a ploy to hook/detour both fprintf and strerror in a similar way. Get it to diffuse into systems that rely on libarchive in their package managers.

When the trap is in place deploy a crafted package file that appears invalid on the surface level triggers this trap. In that moment fetch the payload from the (already opened) archive file descriptor, execute it, but also patch the internal state of libarchive so that it will process the rest of the archive file as if nothing happened, and the desired outcome also appearing in the system.

Assuming there isn't another commit somewhere modifying a library-provided error string or anything returned by libc. There is all kinds of mischief to be had there, which may or may not have already happened, e.g. now you do some i18n and introduce Unicode shenanigans.

If libarchive is also backdoored, would that allow specifically crafted http gzip encoded responses to do bad things?

No. There's no good reason HTTP response decoding would ever be implemented in terms of libarchive; using libz directly is simpler and supports some use cases (like streaming reads) which libarchive doesn't.

What software is using libarchive to decode HTTP responses?

Well for one, the Powershell script I just wrote to build all the 3rd-party library dependencies for a video game.

tar.exe was added to Windows this January, sourced from libarchive: https://learn.microsoft.com/en-us/virtualization/community/t...

Unlike the GNU tar I'm used to, it's actually a "full fat" command line archiving tool, compressing & decompressing zip, xz, bz2 on the command-line - really handy :-O

FreeBSD's archive tools are built on top of libarchive IIRC. Not sure about the other BSDs.

I don't know, way outside my domain. Possibly none I guess?

EDIT: Ahh, I was wrong and missed the addition of "strerror"

The PR is pretty devious.

JiaT75 claims is "Added the error text when printing out warning and errors in bsdtar when untaring. Previously, there were cryptic error messages" and cites this as fixing a previous issue.

https://github.com/libarchive/libarchive/pull/1609

However it doesn't actually do that!

The PR literally removes a new line between 2 arguments on the first `safe_fprintf()` call, and converts the `safe_fprintf()` to unsafe direct calls to `fprintf()`. In all cases, the arguments to these functions are exactly the same! So it doesn't actually make the error messages any different, it doesn't actually solve the issue it references. And the maintainer accepted it with no comments!

reread it...

It does remove the safe prefixes... But it also adds one print statement to "strerror()", which could plausibly give better explanations for the error code...

The only suspicious thing here is the lack for safe_ prefix (and the potential for the strerror() function to already be backdoored elsewhere in another commit)

But I see the "strerror" call is added