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: Mohd Hanafie <nafiez.skins@gmail.com>
Newsgroups: gnu.utils.bug
Subject: Re: Vulnerability Report on Sharutils 4.15.2
Date: Sun, 25 Mar 2018 23:17:45 +0000
Lines: 64
Approved: bug-gnu-utils@gnu.org
Message-ID: <mailman.11236.1522019881.27995.bug-gnu-utils@gnu.org>
References: <47a93dc0-b0f9-9dc7-593e-ce7f96f56e19@gmail.com> <20180325175147.GA13587@eldamar.local>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: bug-gnu-utils@gnu.org
To: Salvatore Bonaccorso <carnil@debian.org>
Envelope-to: bug-gnu-utils@gnu.org
In-Reply-To: <20180325175147.GA13587@eldamar.local>
Precedence: list
Xref: csiph.com gnu.utils.bug:2233

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 <carnil@debian.org>
wrote:

> 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
>
-- 
Thanks,
Nafiez