Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 51285 - app-arch/lha : buffer overflow again
Summary: app-arch/lha : buffer overflow again
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: GLSA Errors (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
Depends on:
Reported: 2004-05-17 07:15 UTC by Florian Schilhabel (RETIRED)
Modified: 2004-09-02 06:39 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Florian Schilhabel (RETIRED) gentoo-dev 2004-05-17 07:15:48 UTC
hi all,
another lha buffer overflow has been made public on [bugtraq]
as the last, this one was also discovered by Ulf Harnhammar.

[quote from bugtraq]
> 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.


here's the patch, btw:

--- lhext.c.old	2000-10-04 16:57:38.000000000 +0200
+++ lhext.c	2004-05-16 00:27:22.000000000 +0200
@@ -207,9 +207,11 @@
 	if (extract_directory)
-		sprintf(name, "%s/%s", extract_directory, q);
-	else
-		strcpy(name, q);
+		snprintf(name, sizeof(name), "%s/%s", extract_directory, q);
+	else {
+		strncpy(name, q, sizeof(name));
+		name[sizeof(name) - 1] = '\0';
+	}

so please apply, test and release a GLSA, if you want... ;-)

Reproducible: Always
Steps to Reproduce:
Comment 1 Thierry Carrez (RETIRED) gentoo-dev 2004-05-18 06:16:27 UTC
No, not again ?
usata : please have a look at the patch and bump ebuild accordingly :)
Comment 2 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-05-19 10:12:00 UTC
Hi, thanks for the patch. I couldn't find the post by Ulf Harnhammer
(Only I found,
posted by Lukasz Wojtow) though.

Koon: I applied it and bumped lha revision. 
btw, I originally wanted to rename lha-114i to lha-1.14i before these overflows 
were revealed, as 1.14i is the right version and it seems original ebuild submitter 
created the ebuild as lha-114i.ebuild only because the source archive was named 
so.  There isn't any way in Portage to map one version to another at the moment,
but I'm not too comfortable with the ebuild versioning of lha. 
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2004-05-19 14:15:15 UTC
Ready for a GLSA...

usata : if you change versions 114i -> 1.14i it will probably break upgrades (114>1.14). Maybe there is a way to handle this I don't know of. Probably better to leave it this way ?
Comment 4 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-05-20 10:02:01 UTC
Agreed. It was just a thought. I'm not going to do so since it breaks upgrades. It is not supported by Portage atm. If you remove or mask any other versions Portage will let you downgrade, say 114i-r2 to 1.14i-r3, but people don't know why they have to downgrade. I'll leave it as it is. 
Comment 5 Thierry Carrez (RETIRED) gentoo-dev 2004-05-23 04:59:15 UTC
Rereading the bug description it requires a specific parameter call, so it's not really remotely exploitable.

I would say close without GLSA. Confirm anyone ?
Comment 6 Thierry Carrez (RETIRED) gentoo-dev 2004-05-24 02:15:02 UTC
Got confirmation -- closing without GLSA
Comment 7 Matthias Geerdsen (RETIRED) gentoo-dev 2004-09-02 06:39:32 UTC
*** Bug 62618 has been marked as a duplicate of this bug. ***