Vulnerability Report on Sharutils 4.15.2

[Salvatore Bonaccorso]

Hi

Hi,
Below are the details of the issue we found during fuzzing "unshar". 
Was trying to compile with ASAN however doesn't work at all (could be
missing something that's why not worked). However, I did this manually
verified. Attached is the fuzzed file (password: abc123).
Reading symbols from ../unshar...done.
(gdb) r 2.fuzz
Starting program: /home/john/sharutils-4.15.2/src/unshar 2.fuzz
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Segmentation fault
Program received signal SIGPIPE, Broken pipe.
0xb7fd9ce5 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fd9ce5 in __kernel_vsyscall ()
#1  0xb797bb93 in __write_nocancel () at
../sysdeps/unix/syscall-template.S:84
#2  0xb790f0b1 in _IO_new_file_write (f=0xb4103b50, data=0xb6100100,
n=4096) at fileops.c:1263
#4  0xb790f775 in _IO_new_file_xsputn (f=0xb4103b50, data=0xb6100100,
n=4096) at fileops.c:1342
#5  0xb790e01e in __GI_fwrite_unlocked (buf=0xb6100100, size=1,
count=4096, fp=0xb4103b50) at iofwrite_u.c:43
#6  0x0804c2df in unshar_file (name=0xbffff1e4 "2.fuzz",
file=0xb4903bc0) at unshar.c:396
#7  0x0804a2f5 in validate_fname (fname=0xbffff1e4 "2.fuzz") at
unshar-opts.c:604
#8  main (argc=2, argv=0xbfffefb4) at unshar-opts.c:639
Further verification of the source code, we found the issue was on the
line unshar.c:396 which is broken when performed write. Issue seems to
be more on memory corruption.

Has this issue been further looked at and is there a patch available
for the issue?

Does it need a CVE assigned?

Regards,
Salvatore

[Mohd Hanafie]

Hi,

Issue has been resolved and CVE has been assigned, CVE-2018-1000097.

Thanks!

Post by Salvatore Bonaccorso
Hi

Hi,
Below are the details of the issue we found during fuzzing "unshar".
Was trying to compile with ASAN however doesn't work at all (could be
missing something that's why not worked). However, I did this manually
verified. Attached is the fuzzed file (password: abc123).
Reading symbols from ../unshar...done.
(gdb) r 2.fuzz
Starting program: /home/john/sharutils-4.15.2/src/unshar 2.fuzz
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Segmentation fault
Program received signal SIGPIPE, Broken pipe.
0xb7fd9ce5 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fd9ce5 in __kernel_vsyscall ()
#1 0xb797bb93 in __write_nocancel () at
../sysdeps/unix/syscall-template.S:84
#2 0xb790f0b1 in _IO_new_file_write (f=0xb4103b50, data=0xb6100100,
n=4096) at fileops.c:1263
#4 0xb790f775 in _IO_new_file_xsputn (f=0xb4103b50, data=0xb6100100,
n=4096) at fileops.c:1342
#5 0xb790e01e in __GI_fwrite_unlocked (buf=0xb6100100, size=1,
count=4096, fp=0xb4103b50) at iofwrite_u.c:43
#6 0x0804c2df in unshar_file (name=0xbffff1e4 "2.fuzz",
file=0xb4903bc0) at unshar.c:396
#7 0x0804a2f5 in validate_fname (fname=0xbffff1e4 "2.fuzz") at
unshar-opts.c:604
#8 main (argc=2, argv=0xbfffefb4) at unshar-opts.c:639
Further verification of the source code, we found the issue was on the
line unshar.c:396 which is broken when performed write. Issue seems to
be more on memory corruption.

Has this issue been further looked at and is there a patch available
for the issue?
Does it need a CVE assigned?
Regards,
Salvatore

[Petr Pisar]

Post by Mohd Hanafie
Issue has been resolved and CVE has been assigned, CVE-2018-1000097.

It's still not resolved in the upstream. I.e. latest upstream 4.15.2 release
does not contain the fix.

-- Petr

[Salvatore Bonaccorso]

Hi,

Post by Mohd Hanafie
Hi,
Issue has been resolved and CVE has been assigned, CVE-2018-1000097.

This is confusing. CVE-2018-1000097 seems to be assigned specifically
for http://seclists.org/bugtraq/2018/Feb/54 which was reported as
http://lists.gnu.org/archive/html/bug-gnu-utils/2018-02/msg00004.html
. Petr Pisar proposed a fix in
https://lists.gnu.org/archive/html/bug-gnu-utils/2018-02/msg00005.html

[Salvatore Bonaccorso]

Hi!

Hi,
Apologize for the confusion. Yes I reported two different bugs here. One
has been assign with CVE the other seems no update.
Do you guys take a look into this? If yes, is there a fix will propose and
cve assign?

Thanks for confirming they are different issues.

AFAICT for this issue still no proposed fix is available for the
issues raised in
https://lists.gnu.org/archive/html/bug-gnu-utils/2018-02/msg00003.html,
nor am I aware of any requested CVE assignments.

Regards,
Salvatore

[Petr Pisar]

Post by Salvatore Bonaccorso
AFAICT for this issue still no proposed fix is available for the
issues raised in
https://lists.gnu.org/archive/html/bug-gnu-utils/2018-02/msg00003.html,

Well, I cannot reproduce it. Maybe the attachent with the reproducer is
wrong. The message reads 2.fuzz, but the attachent contains four
SIGSEGV*.fuzz files. Runnning unshar on any of them results in:

sh: line 14386: warning: here-document at line 37 delimited by end-of-file (wanted `_EOF_')
sh: line 14387: syntax error: unexpected end of file

(the line numbers differ) and valgrdind does not show any issue in the
unshar process.

-- Petr

[Salvatore Bonaccorso]

Hi Petr

Post by Petr Pisar

Post by Salvatore Bonaccorso
AFAICT for this issue still no proposed fix is available for the
issues raised in
https://lists.gnu.org/archive/html/bug-gnu-utils/2018-02/msg00003.html,

Well, I cannot reproduce it. Maybe the attachent with the reproducer is
wrong. The message reads 2.fuzz, but the attachent contains four
sh: line 14386: warning: here-document at line 37 delimited by end-of-file (wanted `_EOF_')
sh: line 14387: syntax error: unexpected end of file
(the line numbers differ) and valgrdind does not show any issue in the
unshar process.

That you were not able to reproduce let me look again at it. So I can
reproduce it on an up-to-date Debian unstable (amd64) system, with
sharutils updated up to 1:4.15.2-3. Valgrind shows:

$ valgrind unshar SIGSEGV.PC.80018413.STACK.1dab0c403.CODE.1.ADDR.0xbf7fe258.INSTR.push___%ecx.fuzz
==3784== Memcheck, a memory error detector
==3784== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3784== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==3784== Command: unshar SIGSEGV.PC.80018413.STACK.1dab0c403.CODE.1.ADDR.0xbf7fe258.INSTR.push___%ecx.fuzz
==3784==
SIGSEGV.PC.80018413.STACK.1dab0c403.CODE.1.ADDR.0xbf7fe258.INSTR.push___%ecx.fuzz:
Segmentation fault
==3784==
==3784== Process terminating with default action of signal 13 (SIGPIPE)
==3784== at 0x4F21134: write (write.c:27)
==3784== by 0x4EB24BC: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1203)
==3784== by 0x4EB17DE: new_do_write (fileops.c:457)
==3784== by 0x4EB3648: _IO_do_write@@GLIBC_2.2.5 (fileops.c:433)
==3784== by 0x4EB2B7E: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1266)
==3784== by 0x4EB13BF: fwrite_unlocked (iofwrite_u.c:43)
==3784== by 0x10C3E6: unshar_file (unshar.c:396)
==3784== by 0x10BC4E: validate_fname (unshar-opts.c:604)
==3784== by 0x10BC4E: main (unshar-opts.c:639)
==3784==
==3784== HEAP SUMMARY:
==3784== in use at exit: 4,920 bytes in 4 blocks
==3784== total heap usage: 55 allocs, 51 frees, 167,287 bytes allocated
==3784==
==3784== LEAK SUMMARY:
==3784== definitely lost: 0 bytes in 0 blocks
==3784== indirectly lost: 0 bytes in 0 blocks
==3784== possibly lost: 0 bytes in 0 blocks
==3784== still reachable: 4,920 bytes in 4 blocks
==3784== suppressed: 0 bytes in 0 blocks
==3784== Rerun with --leak-check=full to see details of leaked memory
==3784==
==3784== For counts of detected and suppressed errors, rerun with: -v
==3784== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

and actually sh/dash segfaults. Since you were not able to reproduce,
I switched to bash as /bin/sh, and indeed I land were you got:

$ unshar SIGSEGV.PC.80018413.STACK.1dab0c403.CODE.1.ADDR.0xbf7fe258.INSTR.push___%ecx.fuzz
SIGSEGV.PC.80018413.STACK.1dab0c403.CODE.1.ADDR.0xbf7fe258.INSTR.push___%ecx.fuzz:
sh: line 13462: warning: here-document at line 37 delimited by end-of-file (wanted `_EOF_')
sh: line 13463: syntax error: unexpected end of file

Regards,
Salvatore