SUID Scripts vulnerability

Question

In this article, it says that this C-shell script:

#!/bin/csh -b
set user = $1
passwd $user

With these permissions:

-rwsr-x---   1 root     helpdesk  

Is vulnerable because one can manipulate env variables, like:

env TERM='`cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755/tmp/sh`' change-pass

But I really don't see what the TERM env var has to see with all this. Do you have any explanation?

Answer 1

This is a design flaw in csh, allowing the evaluation of backtick escape in the contents of environment variable.

Overall, the assumption is generally made that controlling the environment of a shell should not lead to execution of arbitrary code.

Breaking this assumption creates dozens of attack vectors for remote code execution, from CGI scripts to malicious DHCP replies to mail forwarding.

When this behaviour was accidentally triggerable for bash, we called it Shellshock and made a huge fuss about it.

Answer 2

@b0fh has already explained the use of environment in csh. But the article should be obsolete in 21th century. Set uid programs are know to be possible attack vectors, and paranoid admins receive a mail each time a new setuid root program is installed - admins should always be paranoid...

But AFAIK, recent flavours of unixes do not allow setuid scripts, because it used to be much too dangerous. That means that any decent OS should ignore the s on a file that is not in executable format but only use the hash bang(#!) in its first line.

Answer 3

When a new shell is started, the environment variables are evaluated. In this case, the backticks lead to those commands being run, and the output being used as the value of TERM.

(This particular problem might be fixed, or it might not be. Generally, it's very hard to write shell scripts that are secure against clever input and will protect themselves properly when run setuid.)

Answer 4

Every program with one of the set-user/group-upon-execution bits ¹ set is a potential security risk. In the example given in this question ², the change-pass script permissions permit the running of the script and the passwd program with root privileges using the environment name space copied from other users.

The program passwd is running in terminal mode, as opposed to standard input mode, and does not want the terminal to echo password characters to the display. It calls ttyname to get the name of the terminal from the environment variable TERM to shut the echo off and otherwise direct i/o.

By substituting a back-quoted set of shell commands for the value of TERM it is possible to create an unrestricted shell to non-root users. The single quoting in the env command ensures the evaluation is postponed, in at least some shell implementations ³, until the getenv call is made for TERM by ttyname.

The unsuspecting member of the group helpdesk could open a back door to the attacker, simply by resetting a customer password using change-pass.

---

[1] The ls -l command shows this as an 's' in the permission codes. It is the '4' in the example's chmod command codes. The user and group versions of these bits are abbreviated SUID and SGID.

[2] This same exploit is reported to be effective with environment variable MAIL_CONFIG and the executable that acquires it from the environment, sudo, in the same fashion. (Credit to @adam-shostack for this alternate example.)

[3] There may be implementations that postpone TERM evaluation until the environment copy is made for the child process, the change-pass script. It is more likely that POSIX or some other standard governs when evaluation occurs and that it always defers until the value is requested.