Tim Kientzle [Sun, 4 Sep 2016 23:08:26 +0000 (16:08 -0700)]
Test for PR#777: verify ACL reading during directory walks
This verifies the issue mentioned in Pull Request #777:
When using archive_read_disk to read a directory tree,
libarchive would attempt to read ACLs with the wrong
directory.
Tim Kientzle [Mon, 22 Aug 2016 00:11:45 +0000 (17:11 -0700)]
Issue #744 (part of Issue #743): Enforce sandbox with very long pathnames
Because check_symlinks is handled separately from the deep-directory
support, very long pathnames cause problems. Previously, the code
ignored most failures to lstat() a path component. In particular,
this led to check_symlinks always passing for very long paths, which
in turn provides a way to evade the symlink checks in the sandboxing
code.
We now fail on unrecognized lstat() failures, which plugs this
hole at the cost of disabling deep directory support when the
user requests sandboxing.
TODO: This probably cannot be completely fixed without
entirely reimplementing the deep directory support to
integrate the symlink checks. I want to reimplement the
deep directory hanlding someday anyway; openat() and
related system calls now provide a much cleaner way to
handle deep directories than the chdir approach used by this
code.
Tim Kientzle [Mon, 22 Aug 2016 00:01:54 +0000 (17:01 -0700)]
Issue #748: Zip decompression failure with highly-compressed data
Previously, we stopped driving the decompressor as soon as
we hit end of input, but in some cases, the decompressor
has internal state that can continue generating output
even when there is no more input. So we now feed zero-length
blocks into the decompressor until the decompressor tells us
it is finished.
Tim Kientzle [Sun, 21 Aug 2016 17:51:43 +0000 (10:51 -0700)]
Issue #767: Buffer overflow printing a filename
The safe_fprintf function attempts to ensure clean output for an
arbitrary sequence of bytes by doing a trial conversion of the
multibyte characters to wide characters -- if the resulting wide
character is printable then we pass through the corresponding bytes
unaltered, otherwise, we convert them to C-style ASCII escapes.
The stack trace in Issue #767 suggest that the 20-byte buffer
was getting overflowed trying to format a non-printable multibyte
character. This should only happen if there is a valid multibyte
character of more than 5 bytes that was unprintable. (Each byte
would get expanded to a four-charcter octal-style escape of the form
"\123" resulting in >20 characters for the >5 byte multibyte character.)
I've not been able to reproduce this, but have expanded the conversion
buffer to 128 bytes on the belief that no multibyte character set
has a single character of more than 32 bytes.
Tim Kientzle [Sun, 21 Aug 2016 16:25:00 +0000 (09:25 -0700)]
Issue #770: Be more careful about extra_length
Hanno Böck pointed out that the loop here computes
extra_length - 4 without first checking for possible underflow.
In addition to fixing this, I also added a bunch of error
checks so Zip parsing will fail if any Zip extra field
is malformed. Among other things, this uncovered an
old bug that would skip a trailing extra field with
zero-sized data.
Note that we still simply ignore well-formed
extra fields that we don't understand.
Tim Kientzle [Fri, 24 Jun 2016 05:16:03 +0000 (22:16 -0700)]
FreeBSD bug 204157: If filesystem does not support birthtime, then make all birthtime comparisons succeed.
This is a bit of a hack: We should also have tests that verify
different birthtimes. When/if that happens, we'll need to add
a real system probe to determine whether birthtime is actually
supported on this particular filesystem and skip tests accordingly.
SIGRTMAX doesn't exist on all systems, so compute the largest used
signal number. Don't bother with dynamically allocating the array, just
use a static array instead. Fix ctype use.
In the past, OpenSSL was not needed by the main libarchive when the hash
functions were provided by libc, e.g. on NetBSD. With the introduction
of the de-/encryption support, this is no longer the case. As such,
explicitly check for the necessary EVP routines as well to make sure
that -lcrypto is added as necessary.
Tim Kientzle [Sun, 19 Jun 2016 22:58:33 +0000 (15:58 -0700)]
Issue 719: Refuse to allocate a too-small PPMD7 context
Other parts of the PPMD7 code assume that the dictionary is
at least UNIT_SIZE (12 bytes). Enforce that assumption here
to avoid potential buffer under- and over-runs.
This was pointed out in a review of the original fix for Issue 719.
Tim Kientzle [Sun, 19 Jun 2016 21:34:37 +0000 (14:34 -0700)]
Issue 717: Fix integer overflow when computing location of volume descriptor
The multiplication here defaulted to 'int' but calculations
of file positions should always use int64_t. A simple cast
suffices to fix this since the base location is always 32 bits
for ISO, so multiplying by the sector size will never overflow
a 64-bit integer.
Tim Kientzle [Sun, 19 Jun 2016 21:21:42 +0000 (14:21 -0700)]
Issue 719: Fix for TALOS-CAN-154
A RAR file with an invalid zero dictionary size was not being
rejected, leading to a zero-sized allocation for the dictionary
storage which was then overwritten during the dictionary initialization.
Thanks to the Open Source and Threat Intelligence project at Cisco for
reporting this.
Tim Kientzle [Sun, 19 Jun 2016 21:14:09 +0000 (14:14 -0700)]
Issue #718: Fix TALOS-CAN-152
If a 7-Zip archive declares a rediculously large number of substreams,
it can overflow an internal counter, leading a subsequent memory
allocation to be too small for the substream data.
Thanks to the Open Source and Threat Intelligence project at Cisco
for reporting this issue.
Tim Kientzle [Thu, 16 Jun 2016 01:38:30 +0000 (18:38 -0700)]
Issue 553: Fix broken decryption for ZIP files.
Sometimes, decompressing was failing due to miscalculation of buffer
offsets, and hence causing a silent buffer overflow.
When a previous chunk decompression left some bytes in the decryption
buffer, it was not taken into account in determining space left in the
decompression buffer.
So, it could happen, that the decryption buffer is completely full,
but some bytes are not used yet. In such case, even though the buffer
is full, the code tried to decrypt more bytes behind it's boundary.
This CL resolves this issue by properly calculating the amount of
space left in the decompression buffer.
(This is an edited version of Tomasz Mikolajewski's pull request.)
Graham Percival [Mon, 13 Jun 2016 23:13:06 +0000 (16:13 -0700)]
Remove dead code in archive_entry_xattr_add_entry()
The code seems to be walking through the linked list beginning at
entry->xattr_head, but then it immediately sets xp to be something different.
This is 10-year old code; it was added in the first "POSIX.1e-style Extended
Attribute support" commit, on March 21 2006:
https://svnweb.freebsd.org/base/head/lib/libarchive/archive_entry.c?annotate=156961&pathrev=156961#l1387
Maxin B. John [Fri, 3 Jun 2016 11:09:30 +0000 (14:09 +0300)]
Makefile.am: Remove non-existing file
Fixes this build error:
CC libarchive/archive_write_set_format_gnutar.lo
make[1]: *** No rule to make target
'libarchive/archive_write_set_format_gnutar_filenames.c', needed by
'libarchive/archive_write_set_format_gnutar_filenames.lo'. Stop.
make[1]: Leaving directory '/home/maxin/clone/libarchive'
Makefile:2866: recipe for target 'all' failed
make: *** [all] Error 2
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Tim Kientzle [Wed, 1 Jun 2016 04:01:59 +0000 (21:01 -0700)]
Issue 682: Correctly write gnutar filenames of exactly 512 bytes
Previous code omitted the final zero byte for filenames and
linknames. This is usually okay since the final block is
padded with zero bytes, but if the filename exactly filled
the block, there would be no zero byte.
Tim Kientzle [Sat, 28 May 2016 18:50:39 +0000 (11:50 -0700)]
Issue 711: Be more careful about verifying filename lengths when writing ISO9660 archives
* Don't cast size_t to int, since this can lead to overflow
on machines where sizeof(int) < sizeof(size_t)
* Check a + b > limit by writing it as
a > limit || b > limit || a + b > limit
to avoid problems when a + b wraps around.