Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user
Status: Fixed
Owner: ----
Closed: May 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Security

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
Security: .keystone_install_lock is insecurely handled in install.py
Reported by googlec...@vtty.com, Apr 27 2011 Back to list

VULNERABILITY DETAILS
Keystone installer insecurely handles files in /tmp - this is similar to 44658

VERSION
Chrome Version: 11.0.696.57 + stable
Operating System: Fully patched Mac OS X v10.6.7

REPRODUCTION CASE

This is visible in the install.py script (GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/install.py):
  lockfilename = '/tmp/.keystone_install_lock'

  # Make sure that root and user can share the same lockfile
  oldmask = os.umask(0000)
  # os.O_EXLOCK is 32, but isn't defined on 10.4 (python2.3)
  lockfile = os.open(lockfilename, os.O_CREAT | os.O_RDWR | 32, 0666)

This is badness. An attacking local user can pre-create this file as a symbolic link pointing at a file that the user running the install can write, and when it is created it will be created world writable and world readable.   This directory is cleared on boot, and from time to time on certain systems, opening this up for attack against the user running this python script.

To attack, the bad guy executes: ln -s /path/to/file/to/get/install/user/to/precreate /tmp/.keystone_install_lock


 
Cc: a deleted user mark@chromium.org
Labels: -Pri-0 -Area-Undefined Pri-2 Area-Internals OS-Mac
@mark, @alex - Could one of you take a look at this and/or direct it to the appropriate keystone person?
Comment 2 by mark@chromium.org, May 2 2011
Status: ExternalDependency
This is a Keystone bug. I’ve filed it internally at http://b/4366214 and assigned it to Alex.
Labels: SecSeverity-Low
Comment 4 Deleted
Comment 5 by googlec...@vtty.com, Aug 16 2011
Did those Keystone people fix it?
Comment 6 by mark@chromium.org, Aug 16 2011
Owner: ----
Yes, install.py now does

  oldmask = os.umask(0000)
  lockfile = os.open(lockfilename, os.O_CREAT | os.O_RDONLY | os.O_NOFOLLOW,
                     0444)
  os.umask(oldmask)
  # Lock, callers that cannot wait are expected to kill us.
  fcntl.flock(lockfile, fcntl.LOCK_EX)

This is from the current shipping Keystone install.py.
Is there a public reference of this bug fix I could mention when referring to this issue?
Looks like the Chrome 14 release notes will link this bug (which I can then make public) and credit you. What's your credit line, again?
Thanks, Chris!  It is:

Aaron Sigel of vtty.com


Labels: CVE-2011-2842
Labels: SecImpacts-Stable
Batch update.
Labels: -Restrict-View-SecurityNotify
Lifting view restrictions.
Status: Fixed
Project Member Comment 14 by bugdroid1@chromium.org, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 15 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Type-Security -Area-Internals -SecSeverity-Low -SecImpacts-Stable Security-Severity-Low Security-Impact-Stable Cr-Internals Type-Bug-Security
Project Member Comment 16 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Severity-Low Security_Severity-Low
Project Member Comment 17 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Impact-Stable Security_Impact-Stable
Labels: allpublic
Sign in to add a comment