New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 80680 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: May 2011
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Security

  • Only users with Commit permission may comment.

Sign in to add a comment

Security: .keystone_install_lock is insecurely handled in

Reported by, Apr 27 2011

Issue description

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

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


This is visible in the script (GoogleSoftwareUpdate.bundle/Contents/Resources/
  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.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
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, 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, Aug 16 2011

Did those Keystone people fix it?

Comment 6 by, Aug 16 2011

Owner: ----
Yes, now does

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

This is from the current shipping Keystone
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

Labels: CVE-2011-2842
Labels: SecImpacts-Stable
Batch update.
Labels: -Restrict-View-SecurityNotify
Lifting view restrictions.
Status: Fixed
Project Member

Comment 14 by, 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, 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, Mar 21 2013

Labels: -Security-Severity-Low Security_Severity-Low
Project Member

Comment 17 by, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment