In the latest commit master-ed51e1, there is a heap-use-after-free in read_stream function (stream.c:1756).
With ASAN cflags "-fsanitize=address", use the POC attached will trigger the vulnerability.
Command to reproduce: ./lrzip -t lrzip-uaf-read_stream.lrz
The ASAN backtrace info:
READ of size 1 at 0x60200000eef0 thread T0
#0 0x7f5752d26934 in __asan_memcpy (/usr/lib/gcc/x86_64-linux-gnu/5/libasan.so+0x8c934)
#1 0x414655 in memcpy /usr/include/x86_64-linux-gnu/bits/string3.h:53
#2 0x414655 in read_stream /opt/csn/lrzip/stream.c:1756
#3 0x40ee8c in read_vchars /opt/csn/lrzip/runzip.c:79
#4 0x40ee8c in read_header /opt/csn/lrzip/runzip.c:147
#5 0x40ee8c in runzip_chunk /opt/csn/lrzip/runzip.c:316
#6 0x40ee8c in runzip_fd /opt/csn/lrzip/runzip.c:384
#7 0x407db9 in decompress_file /opt/csn/lrzip/lrzip.c:838
#8 0x403a74 in main /opt/csn/lrzip/main.c:675
#9 0x7f57515e082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#10 0x404888 in _start (/opt/csn/lrzip/lrzip+0x404888)
0x60200000eef0 is located 0 bytes inside of 10-byte region [0x60200000eef0,0x60200000eefa)
freed by thread T0 here:
#0 0x7f5752d322ca in __interceptor_free (/usr/lib/gcc/x86_64-linux-gnu/5/libasan.so+0x982ca)
#1 0x4146d0 in fill_buffer /opt/csn/lrzip/stream.c:1573
#2 0x4146d0 in read_stream /opt/csn/lrzip/stream.c:1764
previously allocated by thread T0 here:
#0 0x7f5752d32602 in malloc (/usr/lib/gcc/x86_64-linux-gnu/5/libasan.so+0x98602)
#1 0x414937 in fill_buffer /opt/csn/lrzip/stream.c:1651
#2 0x414937 in read_stream /opt/csn/lrzip/stream.c:1764
SUMMARY: AddressSanitizer: heap-use-after-free ??:0 __asan_memcpy
Shadow bytes around the buggy address:
0x0c047fff9d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fd fd fa fa[fd]fd
0x0c047fff9de0: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
0x0c047fff9df0: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 04 fa
0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
==85575==ABORTING
when compile without ASAN flags, lrzip will crash because of double free
1564/* fill a buffer from a stream - return -1 on failure */1565staticintfill_buffer(rzip_control *control, struct stream_info *sinfo, struct stream *s, int streamno)
1566 {
1567 i64 u_len, c_len, last_head, padded_len, header_length, max_len;
1568 uchar enc_head[25 + SALT_LEN], blocksalt[SALT_LEN];
1569 stream_thread_struct *st;
1570bool new_thread = false;
1571 uchar c_type, *s_buf;
15721573dealloc(s->buf);
in the below code, the s->buf may be freed in fill_buffer, but with while the s->buf will be used again in memcpy in line 1756, and may be free again in fill_buffer in 1764. which caused heap use after free and double free.
In the latest commit master-ed51e1, there is a heap-use-after-free in read_stream function (stream.c:1756).
With ASAN cflags "-fsanitize=address", use the POC attached will trigger the vulnerability.
Command to reproduce:
./lrzip -t lrzip-uaf-read_stream.lrzThe ASAN backtrace info:
when compile without ASAN flags, lrzip will crash because of double free
s->bufwas freed infill_bufferin stream.c:1573in the below code, the
s->bufmay be freed infill_buffer, but with while the s->buf will be used again in memcpy in line 1756, and may be free again in fill_buffer in 1764. which caused heap use after free and double free.lrzip-uaf-read_stream.lrz.zip
The text was updated successfully, but these errors were encountered: