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

Issue 334897 link

Starred by 1 user

Issue metadata

Status: Fixed
Closed: Jan 2014
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Security

Sign in to add a comment

Security: Windows Sandbox Named Pipe Policy Doesn't Block Relative Paths

Reported by, Jan 16 2014

Issue description


Every sandboxed process on Windows has a default policy to create named pipes with a chrome.nacl or chrome.sync prefixes. This is done through the broker. For example the code in AddGenericPolicy is:

result = policy->AddRule(sandbox::TargetPolicy::SUBSYS_NAMED_PIPES,
  if (result != sandbox::SBOX_ALL_OK)
    return false;

This should only allow named pipes with a chrome.nacl prefix, however it doesn't as CreateNamedPipe will canonicalize the pipe path (it seems counter intuitive) if it starts with the \\.\ prefix. 
So for example call the broker passing it "\\.\pipe\chrome.nacl.\..\abc" and you will create a named pipe called "abc" outside of the chrome namespace. 

This could be fixed in a number of ways, the least impact would be to pre-canonicalize the path before evaluating the policy in NamedPipeDispatcher::CreateNamedPipe. Alternatively you could require the path be the form: \\?\pipe\... which will not get canonicalized. The "correct" way is probably to hook NtCreateNamedPipeFile instead. 

This is an exploitable condition for various different reasons. While this only opens the server side of a pipe you should be able to impersonate chrome named pipes (although wouldn't be trivial to guess the random values). You could also create a server instance of any multi-use pipe in the user's session and use that reference to change the DACL of the pipe by requesting WRITE_DAC permissions. Once the DACL has been modified you should be able to open it directly from the sandboxed process and potentially escape the sandbox. 

Chromium Version: 34.0.1784.0 - dev from SVN/GIT
Operating System: Windows 7 SP1 x64


Apply the following patch: 

--- src/content/renderer/  2014-01-16 00:50:07.609924900 +0000
+++ src/content/renderer/       2014-01-16 00:49:35.423083900 +0000
@@ -233,6 +233,26 @@
     new RenderThreadImpl();

+    {
+       HANDLE hPipe = CreateNamedPipeW(
+          L"\\\\.\\pipe\\chrome.nacl.a\\..\\this_shouldn't_work",
+          PIPE_ACCESS_DUPLEX | WRITE_DAC,       // read/write access
+          PIPE_TYPE_MESSAGE |       // message type pipe
+          PIPE_READMODE_MESSAGE |   // message-read mode
+          PIPE_WAIT,                // blocking mode
+          PIPE_UNLIMITED_INSTANCES, // max. instances
+          512,                  // output buffer size
+          512,                  // input buffer size
+          0,                        // client time-out
+          NULL);                    // default security attribute
+  if(hPipe != INVALID_HANDLE_VALUE) {
+     LOG(ERROR) << "Created Pipe (BAD)";
+  } else {
+     LOG(ERROR) << L"Failed to create pipe (GOOD)";
+  }
+    }
     base::HighResolutionTimerManager hi_res_timer_manager;


This will try and create a named pipe called 'this_shouldn't_work' for every new renderer. If it was successful in creating the pipe you should get an appropriate log message. You can also see the new pipe by looking at handle view in process explorer or process hacker. 


Comment 1 by, Jan 16 2014

Labels: OS-Windows Cr-Internals-Sandbox
Interesting bug, I was not aware that object namespaces would be vulnerable to this type of path traversal bug.  I agree probably the best option here is to canonicalize before we run the policy validation engine.
@wfh or @jschuh: you are our Windows experts. What's the severity here? Is it as readily exploitable as @tyranid documents?

Comment 3 by, Jan 16 2014

Labels: Security_Severity-High
Well, that's an obnoxious Windows quirk that I'd never even considered. Nice find.

I'm not sure about the exploitability. The Chrome IPC pipes shouldn't be vulnerable to squatting or hijacking. The pipe server includes a strong random value in the name and the client must validate itself with with a strong random nonce.

Odds should be better going after something Windows exposes. However, that's going to be very hard from a renderer or pepper process where you shouldn't be able to enumerate much of anything or trigger external activity. The GPU process may be a different story, since it can enumerate resources and trigger some activity directly.

I'll flag it high-severity out of an abundance of caution, but I'd be very curious to see a more concrete target for the bug.

Project Member

Comment 4 by ClusterFuzz, Jan 16 2014

Labels: Pri-1

Comment 5 by, Jan 16 2014

Labels: Security_Impact-Stable Security_Impact-Beta
Project Member

Comment 6 by ClusterFuzz, Jan 16 2014

Labels: M-32
Project Member

Comment 7 by ClusterFuzz, Jan 18 2014

Labels: Untriaged-1

Comment 8 by, Jan 20 2014

Status: Available

Comment 9 by, Jan 20 2014

Status: Assigned
CL is under review -
Project Member

Comment 11 by, Jan 28 2014

r247511 | | 2014-01-28T21:26:58.610728Z

Changed paths:

Correctly test for canonicalized path in the CreateNamedPipe policy engine.

BUG= 334897 

Review URL:
Project Member

Comment 12 by ClusterFuzz, Jan 29 2014

Labels: Nag
wfh@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz

Comment 13 by, Jan 29 2014

Labels: -Untriaged-1 -Nag
Status: Fixed
Project Member

Comment 14 by ClusterFuzz, Jan 29 2014

Labels: -Restrict-View-SecurityTeam M-33 Merge-Triage Restrict-View-SecurityNotify
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on

- Your friendly ClusterFuzz
Project Member

Comment 15 by, Jan 29 2014

r247725 | | 2014-01-29T18:24:37.672236Z

Changed paths:

Fix nit introduced in r247511

BUG= 334897

Review URL:
Labels: -Merge-Triage Merge-Requested
Merge requested for both M32 and M33.
Labels: -Merge-Requested Merge-Approved
Approved for M33 (1750 branch) only.
Project Member

Comment 18 by, Feb 4 2014

Labels: -Merge-Approved merge-merged-1750
r248761 | | 2014-02-04T18:57:35.579542Z

Changed paths:

Merge 247511 "Correctly test for canonicalized path in the Creat..."

> Correctly test for canonicalized path in the CreateNamedPipe policy engine.
> BUG= 334897 
> TEST=sbox_integration_tests.exe
> Review URL:

Review URL:

Comment 19 by, Feb 4 2014

Labels: -M-33 Merge-Requested
Merge requested for M32

Comment 20 by, Feb 5 2014

there will be no more 32s, please make sure to request merge to M33 instead

Comment 21 by, Feb 5 2014

Labels: -M-32 -Merge-Requested reward-topanel
Already merged to 33, so all done. Thanks!
Labels: Release-0-M33

Comment 23 by, Feb 19 2014

Labels: CVE-2013-6652
Labels: -reward-topanel reward-unpaid reward-2000
Thanks for the report! This one qualifies for a $2000 reward. This was an interesting bug and the patch you provided was very helpful for reproducing the issue. 
Hey - my apologies for the delay here. I'll start the process for this payment today. Feel free to reach out to me directly with any payment or reward questions.
Labels: -reward-unpaid reward-inprocess
Labels: -reward-inprocess
Processing via our e-payment system can take up to a month, but the reward should be on its way to you. Thanks again for your help!
Project Member

Comment 28 by ClusterFuzz, May 13 2014

Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member

Comment 29 by ClusterFuzz, Feb 2 2016

Labels: -Security_Impact-Beta
Project Member

Comment 30 by, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 31 by, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment