[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Emacs backup file mode bits vulnerability

From: Atul Prakash
Subject: Emacs backup file mode bits vulnerability
Date: Tue, 15 Nov 2005 21:31:28 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915

Attached is a description of a vulnerability that results from use of emacs for editing files that are readable by a group on Unix. I have put it in the CERT's format and have also filed a report
with CERT. Hopefully you can fix it.

A possible improvement would be not make backup files readable except by the user (unset group and other mode

I discovered this when helping our staff on how an attacker may have got hold of contents of an /etc/shadow file on
one of the machines.

-- Atul Prakash
Professor, Dept. of EECS

Let us know who you are:

 Name                   : Atul Prakash
 E-mail                 : address@hidden
 Phone / fax            : 734-763-1585/734-763-8094
 Affiliation and address: Department of EECS, Univ. of Michigan, Ann Arbor,
                                MI 48109

Have you reported this to the vendor?  [yes/no] no.

        If so, please let us know whom you've contacted:

        Date of your report     :
        Vendor contact name     :
        Vendor contact phone    :
        Vendor contact e-mail   :
        Vendor reference number :

        If not, we encourage you to do so--vendors need to hear about
        vulnerabilities from you as a customer.

We encourage communication between vendors and their customers.  When
we forward a report to the vendor, we include the reporter's name and
contact information unless you let us know otherwise.

If you want this report to remain anonymous, please check here:

        ___ Do not release my identity to your vendor contact.

If there is a CERT Vulnerability tracking number please put it
here (otherwise leave blank): VU#______.

Please describe the vulnerability.
- ----------------------------------

Emacs can create temporary files (ending with ~) that have different
permissions than the file being edited. 
file that was opened in emacs:
/etc/shadow:  with Unix Permissions -r--r-----  root shadow

additional file that is created by emacs and left in the directory if
a root user attempts to look at the file or edit it in emacs:
/etc/shadow~: with Unix Permissions -r--r----- root root

(Notice that the group ownership changed from shadow to group) 

If the new group has larger membership, the tilde file can be read by
people who could not read the original file. 

What is the impact of this vulnerability?
- -----------------------------------------
 (For example: local user can gain root/privileged access, intruders
  can create root-owned files, denial of service attack,  etc.)

It can be used to grab contents of protected files such as /etc/shadow if
an attacker can manage to acquire access to a person's account who is listed
in the root group, even if that person is not the root.  Then, the 
attacker can run password cracking tools to break other passords.

   a) What is the specific impact:

Overall, it makes it dangerous to use emacs to edit files that have group 
permissions set because the group for temp files may not be the same as the
group for the original file. Information can be leaked.

   b) How would you envision it being used in an attack scenario:

Consider the following:

        -- root account is secure.
        -- But an attacker manages to sniff or break a person's password who
                is listed in the root group in /etc/group.
                (or he could use other vulnerabilities such as NFS to break
                        into a machine).
        -- The attacker checks to see if there are files left around by emacs
                such as /etc/shadow~ that are readable to the root group.
        -- The attacker mails these files to his account.

To your knowledge is the vulnerability currently being exploited?
- -----------------------------------------------------------------

It may have been exploited on EECS servers at the Univ. of Michigan. By 
default,/etc/shadow was readable only to the root account and to the shadow 
The shadow group was listed in /etc/group, but did not have any valid userids.

However, we found evidence that an attacker managed to steal the file
without accessing the root account. A good possibility is that the attacker
managed to compromise someone in the root group, which had about 10 members. 
There was a file /etc/shadow~, which was left by emacs, which was readable
to the root group.

If there is an exploitation script available, please include it here.
- ---------------------------------------------------------------------

Below is a shell script.


# Run this script as root

echo "Run this script as root in an empty directory"

echo "hit Return if ready..."


# Create a test file foo
echo "sensitive content" > foo

# Make it readable by root and by the default root group
chmod 0440 foo

# Change group ownership of foo from default group (e.g., root) to tty
chgrp tty foo

# Now edit the file using emacs. Make sure you modify it.

echo "Modify foo using emacs as root." 
echo "A tilde backup file foo~ should be created if you modify the file" 
echo "Hit Return when done."


echo "Following are the permissions of foo and foo~. Problem if they are 
ls -l foo
ls -l foo~ 

Do you know what systems and/or configurations are vulnerable?
- --------------------------------------------------------------
        [yes/no]  (If yes, please list them below)

        System          : Emacs, Version 21.3.1
        OS version      : Redhat Fedora Core 3
        Verified/Guessed: verified

Are you aware of any workarounds and/or fixes for this vulnerability?
- ---------------------------------------------------------------------
        [yes/no] (If you have a workaround or are aware of patches
              please include the information here.)


The only precaution would be to not edit group-readable files using emacs.
Or to make sure you delete any backup files created by emacs.

Is there anything else you would like to tell us?

- --------

reply via email to

[Prev in Thread] Current Thread [Next in Thread]