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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:03:01 PDT