Ubuntu

pam_motd runs commands as root with unsanitised environment

Reported by Stephane Chazelas on 2010-07-26
270
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pam (Ubuntu)
Low
Dustin Kirkland 
Lucid
Low
Dustin Kirkland 
Maverick
Low
Dustin Kirkland 
Natty
Low
Dustin Kirkland 
Oneiric
Low
Dustin Kirkland 
Precise
Low
Dustin Kirkland 

Bug Description

ii libpam-modules 1.1.1-2ubuntu5 Pluggable Authentication Modules for PAM

(lucid amd64)

pam_motd calls the scripts in /etc/update-motd.d/ as root without sanitising the environment. While that is acceptable when called for instance by sshd or by getty through login where the environment should be controlled, it becomes an issue if for instance "session optional pam_motd.so" is added to /etc/pam.d/su

With that done, a user can simply update his $PATH to look first in a directory that contains malicious replacements for commands called by the /etc/update-motd.d/ scripts (for instance "uname" called by 00_header).

pam_motd should perform the same kind of sanitisation as pam_exec, or even better not do the run-part /etc/update-motd.d/ at all but add some pam_exec calls to the pam configuration.

That issue is made worse by the fact that the running of those scripts by pam_motd is not documented.

[SRU JUSTIFICATION]
IMPACT
This bug affects those who might have manually modified their PAM configuration to add something like "session optional pam_motd.so" to a pam configuration in pam.d, such as /etc/pam.d/su, where the user controls the environment prior to executing the PAM stack. If so, the user can elevate her privileges to root by simply modifying her PATH to look in a directory that contains a malicious replacement for any of the programs called by the shell scripts in /etc/update-motd.d, such as 'uname'. Note that default Ubuntu installs are NOT affected, as pam_motd only runs in sshd and login PAM stacks, where the environment is already well controlled.

HOW ADDRESSED
The bug is trivially fixed by wrapping the run-parts shell call with an env -i, which clears the entire environment, and manually sets the PATH variable (to the same value lifted from /etc/login.defs.

PATCH
See the patch attached to this bug. It applies equally to all of the affected Ubuntu versions.

REPRODUCE INSTRUCTIONS
To test, add $HOME/bin to the path of non-root user 'kirkland'. Add a shell script, $HOME/bin/uname which does a "date >> /root/howdy". I then add "session optional pam_motd.so" to the end of /etc/pam.d/su. Before installing patched pam, su and definite see the file /root/howdy created (verifying the vulnerability). After applying and installing patched pam, you should not see /root/howdy created.

REGRESSION POTENTIAL
As far as I could tell, the rest of the update-motd part of pam_motd seemed to work correctly without regression. In the absolute worst case, /etc/motd might not be updated correctly, which is obviously not ideal, but hardly critical functionality to system operation.

Kees Cook (kees) on 2010-10-02
Changed in pam (Ubuntu):
assignee: nobody → Dustin Kirkland (kirkland)
status: New → Confirmed
importance: Undecided → Low
Changed in pam (Ubuntu):
assignee: Dustin Kirkland (kirkland) → nobody
Jamie Strandboge (jdstrand) wrote :

@Dustin, you removed yourself from the assignment even though aiui you implemented the feature. Can you provide more details?

Changed in pam (Ubuntu):
status: Confirmed → Triaged
Dustin Kirkland  (kirkland) wrote :

Jamie,

I'm attaching the patch that I've tested and verified works here for me. I sanitize the environment using env -i, and hardcode PATH to the values I pulled from /etc/login.defs:ENV_SUPATH. Arguably, there might be a few other environment values we should pass here (LANG?). I also hardcoded the path of /bin/run-parts.

I discussed this with someone in IRC (Kees? Steve? You? Sorry, I don't recall who) back in December 2010, and whomever I showed this to didn't like it. They wanted a fork/exec approach instead, which I didn't have time to implement. At that point, I unassigned myself from the bug.

To test, I added $HOME/bin to the path of user 'kirkland'. I added a shell script, $HOME/bin/uname which does a "date >> /root/howdy". I then added "session optional pam_motd.so" to the end of /etc/pam.d/su. All of this as the reported suggested.

Before applying my patch, I would su and definitely see the file /root/howdy created (verifying the vulnerability). After applying and installing my patch, I would not see /root/howdy created. As far as I could tell, the rest of the update-motd part of pam_motd seemed to work correctly without regression.

If the attached patch is acceptable, then feel free to assign this bug back to me, and I'll prepare SRUs, and upload to Oneiric.

If the attached patch is unacceptable, then I politely request that the dissatisfied parties attached a preferred diff.

Thanks,
:-Dustin

On Wed, Apr 27, 2011 at 06:23:28PM -0000, Dustin Kirkland wrote:
> I discussed this with someone in IRC (Kees? Steve? You? Sorry, I
> don't recall who) back in December 2010, and whomever I showed this to
> didn't like it. They wanted a fork/exec approach instead, which I
> didn't have time to implement. At that point, I unassigned myself from
> the bug.

Wasn't me; I'm not qualified to have an opinion on this. :)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Kees Cook (kees) wrote :

Forking was a suggestion for improving login speed (fork update-motd.d scripts) and wasn't related to this. I think the attached patch should be fine.

It would be nice to update the manpages for Oneiric too.

Changed in pam (Ubuntu Maverick):
status: New → Triaged
Changed in pam (Ubuntu Lucid):
status: New → Triaged
Changed in pam (Ubuntu Maverick):
importance: Undecided → Low
Changed in pam (Ubuntu Lucid):
importance: Undecided → Low
assignee: nobody → Dustin Kirkland (kirkland)
Changed in pam (Ubuntu Maverick):
assignee: nobody → Dustin Kirkland (kirkland)
Changed in pam (Ubuntu Natty):
assignee: nobody → Dustin Kirkland (kirkland)
Changed in pam (Ubuntu Lucid):
milestone: none → lucid-updates
Changed in pam (Ubuntu Maverick):
milestone: none → maverick-updates
Changed in pam (Ubuntu Natty):
milestone: none → natty-updates
Changed in pam (Ubuntu Oneiric):
status: New → Triaged
importance: Undecided → Low
assignee: nobody → Dustin Kirkland (kirkland)
Changed in pam (Ubuntu Oneiric):
status: Triaged → In Progress
Changed in pam (Ubuntu Natty):
status: Triaged → In Progress
Changed in pam (Ubuntu Maverick):
status: Triaged → In Progress
Changed in pam (Ubuntu Lucid):
status: Triaged → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pam - 1.1.2-2ubuntu9

---------------
pam (1.1.2-2ubuntu9) oneiric; urgency=low

  * debian/patches-applied/update-motd: santize the environment before
    calling run-parts, LP: #610125
 -- Dustin Kirkland <email address hidden> Wed, 27 Apr 2011 13:02:15 -0500

Changed in pam (Ubuntu Oneiric):
status: In Progress → Fix Released
Dustin Kirkland  (kirkland) wrote :

 - SRU justification added.
 - Uploaded to Oneiric
 - Uploaded to [lucid-proposed, maverick-proposed, natty-proposed]
 - Subscribed ubuntu-sru
 - Awaiting ack from ubuntu-sru, and acceptance of queued packages

description: updated
Changed in pam (Ubuntu Lucid):
status: In Progress → Fix Committed
Changed in pam (Ubuntu Maverick):
status: In Progress → Fix Committed
Changed in pam (Ubuntu Natty):
status: In Progress → Fix Committed
Clint Byrum (clint-fewbar) wrote :

Looks good, I'm accepting them now. One question, since its already been mentioned in an oneiric upload, when does this bug go from private -> public ?

tags: added: verification-needed

Accepted pam into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Clint Byrum (clint-fewbar) wrote :

Accepted pam into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Clint Byrum (clint-fewbar) wrote :

Accepted pam into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I don't see any reason why this bug really needs to be private
necessarily, from my PoV.

Martin Pitt (pitti) wrote :

This really shouldn't be an SRU, but a security update. Now that the update is in -proposed, it's public and thus the bug should be public as well, making so.

visibility: private → public
Jamie Strandboge (jdstrand) wrote :

Since this is already part of the SRU process, let's just follow that and when it is accepted, the security team can do a no change rebuild. Alternatively, at the time the SRU team would accept it, we can do a no change rebuild in -security and push updates out then (to reduce archive churn and pain do to pam service restarts).

Marc Deslauriers (mdeslaur) wrote :

I will be releasing pam security updates in a week or so, so I will bundle this issue with them.

Kees Cook (kees) wrote :

This still needs fixing, unfortunately. "env" is called without a fully qualified path, which means a malicious PATH can still cause problems. (Again, only in the case of having pam_motd added to non-default pam service configs that are local setuid applications.)

Changed in pam (Ubuntu Precise):
status: Fix Released → Triaged
Changed in pam (Ubuntu Oneiric):
status: Fix Released → Triaged
Changed in pam (Ubuntu Natty):
status: Fix Committed → Triaged
Changed in pam (Ubuntu Maverick):
status: Fix Committed → Triaged
Changed in pam (Ubuntu Lucid):
status: Fix Committed → Triaged
Changed in pam (Ubuntu Oneiric):
milestone: none → oneiric-updates
Changed in pam (Ubuntu Precise):
milestone: natty-updates → none
Dustin Kirkland  (kirkland) wrote :

Proposed patch attached.

Dustin Kirkland  (kirkland) wrote :

Strangely, this patch was dropped from natty and oneiric. What happened?

Marc Deslauriers (mdeslaur) wrote :

Looks like another UDD casualty:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/pam/oneiric/revision/79#debian/changelog

I still see the patch in natty, so looks like it's only missing in Oneiric.
Thanks for the fix Dustin, I'll push it out as a security update once I get a proper CVE.

Steve Langasek (vorlon) wrote :

On Thu, Oct 13, 2011 at 11:05:46PM -0000, Dustin Kirkland wrote:
> Strangely, this patch was dropped from natty and oneiric. What
> happened?

The patch was not committed to the Vcs-Bzr branch that's documented as
authoritative in the package's debian/control file, so the change was
dropped in the next merge from Debian. Please make sure to push your
changes to lp:~ubuntu-core-dev/pam/ubuntu.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Dustin Kirkland  (kirkland) wrote :

Thanks Marc.

Marc Deslauriers (mdeslaur) wrote :

This is CVE-2011-3628.

Jamie Strandboge (jdstrand) wrote :

Thank you for reporting this bug to Ubuntu. maverick has reached EOL
(End of Life) and is no longer supported. As a result, this bug
against maverick is being marked "Won't Fix". Please see
https://wiki.ubuntu.com/Releases for currently supported Ubuntu
releases.

Please feel free to report any other bugs you may find.

Changed in pam (Ubuntu Maverick):
status: Triaged → Won't Fix
Jamie Strandboge (jdstrand) wrote :

Thank you for reporting this bug to Ubuntu. natty has reached EOL
(End of Life) and is no longer supported. As a result, this bug
against natty is being marked "Won't Fix". Please see
https://wiki.ubuntu.com/Releases for currently supported Ubuntu
releases.

Please feel free to report any other bugs you may find.

Changed in pam (Ubuntu Natty):
status: Triaged → Won't Fix
Niko Ehrenfeuchter (he1ix) wrote :

Could we get an update here, please? There's a fix available for almost one and a half years now.

Changed in pam (Ubuntu Precise):
status: Triaged → Fix Released
Changed in pam (Ubuntu Oneiric):
status: Triaged → Fix Released
Changed in pam (Ubuntu):
status: Triaged → Fix Released
Dustin Kirkland  (kirkland) wrote :

This looks fixed in raring, precise, oneiric, and lucid:

$ grep -r env.*run-parts:

./pam-1.1.3/debian/patches-applied/update-motd:+ if (!system("/usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /var/run/motd.new"))
./pam-1.1.3/debian/patches-applied/update-motd:+ if (!system("/usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /var/run/motd.new"))
./pam-1.1.3/debian/patches-applied/update-motd:+ if (!system("/usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /var/run/motd.new"))
pam-1.1.1/debian/patches-applied/update-motd:+ if (!system("/usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d > /var/run/motd.new"))

Changed in pam (Ubuntu Lucid):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers