[7224] in bugtraq
Re: Forwared to me
daemon@ATHENA.MIT.EDU (Solar Designer)
Fri Jul 10 15:06:39 1998
Date: Fri, 10 Jul 1998 04:41:36 +0400
Reply-To: Solar Designer <solar@FALSE.COM>
From: Solar Designer <solar@FALSE.COM>
X-To: medeiros@ENG.USF.EDU
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.GSO.3.96.980708141826.4646A-100000@suntan> from "Raymond
Medeiros" at Jul 8, 98 02:20:01 pm
Hello,
> # mv /usr/bin/finger /usr/bin/finger.exe
> # cat > /usr/bin/finger
> #!/bin/sh
> exec /usr/bin/finger.exe -m $*
> ^D
> # chmod +x /usr/bin/finger
Hmm, weird, this doesn't look safe to me. Why trust the extra parsing done
by the shell? Look at this:
sunny:~$ finger "a -b"
finger: a -b: no such user.
sunny:~$ finger a -b
finger: illegal option -- b
usage: finger [-lmps] [login ...]
Now, many implementations of fingerd just run finger on data received from
the remote, doing some sanity checks first, and splitting the arguments
for execv(). These checks often include denying passing of some or all
options to finger. If fingerd knows about less word separators than the
shell does, then an attacker might be able to pass a forbidden option to
finger. For example, if our fingerd didn't know about tabs (which isn't a
security hole yet: our fingerd uses execv(), remember?), a remote attacker
could send us "user\t-option".
I admit that the problem isn't serious: not all fingerd's are done this
way, forbidden finger options are likely to violate someone's privacy
only, etc. Still, it's not a good idea to trust the shell, in general.
Signed,
Solar Designer
