from bugtraq@securityfocus.com: ... Details ######## A stack-based buffer overflow vulnerability exists in the popular 'shar' utility packaged in the GNU sharutils distribution, due to lack of bounds checking when handling the '-o' command-line option. During the command-line argument parsing routine, when the '-o' flag is encountered, 'shar' performs a 'strcpy()' call to blindly copy the user-supplied argument after '-o' without bounds checking, into a fixed length buffer, output_base_name, which has only 50 allocated to it. ... Solution ######### I contacted the vendor, GNU, and received no response within 4 1/2 days. Although this issue isn't to be considered a serious security threat, there are instances where this can be exploited by a would-be attacker to execute code, such as in the circumstances suggested above (cgi script, sXid program, etc). Therefore, it would be considered good practice to apply the fix regardless of whether your system is likely to be compromised as a result of the issue. I have written a simple patch below to fix the buffer overflow bug: --- shar-bof.patch --- --- shar.1.c 2004-04-06 16:26:55.000000000 +0100 +++ shar.c 2004-04-06 16:32:32.000000000 +0100 @@ -1905,7 +1905,7 @@ break; case 'o': - strcpy (output_base_name, optarg); + strncpy (output_base_name, optarg, sizeof(output_base_name)); if (!strchr (output_base_name, '%')) strcat (output_base_name, ".%02d"); part_number = 0; --- EOF --- ... above text is a snippet from the bugtraq maillist. Apply the patch, and rebuild: --- bash# patch < shar-bof.patch && make && make install so long rootshell Reproducible: Always Steps to Reproduce: 1. 2. 3.
sharutils-4.2.1-r8 has this patch i dont think we need a GLSA as this doesnt seem to have any exploitable-ness to it ...
4.2.1-r8 must be stable before we get into GLSA process. Resetting component to Security.
i tested on x86 / sparc / hppa so those are stable now
alpha and ia64 are stable
Stable on mips.
sharutils-4.2.1-r8 bug update. Currently in cvs portage tree as. KEYWORDS="x86 ~amd64 ~ppc sparc alpha hppa ia64 ~ppc64 s390 mips" Adding amd64 & ppc to this bug. I would think this would fall under the "good practice" vs GLSA and thus the 'Severity' could be lowered from critical to normal. Users can usually walk all over themselves from the command line.
Marked stable on amd64
While adding another patch to the sharutils bug that Florian had sent us in mail, I noticed that the code lacked bounds checking a few lines below in the same -o option. --- 1907,1912 ---- case 'o': strcpy (output_base_name, optarg); + memset(output_base_name, '\0', sizeof(output_base_name)); + strncpy (output_base_name, optarg, sizeof(output_base_name)-1); if (!strchr (output_base_name, '%')) strcat (output_base_name, ".%02d"); As we can see we can fill the string up to sizeof(blah)-1 but what if the string contains a format identifier? It will overflow right again. Not only will it overflow but we have the full makings here of a format string vuln. Check it out.. solar@simple sharutils $ shar -o `perl -e 'print "%p" x 54'` solar@simple sharutils $ ls solar@simple sharutils $ shar -o `perl -e 'print "%p" x 54'` shar: No input files Try `shar --help' for more information. solar@simple sharutils $ ls 0x10x2e80f0200x30356230x5e2e60c80x2e8e1dd70x30x5e2e62a40xe25c7dd0xe25ecc00xe25eff00xe25f1e00xe25f2120x5e2e62580xe258dcd0xe25f1e00x250x320xe25ecc0(nil)0x2e82dd500x2e8253f00x2e80fb200x30x2e80fda80x2e80eff8 # fun with all the format identifiers... shar -o `perl -e 'print "%d" x 54'` shar -o `perl -e 'print "%s" x 54'` It's safe to say this is not fixed and new patch should be created.
I'm reviewing this patch shortly. http://marc.theaimsgroup.com/?l=bugtraq&m=108164583423126&w=2
Ok patch works for the -o format string problem. But while looking over other areas of code in sharutils I found what looks like more undesired voodoo.. Actually quite a bit of it. This thing needs either a complete rewrite or a full audit in my opinion. Neither of which I intend to do.. (Volunteers Welcome) I also can't make heads/tails of who to exactly mail upstream about all this.
OK, the only semi-relevant email address I can find is bug-gnu-utils@prep.ai.mit.edu, which is listed in the README included with the sharutils sources. I contacted them and asked them to look at our bug here and provide some sort of response. (and hopefully a patch)
OK, Google proved its worth once more. The current active address for bug-gnu-utils seems to be bug-gnu-utils@gnu.org. Looking at the archives[1] for the mailing list, it appears there are two semi-active maintainers of sharutils; Karl Eichwalder <keichwa@gmx.net> and Paul Eggert <eggert@twinsun.com>. Solar -- since you're most familiar with the issues you've found in sharutils (outside of the -o issue) would you mind emailing these folks and asking for their input? [1]http://mail.gnu.org/archive/html/bug-gnu-utils/
mail sent.
Created attachment 31485 [details, diff] command line handling From: Karl Eichwalder <ke@gnu.franken.de To: solar@gentoo.org Cc: eggert@twinsun.com Subject: Re: <=app-arch/sharutils-4.2.1-r8 - Multiple command line vulnerabilities. Date: Sat, 15 May 2004 11:19:19 +0200 Thanks for the info; I'm going to add tht appended patch supplied by Suse Linux. My sharutils CVS is here: http://developer.berlios.de/projects/sharutils/ - if one of you wants to become a "developer" or a "project admin" please drop me a line. 2004-05-15 Karl Eichwalder <ke@gnu.franken.de> * shar.c (open_output): Fix command line handling; reported by Ned Ludd: http://bugs.gentoo.org/show_bug.cgi?id=46998 Use patch supplied by Michael Schr
Created attachment 31485 [details, diff] command line handling From: Karl Eichwalder <ke@gnu.franken.de To: solar@gentoo.org Cc: eggert@twinsun.com Subject: Re: <=app-arch/sharutils-4.2.1-r8 - Multiple command line vulnerabilities. Date: Sat, 15 May 2004 11:19:19 +0200 Thanks for the info; I'm going to add tht appended patch supplied by Suse Linux. My sharutils CVS is here: http://developer.berlios.de/projects/sharutils/ - if one of you wants to become a "developer" or a "project admin" please drop me a line. 2004-05-15 Karl Eichwalder <ke@gnu.franken.de> * shar.c (open_output): Fix command line handling; reported by Ned Ludd: http://bugs.gentoo.org/show_bug.cgi?id=46998 Use patch supplied by Michael Schröder: http://bugzilla.suse.de [#39122, password protected].
Updated existing patch in portage tree but revision bumped to force updates. sharutils-4.2.1-r9.ebuild: KEYWORDS="~x86 ~amd64 ~ppc ~sparc ~alpha ~hppa ~ia64 ~ppc64 ~s390 ~mips"
arch-maintainers : please mark stable on all arches (except arm)
Marked stable on sparc.
Marked stable on hppa.
Marked stable on mips.
Stable on amd64 and x86
Stable on alpha.
Stable on ppc
Ready for a GLSA draft
Send a GLSA if you want. But please note that further auditing should be done on sharutils.
GLSA drafted for the case we need it...
Not really exploitable so closed without GLSA.
