Re: Vulnerability Report on Sharutils 4.15.2
Salvatore Bonaccorso <[email protected]> Sat, 14 Apr 2018 11:30:21 +0200
| Newsgroups | gmane.comp.gnu.utils.bugs |
|---|---|
| Message-ID | <[email protected]> |
Hi Petr On Tue, Apr 10, 2018 at 02:54:32PM +0000, Petr Pisar wrote: > On 2018-04-06, Salvatore Bonaccorso <[email protected]> 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