Re: Vulnerability Report on Sharutils 4.15.2

[Salvatore Bonaccorso]

Hi Petr

On Tue, Apr 10, 2018 at 02:54:32PM +0000, Petr Pisar wrote:
> On 2018-04-06, Salvatore Bonaccorso <address@hidden> 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.

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