full-disclosure - Re: lha buffer overflow(s) again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: Ulf.Harnhammar.9485 at student.uu.se (Ulf Härnhammar)
Subject: Re: lha buffer overflow(s) again

> it seems that lha is quite poorly written. after your last advisory, i
> decided to take a look at the code and found 2 BO in function extract_one
> (file lhext.c):
>         if (extract_directory)
>                 sprintf(name, "%s/%s", extract_directory, q);
>         else
>                 strcpy(name, q);

The first case (when the if clause evaluates to true) is a buffer
overflow, but it only occurs when lha is called with long command
line parameters:

lha xw=[about 390-400 characters] some_lharc_archive.lha

(It also works with other commands than x.)

Since q has a size of 256, and name has a size of 257, the second
case is not really a problem.

I have attached a patch against the upstream version 1.14i that
corrects this.

// Ulf Harnhammar
   looking for a summer vacation job
   http://www.advogato.org/person/metaur/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lha.obscure_buf_oflow.patch
Type: application/octet-stream
Size: 427 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040516/8bbeb569/lha.obscure_buf_oflow.obj