Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Vulnerability Report on Sharutils 4.15.2

2 views
Skip to first unread message

Salvatore Bonaccorso

unread,
Mar 25, 2018, 4:36:07 PM3/25/18
to bug-gn...@gnu.org, nafiez
Hi

On Wed, Feb 21, 2018 at 03:06:34PM +0800, nafiez wrote:
> 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).
>
> john@fuzzing:~/sharutils-4.15.2/src/crashed_unshar$ gdb -q ../unshar
> 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".
> 2.fuzz:
> 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
> #3  0xb790e3e4 in new_do_write (fp=fp@entry=0xb4103b50,
> data=data@entry=0xb6100100 "", to_do=to_do@entry=4096) at fileops.c:518
> #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

unread,
Mar 25, 2018, 7:18:03 PM3/25/18
to Salvatore Bonaccorso, bug-gn...@gnu.org
Hi,

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

Thanks!


On Mon, 26 Mar 2018 at 1:51 AM, Salvatore Bonaccorso <car...@debian.org>
wrote:
--
Thanks,
Nafiez

Petr Pisar

unread,
Mar 26, 2018, 9:06:36 AM3/26/18
to bug-gn...@gnu.org
On 2018-03-25, Mohd Hanafie <nafiez...@gmail.com> wrote:
> 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

unread,
Mar 26, 2018, 6:34:55 PM3/26/18
to Mohd Hanafie, bug-gn...@gnu.org
Hi,

On Sun, Mar 25, 2018 at 11:17:45PM +0000, Mohd Hanafie wrote:
> 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

unread,
Apr 6, 2018, 9:08:07 AM4/6/18
to Mohd Hanafie, bug-gn...@gnu.org
Hi!

[adding back the bug-gn...@gnu.org list]

On Mon, Mar 26, 2018 at 04:49:56AM +0000, Mohd Hanafie wrote:
> 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

unread,
Apr 10, 2018, 11:02:48 AM4/10/18
to bug-gn...@gnu.org
On 2018-04-06, Salvatore Bonaccorso <car...@debian.org> wrote:
> 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

unread,
Apr 14, 2018, 5:30:43 AM4/14/18
to bug-gn...@gnu.org
Hi Petr
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

0 new messages