| Summary: | app-arch/lha : buffer overflow again | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Florian Schilhabel (RETIRED) <ruth> |
| Component: | GLSA Errors | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | usata, vorlon |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
No, not again ? usata : please have a look at the patch and bump ebuild accordingly :) Hi, thanks for the patch. I couldn't find the post by Ulf Harnhammer (Only I found http://msgs.securepoint.com/cgi-bin/get/bugtraq0405/126.html, 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. 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 ? 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. 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 ? Got confirmation -- closing without GLSA |
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. [/quote] --- 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... ;-) florian Reproducible: Always Steps to Reproduce: 1. 2. 3.