Emacs movemail race condition

[Dan Rosenberg]

Binary package hint: emacs22

As a part of emacs22, specifically from emacs22-bin-common (also confirmed with emacs23), "movemail" is installed as /usr/lib/emacs/22.2/i486-linux-gnu/movemail (at least on my x86 Karmic machine), setgid mail.

A quick glance at the code (lib-src/movemail.c) reveals a glaringly obvious race condition, where permission to read/write the input and output files is checked using access() before opening them without further checking later in the code. Since this program is setgid mail, this allows an attacker to alter the contents of another user's mailbox, or read their mailbox (provided they are using a traditional Unix mail system where mailboxes are group "mail"). I've confirmed exploitability with a simple script that toggles a symbolic link.

I'll submit a patch for this issue this weekend.

[Kees Cook (kees)]

Thanks for the report! The code looks pretty bad, yes. Would you mind sharing the proof-of-concept script? (and do you mind me sharing with vendor-sec, even I mark it as "private"?) I can delete the script from this bug report before making the bug public after the issues have been fixed.

[Dan Rosenberg (dan-j-rosenberg)]

I've attached my exploit here, it's a one-shot script that takes care of everything. Let me know if you have any trouble reproducing the issue. The target mailbox should be owned by another user, group "mail", and readable by mail.

[Kees Cook (kees)]

Yeah, easily confirmed. Nice catch. (cosmetic s/killall exploit.sh/killall loop.sh/ to clean up)

[Kees Cook (kees)]

CVE-2010-0825

[Dan Rosenberg (dan-j-rosenberg)]

I've attached my patch for the issue. I removed the calls to access(), and instead called setegid() to drop group permissions before opening both the input and output files. I re-raised the egid after this, because movemail needs egid mail to create a lockfile in the mail directory if it's not world-writeable. Movemail already dropped the euid with setuid() prior to opening the files, so I didn't have to deal with that. I inserted checks on the return values of all the setuid() functions, just to be safe.

I've confirmed that this resolves the vulnerability and does not break functionality.

[Kees Cook (kees)]

While testing this patch, it seems that there is still a condition where movemail wipes the mailbox (though it doesn't leak contents any more).

Here is an updated reproducer that tests for the conditions...

[Dan Rosenberg (dan-j-rosenberg)]

New patch coming right up, ready in 10 minutes.

[Dan Rosenberg (dan-j-rosenberg)]

As promised...this takes the same approach as before - dropping the egid before calls to open() or creat(). I made another pass through the code to make sure there weren't any other vulnerable calls, so this should finally kill these bugs. I tested using the reproducer to confirm it fixes the race, and made sure functionality is still intact.

[Kees Cook (kees)]

Cool! Thanks very much for the quick turn-around. :)

[Kees Cook (kees)]

http://www.ubuntu.com/usn/USN-919-1

[Alex Valavanis (valavanisalex)]

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the
report. The bug is still marked as confirmed in later versions of Ubuntu.

[Alex Valavanis (valavanisalex)]

Jaunty reached end-of-life on 23 October 2010 so I'll close the report

[Jamie Strandboge (jdstrand)]

Thank you for reporting this bug and helping to make Ubuntu better. The package referred to in this bug is in universe or multiverse and reported against a release of Ubuntu (hardy) which no longer receives updates outside of the explicitly supported LTS packages. While the bug against hardy is being marked "Won't Fix" for now, if you are interested feel free to post a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures'

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

[Jamie Strandboge (jdstrand)]

Thank you for reporting this bug to Ubuntu. dapper has reached EOL
(End of Life) and is no longer supported. As a result, this bug
against dapper 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.