Path: csiph.com!weretis.net!feeder6.news.weretis.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!171.64.64.130.MISMATCH!usenet.stanford.edu!not-for-mail
From: Salvatore Bonaccorso <carnil@debian.org>
Newsgroups: gnu.utils.bug
Subject: Re: Vulnerability Report on Sharutils 4.15.2
Date: Sun, 25 Mar 2018 19:51:47 +0200
Lines: 51
Sender: Salvatore Bonaccorso <salvatore.bonaccorso@gmail.com>
Approved: bug-gnu-utils@gnu.org
Message-ID: <mailman.11228.1522010166.27995.bug-gnu-utils@gnu.org>
References: <47a93dc0-b0f9-9dc7-593e-ce7f96f56e19@gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: nafiez <nafiez.skins@gmail.com>
To: bug-gnu-utils@gnu.org
Envelope-to: bug-gnu-utils@gnu.org
Content-Disposition: inline
In-Reply-To: <47a93dc0-b0f9-9dc7-593e-ce7f96f56e19@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: list
Xref: csiph.com gnu.utils.bug:2232

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