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:
Email to this user bounced
Closed: Mar 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Security

Restricted
  • 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 jln@chromium.org, Mar 3 2011 Back to list
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 (was: NULL)
So the real issue here is that you can ptrace the domui process from another renderer using the trick described here https://groups.google.com/a/google.com/group/client-linux-sandbox/browse_thread/thread/3000583cf83c004a/9100f1cf3ef143af?lnk=st&q=Intra-sandbox+protection+within+the+setuid+sandbox#9100f1cf3ef143af

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 jln@chromium.org, 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 jln@chromium.org, 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 jln@chromium.org, 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 (http://lxr.linux.no/linux+v2.6.32/kernel/signal.c#L2352).

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 jln@chromium.org, 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 bugdroid1@chromium.org, Mar 22 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=79003

------------------------------------------------------------------------
r79003 | cevans@chromium.org | Tue Mar 22 11:16:33 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?r1=79003&r2=79002&pathrev=79003

Roll breakpad DEPS.

BUG= 74763 
TEST=none
Review URL: http://codereview.chromium.org/6719018
------------------------------------------------------------------------
Status: WillMerge
Ok, Chrome part is landed as of http://src.chromium.org/viewvc/chrome?view=rev&revision=79003

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 bugdroid1@chromium.org, Mar 30 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=79796

------------------------------------------------------------------------
r79796 | cevans@chromium.org | Tue Mar 29 23:08:55 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/696/src/DEPS?r1=79796&r2=79795&pathrev=79796

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 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 26 by bugdroid1@chromium.org, 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 bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 28 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Severity-High Security_Severity-High
Project Member Comment 29 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member Comment 30 by sheriffbot@chromium.org, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 31 by sheriffbot@chromium.org, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Sign in to add a comment