Directory traversal in `ar`
cherepan at mccme.ru
Sun Dec 28 20:00:48 UTC 2014
On 2014-12-28 14:54, Mark Wielaard wrote:
> On Sun, Dec 28, 2014 at 02:46:15AM +0300, Alexander Cherepanov wrote:
>> There is a directory traversal in `ar`:
>> # printf '!<arch>\n%-48s%-10s`\n//file/\n%-48s%-10s`\n' // 8 /1 0 > test.a
>> # ar -xv test.a
>> x - /file
>> Patch attached.
> Thanks, but I think we need a bit more background.
Yes, sorry, I was excessively terse.
> Unfortunately the ar archive format and long names format are not very
> well documented. And there seem to be various different formats.
Sorry, I did not look into this, I only looked at what elfutils implements.
> What our implementation follows is what I believe is the sysv format,
> which terminates long names with a '/' and LF. So the current
> implementation searches for a '/' and then creates a terminated (NUL)
> string, and skips the LF (we don't actually check there is a LF).
Right, and this missing check is the problem.
> You do terminate the string at a '/' but then start searching for the
> next long name at the LF (which in your example isn't there).
More precisely: start searching for the end of the next line name. As
the start of a long name is determined by an offset stored in a header,
not by our manipulations with '/', LF and NUL.
Roughly speaking, you can check for LF or you can check for non-'/'.
Either way is fine. But you cannot just skip it without checking.
> So if I understand correctly we would still not support directories
> in ar files. But maybe that is not the point of your patch?
Yes, it was not my intention to add a missing feature, only to fix a vuln.
> Is your example something that is actually produced by another ar
> implementation? Or is it an example of a bad long file name that
> we don't handle properly?
Yes, this is a constructed example of a malicious file. An attempt to
extract the contents of the archive will lead to creation of a file in
the root directory. It's usually agreed that unpackers and similar tools
should not by default touch files outside the working directory. The
danger is in overwriting sensitive files by an unconscious user or by an
For similar examples please see
And I recently reported the same problem in binutils:
In case of elfutils the danger is mitigated by the fact that AFAICT only
one '/' is possible in a filename and only in the leading position.
Hence only files in the root directory can be written with this attack
and only when ar is executed by root.
> BTW. For patches we require people to follow the guidelines in the
> CONTRIBUTING file (in particular we require a Signed-off-by line):
Sorry, a better patch attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1856 bytes
Desc: not available
More information about the elfutils-devel