Libarchive crash with malformed cpio archive

[kwrobot]

Original issue 394 created by Google Code user pariszoump on 2015-01-29T12:38:04.000Z:

== Affected software ==

bsdtar

== Version ==

All tests were performed using commit
296efb3db188fa4bf7b0e7b5c61d404f9145f0ab

== OS ==

Linux x86_64 (Ubuntu 14.04). 32-bit builds tested were not affected

== Description ==

Initial fuzzing was performed using the afl-fuzzer.

Using a crafted tar file bsdtar can perform an out-of-bounds memory read which will lead to a SEGFAULT. The issue exists when the executable skips data in the archive. The amount of data to skip is defined in byte offset [16-19] If ASLR is disabled, the issue can lead to an infinite loop.


== Stack trace ==

#0  __memcpy_sse2_unaligned ()
    at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:33
#1  0x0000000000416d96 in __archive_read_filter_ahead (filter=0x6e8ed0, 
    min=0x1a, avail=0x0) at libarchive/archive_read.c:1448
#2  0x000000000041679e in __archive_read_ahead (a=0x6cc710, min=0x1a, 
    avail=0x0) at libarchive/archive_read.c:1285
#3  0x000000000042c85f in header_bin_be (a=0x6cc710, cpio=0x6cd5d0, 
    entry=0x6cd100, namelength=0x7fffffffdf88, name_pad=0x7fffffffdf80)
    at libarchive/archive_read_support_format_cpio.c:904
#4  0x000000000042b3c2 in archive_read_format_cpio_read_header (a=0x6cc710, 
    entry=0x6cd100) at libarchive/archive_read_support_format_cpio.c:377
#5  0x0000000000415510 in _archive_read_next_header2 (_a=0x6cc710, 
    entry=0x6cd100) at libarchive/archive_read.c:643
#6  0x000000000041560c in _archive_read_next_header (_a=0x6cc710, 
    entryp=0x7fffffffe078) at libarchive/archive_read.c:683
#7  0x0000000000457b56 in archive_read_next_header (a=0x6cc710, 
    entry=0x7fffffffe078) at libarchive/archive_virtual.c:148
#8  0x0000000000406ab9 in read_archive (bsdtar=0x7fffffffe1d0, mode=0x78, 
    writer=0x6cb210) at tar/read.c:252
#9  0x0000000000406496 in tar_mode_x (bsdtar=0x7fffffffe1d0) at tar/read.c:104
#10 0x000000000040525e in main (argc=0x3, argv=0x7fffffffe428)
    at tar/bsdtar.c:805
#11 0x00007ffff72bab45 in __libc_start_main ()
   from /lib/x86_64-linux-gnu/libc.so.6
#12 0x0000000000403cc9 in _start ()

== Proof of Concept ==

Attached file will segfault due to an out-of-bounds memory read. If ASLR is disabled an infinite loop will be triggered.

See attachment: crash_dos.tar

[kwrobot]

Comment #1 originally posted by kientzle on 2015-02-02T00:28:24.000Z:

Thank you so much for reporting this!  I appreciate your bringing it to our attention.

The issue turned out to be a problem with the cpio reader:  Libarchive
identifies the file you constructed as a big-endian binary cpio format
with a very large (>2GB) size.  An overflow in parsing the size field caused
libarchive to treat this size as a negative value and lead to an attempt to
skip the file position forward by a negative number of bytes.

This was not found by libarchive's existing fuzz tester because that test
did not exercise the archive_read_data_skip() function.  The fuzz tester
also did not thoroughly test small input files.

I believe this is completely addressed by the commits I just made and would
appreciate you re-testing with commit e6c9668f3202215ddb71617b41c19b6f05acf008.

These fixes should entirely resolve this issue.  In particular, I made the following four changes:
  * Added a basic test for cpio binary little-endian format (which had a similar bug)
  * Extended libarchive's fuzz test so that it now detects the issue you found, and the same issue with little-endian files
  * Fixed the size overflow problem for both binary big-endian and binary little-endian formats
  * Put in an additional check to protect against moving the file pointer forward by a negative amount.

I've re-run libarchive's improved fuzz test and it finds no similar problems in other formats; if you find any other problems of this sort, please let us know right away.

[kwrobot]

Comment #2 originally posted by Google Code user pariszoump on 2015-02-02T08:44:14.000Z:

I can confirm that the latest commit fixes the issue.

I will probably continue fuzzing bsdtar and the other tools of libarchive and will come back if any other problems arise.