Bug 46998 - <=app-arch/sharutils-4.2.1-r8 - Multiple command line vulnerabilities.
|
Bug#:
46998
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: ruth@gentoo.org
|
|
Component: GLSA Errors
|
|
|
URL:
|
|
Summary: <=app-arch/sharutils-4.2.1-r8 - Multiple command line vulnerabilities.
|
|
Keywords: SECURITY
|
|
Status Whiteboard:
|
|
Opened: 2004-04-06 14:33 0000
|
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
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.
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.
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/
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)
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.
