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

Issue metadata

Status: Fixed
Email to this user bounced
Closed: Mar 2011
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Security: Domui process can be ptraced from a compromised renderer leading to sandbox escape

Project Member Reported by, Mar 3 2011

Issue description

I believe we should never sync extensions that can run native code.

It's obviously dangerous in a number of scenarios, and it looks like it could allow escaping the sandbox in many cases.

For instance (I have not verified this, but it seems likely):

- From inside the sandbox, use Google credentials to add a new malicious extension that can run native code to Chrome sync.
- chrome://settings/personal runs inside the sandbox in Chrome 10. It seems likely that an attacker could enable Chrome sync from inside the sandbox
- You now run native code outside the sandbox. Bonus: you also owned any machine from the same user with Chrome sync enabled.
Did this regress? This wasn't possible when sync originally shipped.
Okay, this isn't an extensions issue. Extensions are just a vector you'd use for exploit. Although, we explicitly block syncing NPAPI extensions, so the exact description of the attack wouldn't work.

@cdn will be commenting with more detail.
Summary: Security: Domui process can be ptraced from a compromised renderer leading to sandbox escape
So the real issue here is that you can ptrace the domui process from another renderer using the trick described here

With this it seems likely that you can install an NPAPI extension once you compromise a renderer giving you a sandbox escape. Julien also mentioned changing the downloads directory which seems like a plausible attack as well. 
Labels: -Pri-0 -Area-Undefined Pri-1 Area-Internals OS-Linux SecSeverity-High Mstone-10
Seting the flags. 

@jln - You seem like the most appropriate person to resolve this. Do you have time?

Comment 5 by, Mar 3 2011

Yeah sorry, Chrome sync was fine indeed.

But we have an issue with trusted settings such as chrome://extensions/ or the download directory being inside the sandbox.

It has been confirmed that the DOMUI runs as a separate process though.

On Windows, sandboxed processes should be prevented from interfering with each other. The situation on Mac is not clear yet (I'm talking to the mac sandbox people to figure this out as I don't know that sandbox).

On Linux, as I've pointed out, breakpad has to let a process become dumpable (on SIGSEGV), and so sandboxed processes can interfere with each others. The most straightforward fix at this point on this platform would be to wait for the seccomp sandbox.

But shouldn't we rather get this out of the sandbox? I fear that we will have more problems in the future.

On Linux there will always be kernels not supporting SECCOMP anyway, and there are platforms (such as ChromeOS) which won't enable the seccomp sandbox as is.

(PS: I can't add people to the CC line, I'll send you a list).

Adding linux/mac/sandbox people.

Comment 7 by, Mar 4 2011

(For the Linux specific issue, scarybeast suggested that we look at the PID of the sender of the signal. Indeed, we chould check info->si_pid in
ExceptionHandler::HandleSignal before reseting the dumpable flag)

I think the main issue here is that we're mixing trusted and untrusted things by allowing processes inside the sandbox to install extensions in general.

Comment 9 by, Mar 15 2011

After investigating a little, it looks like the check is a little more complex. System calls such as rt_sigqueueinfo and rt_tgsigqueueinfo allow to send the whole siginfo_t structure along with the signal.

This would allow an attacker to spoof things such as the PID and the UID.

The good news is that the kernel doesn't let you spoof a positive si_code (

So we need to:

1. Make sure we don't have anything using sigqueue()
2. In ExceptionHandler::HandleSignal, ignore signals if : (info->si_code <0) || (info->si_pid != 0)
Labels: Type-Security

Comment 11 by, Mar 21 2011

Updating this bug about the progress on this.

We have a problem to support signals sent via tkill()/tgkill() to yourself (via abort() for instance).

When rt_sigqueueinfo was added to the kernel, tkill didn't exist. A
check was created in rt_sigqueueinfo to make sure that userland could
not spoof signals that would appear to come from the kernel (si_code >
0) or from kill (si_code == SI_USER).

However, this check wasn't amended when tkill and tgkill were added.
This means that currently, even if si_code == SI_TKILL, there is no
guarantee that PID and uid have not been tempered with.

I'm trying to correct this in the upstream Linux kernel. People agree it's a bug, but they are also scared of correcting it now, because (even though it's extremely unlikely), it might break userland in some really old distributions.

Once this patch is accepted, (si->si_code > 0 || SI_USER == si->si_code ||
SI_TKILL == si->si_code) will become a proper way to know if a
signal's pid / uid can be trusted.
Status: Started
Labels: -Mstone-10 Mstone-11
Moving m10 bugs to m11.
Project Member

Comment 14 by, Mar 22 2011

The following revision refers to this bug:

r79003 | | Tue Mar 22 11:16:33 PDT 2011

Changed paths:

Roll breakpad DEPS.

BUG= 74763 
Review URL:
Status: WillMerge
Ok, Chrome part is landed as of

Tentatively marking WillMerge. I'll look at getting it into M11, depending on how enthusiastically Ubuntu patch their 10.04 Linux kernel package with the kernel part of the fix.
Project Member

Comment 17 by, Mar 30 2011

The following revision refers to this bug:

r79796 | | Tue Mar 29 23:08:55 PDT 2011

Changed paths:

Merge breakpad fix by rolling DEPS (src and src-branch).

BUG= 74763 
Labels: ReleaseBlock-Stable
Breakpad is changing pretty infrequently, and breakpad @r784 is working well on the dev channel release, so I'll just roll DEPS to r784 on the M11 branch:

src: Committed revision 79796. (Not sure this DEPS roll does anything but rolled it to be safe).
src-internal: Committed revision 14089.

Seems less painful than alternatives.
Status: FixUnreleased
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify CVE-2011-1439
Labels: SecImpacts-Stable
Batch update.
Lifting view restrictions.
Labels: -Restrict-View-SecurityNotify
Lifting view restrictions.
Status: Fixed
Project Member

Comment 25 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 26 by, Mar 10 2013

Labels: -Area-Internals -SecSeverity-High -Type-Security -Mstone-11 -SecImpacts-Stable Security-Impact-Stable Cr-Internals Security-Severity-High M-11 Type-Bug-Security
Project Member

Comment 27 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 28 by, Mar 21 2013

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

Comment 29 by, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
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