Crafted tar archive can be used to remove arbitrary files

[clausecker]

This bug has been reported by me on FreeBSD as bug #207396. It is reproduced below.

The ustar file format allows to store hard links. Hard links are stored as entries with file type 1 and the linkname field set to the file to link to. In badly constructed tar implementations, a crafted tar file that attempts to link a file to itself can be used to remove files as the tar program first checks if the link-target exists, then unlinks the file name to be linked to and finally attempts to create a link to a non-existent file, which fails for obvious reasons. This attack vector has been known since at least 2003 and is part of the star test suite.

FreeBSD tar apparently doesn't contain code to catch this scenario. Instead, it happily deletes files using such crafted archives. This is a potential security problem as tar is not expected to delete files without replacement as it unpacks an archive.

Attached is the relevant test case from the star test suite

As Github does not allow me to attach the test case, please look at the FreeBSD bug report for the test case.

[jsonn]

I'm a bit puzzled what the "attack" vector as I don't see how removing a file is any more problematic as being able to overwrite it with arbitrary content. To me, this is at beast a Quality of Implementation issue and I don't really consider it a bug in first place based on Garbage In, Garbage Out.

[clausecker]

It's a security issue as tar is normally not able to remove files. They can overwrite files but not remove them. Also, “garbage in, garbage out” is not a design principle for security critical software. If the input is invalid, an error should be raised, erasing random files is not behaviour that should occur in this case.

[kientzle]

I agree that it would be nice to reject a hardlink that points to itself and it should be straightforward to add a check for that. A patch would be welcome.

[jsonn]

You can continue to claim its a security issue, but hand-waving doesn't make it true. So, what scenario can be name where extracting a malformed tarball which removes a file is worse than whatever content that tarball can create. It is hardly a random files that gets removes and the content of the file would have been junked already.

[xorgy]

@jsonn perhaps a lock file could be deleted, or a key. That would cause DoS if you're operating an otherwise poorly secured box.

I would agree that random un-tar-like behaviour is a pretty critical flaw. I wouldn't feel comfortable using libarchive with flaws like this.

I'll take a look at patching it.

[clausecker]

@xorgy Any progress with this one?

[xorgy]

@xorgy Any progress with this one?

Nope, I suggest using a mature tar implementation that has an answer for this.

[mmatuska]

Maybe look here: b3073af
Should be fixed since 3.5.0

[clausecker]

Maybe look here: b3073af
Should be fixed since 3.5.0

That looks like a fix! Closing this one.