bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Vulnerability Report on Sharutils 4.15.2


From: Salvatore Bonaccorso
Subject: Re: Vulnerability Report on Sharutils 4.15.2
Date: Sun, 25 Mar 2018 19:51:47 +0200
User-agent: Mutt/1.9.4 (2018-02-28)

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).
>
> address@hidden:~/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 (address@hidden,
> address@hidden "", address@hidden) 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]