Ubuntu

Emacs movemail race condition

Reported by Dan Rosenberg on 2010-03-03
484
This bug affects 1 person
Affects Status Importance Assigned to Milestone
emacs21 (Ubuntu)
Medium
Unassigned
Dapper
Medium
Unassigned
Hardy
Medium
Unassigned
Intrepid
Medium
Unassigned
Jaunty
Medium
Unassigned
Karmic
Medium
Unassigned
Lucid
Medium
Unassigned
emacs22 (Ubuntu)
Medium
Unassigned
Dapper
Medium
Unassigned
Hardy
Medium
Unassigned
Intrepid
Medium
Unassigned
Jaunty
Medium
Unassigned
Karmic
Medium
Unassigned
Lucid
Medium
Unassigned
emacs23 (Ubuntu)
Medium
Unassigned
Dapper
Medium
Unassigned
Hardy
Medium
Unassigned
Intrepid
Medium
Unassigned
Jaunty
Medium
Unassigned
Karmic
Medium
Unassigned
Lucid
Medium
Unassigned

Bug Description

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.

CVE References

Kees Cook (kees) wrote :

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.

Changed in emacs22 (Ubuntu):
status: New → Confirmed
Changed in emacs23 (Ubuntu):
status: New → Confirmed
Changed in emacs22 (Ubuntu):
importance: Undecided → Medium
Changed in emacs23 (Ubuntu):
importance: Undecided → Medium
Dan Rosenberg (dan-j-rosenberg) wrote :

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) wrote :

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

Kees Cook (kees) wrote :

CVE-2010-0825

Dan Rosenberg (dan-j-rosenberg) wrote :

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) on 2010-03-04
Changed in emacs21 (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Kees Cook (kees) on 2010-03-23
Changed in emacs21 (Ubuntu Dapper):
status: New → Confirmed
importance: Undecided → Medium
Changed in emacs21 (Ubuntu Karmic):
status: New → Invalid
Changed in emacs21 (Ubuntu Hardy):
status: New → Confirmed
importance: Undecided → Medium
Changed in emacs21 (Ubuntu Intrepid):
status: New → Confirmed
importance: Undecided → Medium
Changed in emacs21 (Ubuntu Jaunty):
status: New → Confirmed
importance: Undecided → Medium
Changed in emacs21 (Ubuntu Lucid):
status: Confirmed → Invalid
Changed in emacs21 (Ubuntu Karmic):
status: Invalid → Confirmed
importance: Undecided → Medium
Changed in emacs22 (Ubuntu Dapper):
status: New → Confirmed
importance: Undecided → Medium
Changed in emacs22 (Ubuntu Hardy):
status: New → Confirmed
Changed in emacs22 (Ubuntu Dapper):
status: Confirmed → Invalid
Changed in emacs22 (Ubuntu Hardy):
importance: Undecided → Medium
Changed in emacs22 (Ubuntu Intrepid):
status: New → Confirmed
importance: Undecided → Medium
Changed in emacs22 (Ubuntu Jaunty):
status: New → Confirmed
importance: Undecided → Medium
Changed in emacs22 (Ubuntu Karmic):
status: New → Confirmed
importance: Undecided → Medium
Changed in emacs21 (Ubuntu Karmic):
status: Confirmed → Invalid
Changed in emacs23 (Ubuntu Lucid):
status: Confirmed → Invalid
Changed in emacs23 (Ubuntu Dapper):
status: New → Invalid
importance: Undecided → Medium
Changed in emacs23 (Ubuntu Hardy):
status: New → Invalid
importance: Undecided → Medium
Changed in emacs23 (Ubuntu Intrepid):
status: New → Invalid
importance: Undecided → Medium
Changed in emacs23 (Ubuntu Jaunty):
status: New → Invalid
importance: Undecided → Medium
Changed in emacs23 (Ubuntu Karmic):
status: New → Invalid
importance: Undecided → Medium
status: Invalid → Confirmed
Changed in emacs23 (Ubuntu Lucid):
status: Invalid → Confirmed
Kees Cook (kees) on 2010-03-23
visibility: private → public
visibility: public → private
Kees Cook (kees) wrote :

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) wrote :

New patch coming right up, ready in 10 minutes.

Dan Rosenberg (dan-j-rosenberg) wrote :

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) wrote :

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

Kees Cook (kees) on 2010-03-29
visibility: private → public
Kees Cook (kees) on 2010-03-29
Changed in emacs23 (Ubuntu Lucid):
status: Confirmed → Fix Released
Changed in emacs22 (Ubuntu Lucid):
status: Confirmed → Fix Released
Changed in emacs22 (Ubuntu Hardy):
status: Confirmed → Fix Released
Changed in emacs22 (Ubuntu Intrepid):
status: Confirmed → Fix Released
Changed in emacs22 (Ubuntu Jaunty):
status: Confirmed → Fix Released
Changed in emacs22 (Ubuntu Karmic):
status: Confirmed → Fix Released
Changed in emacs23 (Ubuntu Karmic):
status: Confirmed → Fix Released
Alex Valavanis (valavanisalex) wrote :

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.

Changed in emacs21 (Ubuntu Intrepid):
status: Confirmed → Invalid
Alex Valavanis (valavanisalex) wrote :

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

Changed in emacs21 (Ubuntu Jaunty):
status: Confirmed → Won't Fix
Jamie Strandboge (jdstrand) wrote :

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.

Changed in emacs21 (Ubuntu Hardy):
status: Confirmed → Won't Fix
Jamie Strandboge (jdstrand) wrote :

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.

Changed in emacs21 (Ubuntu Dapper):
status: Confirmed → Won't Fix
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