bugtraq - 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]

Message-ID: <1084661855.40a6a05ff3aac@webmail.uu.se>
Date: Sun, 16 May 2004 00:57:35 +0200
From: Ulf Härnhammar <Ulf.Harnhammar.9485@...dent.uu.se>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.netsys.com
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/


Download attachment "lha.obscure_buf_oflow.patch" of type "application/octet-stream" (427 bytes)