Bugzilla – Bug 54178
VUL-0: CVE-2004-0235: LHA buffer overflows
Last modified: 2021-10-01 08:02:27 UTC
Date: Sun, 18 Apr 2004 02:58:46 +0200 From: Ulf Härnhammar <Ulf.Harnhammar.9485@student.uu.se> To: vendor-sec@lst.de Cc: tsugio@muc.biglobe.ne.jp Subject: [vendor-sec] LHA buffer overflows + directory traversal security problems Parts/Attachments: 1 Shown ~161 lines Text 2 1.6 KB Application ---------------------------------------- Hello, I have found some security problems in LHA. The program has two stack-based buffer overflows and two directory traversal problems. All four problems affect versions 1.14d to 1.14i, 1.17 (Linux binary) and possibly also 1.00. It is worth noting that some antivirus scanners - AMaViS, for instance - require LHA and run it automatically on messages from the network to look for viruses inside lha archives. The buffer overflows occur when testing (t) or extracting (x) archives where the archive contents have too long filenames or directory names. You get control over several registers including EIP, as you can see in this session capture: $ lha t buf_oflow.lha.bin LHa: Error: Unknown information UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUU Segmentation fault $ lha x buf_oflow.lha.bin LHa: Error: Unknown information UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUU Segmentation fault $ gdb lha GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)... (gdb) r t buf_oflow.lha.bin Starting program: /usr/bin/lha t buf_oflow.lha.bin (no debugging symbols found)...(no debugging symbols found)...LHa: Error: Unknown information UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU Program received signal SIGSEGV, Segmentation fault. 0x55555555 in ?? () (gdb) bt #0 0x55555555 in ?? () Cannot access memory at address 0x55555555 (gdb) i r eax 0x4001e4a0 1073865888 ecx 0xffffffe0 -32 edx 0x24 36 ebx 0x55555555 1431655765 esp 0xbffff2d0 0xbffff2d0 ebp 0x55555555 0x55555555 esi 0x55555555 1431655765 edi 0x55555555 1431655765 eip 0x55555555 0x55555555 eflags 0x10286 66182 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x33 51 (gdb) r x buf_oflow.lha.bin The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/bin/lha x buf_oflow.lha.bin (no debugging symbols found)...(no debugging symbols found)...LHa: Error: Unknown information UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU Program received signal SIGSEGV, Segmentation fault. 0x55555555 in ?? () (gdb) bt #0 0x55555555 in ?? () Cannot access memory at address 0x55555555 (gdb) i r eax 0x4001e4a0 1073865888 ecx 0xffffffe0 -32 edx 0x24 36 ebx 0x55555555 1431655765 esp 0xbfffdd50 0xbfffdd50 ebp 0x55555555 0x55555555 esi 0x55555555 1431655765 edi 0x55555555 1431655765 eip 0x55555555 0x55555555 eflags 0x10282 66178 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x33 51 (gdb) q The program is running. Exit anyway? (y or n) y $There are also directory traversal problems, both with absolute paths and relative paths. There is no protection against relative paths at all, so you can simply use the lha binary to create an archive with paths like "../../../../../etc/cron.d/evil". There is some simple protection against absolute paths, namely skipping the first character if it is a slash, but again you can simply use the binary to create archives with paths like "//etc/cron.d/evil". I have written a patch against the upstream version 1.14i that corrects all four problems. The patch is included as an attachment, together with some test archives. I hope to be able to work with the LHA authors and the vendor-sec list subscribers to resolve this problem in a coordinated manner. I could not find an e-mail address to the LHA 1.17 author, so if the LHA 1.14 author has it, perhaps he or she could forward this e-mail to him or her? // Ulf Harnhammar
<!-- SBZ_reproduce --> See bug description
CAN-2004-0234 for the buffer overflows (both) CAN-2004-0235 for the lack of protection against directory traversal
Can you attach the patch or URL? Note for reporter: I have tried to contact author twice (to get source of 1.17). No reply.
No patches yet. I will ask vendor-sec. April 29th seems to be release date.
Created attachment 18452 [details] overflow and directory traversal patch I did not check whether the patch takes into account that the size variables etc could be negative (do not have the LHA sources handy).
I have now patched packages for stable-all sles7 sles7-ppc sles9-all ul1-all 8.0-all 8.2-all 9.0-all. header_size is declared as int and assigned as (header_size = get_word()), so n theory it can not be negative on platforms, where sizeof(int)>sizeof(word). Please confirm and I will submit it.
Depends on the Code. it can, due to signed extension: #include <stdio.h> short get_word() { return 0xffff; } int main(int argc, char *argv[]) { int i = get_word(); printf("%d\n", i); return 0; } I will have a look at the LHA code.
I checked the code. since get-word() returns unsigned word, it is ok. So the patch is ok. Please submit.
Fix submitted for: stable-all sles7 sles7-ppc sles9-all ul1-all 8.0-all 8.2-all 9.0-all
So where are the patchinfo files?
Just a second. I am writing them...
Created attachment 18651 [details] patchinfo ...
Created attachment 18652 [details] patchinfo for box ...
Patchinfos created and submitted. Please tell suse-dist.
Mail to suse-dist was sent.
packages tested by qa-team. do we have a coordinated release date, Sebastian.
I think April 29th. I asked vendor-sec.
Just approved packages. Will be announced with next advisory in section2.
CVE-2004-0235: CVSS v2 Base Score: 6.4 (AV:N/AC:L/Au:N/C:P/I:P/A:N)