Electrolysis security
Lucas Adamski
As part of Electrolysis development, we need to consider the security
implications of the architecture we are implementing. Even though
security per se is not an explicit goal at this point (phase 2) of the
project, the risk remains that we could actually introduce a number of
security issues while refactoring the code into separate processes.
Some areas of risk that come to mind:
1) separating atomic security checks across IPC boundaries could
introduce security bugs from security checks failing due to
a) race conditions (ex. redirect could happen while a related
security check happens on the other side of the IPC boundary)
b) context sync issues (ex. redirects notifications may not be
propagated across IPC)
c) plugins/NPAPI may have odd behavior when in a separate process
from chrome
2) security foundation for process isolation / low rights
a) routing all network access through parent process
b) how/when can remote tabs access cookies, password manager,
certificate information, file system access for file upload/download
c) avoiding proxies for the above - don't have a generic process in
the parent process that just passes through all requests from remote
processes
d) preventing impersonation of chrome dialogs by a remote process
(to the degree feasible)
e) cache - who determines origin of documents, who writes to cache?
A larger threat model is located at https://wiki.mozilla.org/Security/ProcessIsolation/ThreatModel
. Though it is focused on security improvements from process
isolation, it should still provide useful information for laying the
foundation for future phases.
The goal is to start a discussion around the security implications of
electrolysis so please chime in, even if its with general
skepticism. :) Thanks,
Lucas.
Jean-Marc Desperrier
> As part of Electrolysis development, we need to consider the security
> implications of the architecture we are implementing.
Cool.
Are you considering tackling the subject of modal dialog boxes also ?
(which can be seen as security related also)
If each tab is a separate process, it will probably be hard to make
modal dialog box continue to block the whole application as they do now.
But IMO it's the current behavior that's bad, modal dialog box should be
modal *per tab*, and there should just be some way of signaling a tab
requires attention.
So if would be great if Electrolysis would be the occasion of enhancing
that behavior and remove application modal dialog boxes in favor of tab
modal dialog boxes.
Benjamin Smedberg
> Are you considering tackling the subject of modal dialog boxes also ?
> (which can be seen as security related also)
No, at least not initially. The goal is to keep our current behavior as much
as possible.
> If each tab is a separate process, it will probably be hard to make
> modal dialog box continue to block the whole application as they do now.
The chrome process will be responsible for posing prompts in this phase.
> But IMO it's the current behavior that's bad, modal dialog box should be
> modal *per tab*, and there should just be some way of signaling a tab
> requires attention.
Sure, but that's something you could fix without having multiple process and
is only tangentially related. It would also require some serious UI design,
because the standard modal window doesn't make sense: you'd probably want to
present the popup within the tab itself.
--BDS
Lucas Adamski
love to read up some more on it, as I haven't haven't found too many
conclusive references on the risks/implications of passing file
handles, esp. among processes of dramatically different privilege
levels (other than kernel -> userland, which is where we've actually
seen bugs with stdin/stdout/stderr).
Regarding the point below, I said there it would reduce platform-
specific code in the content process, which means we don't end up with
multiple copies of that around. Regarding context switching, we are
already serializing so much stuff across IPC (pretty much all security
sensitive stuff EXCEPT file access) that serializing file uploads will
not have a significant impact. It would remove a lot of potentially
tricky platform-specific code from the content process which is a good
thing.
In some respects I feel like we're trying to address the same problem
from different angles. From a defense-in-depth standpoint, we want to
prevent access to natives files, sockets, libraries, and other
sensitive resources by content processes except where explicitly
permitted by the chrome process. Since the proposed model involves
passing native file handles/descriptors, it requires the content
process to have access to all of the usual file I/O libraries and
prevents us from trying to whole-sale break those, and rely instead on
ensuring that content processes can't load anything by direct or
indirect references, can't import libraries that would allow them to
do so, etc. Now it may not be possible to disable these wholesale
because, as Zack mentioned, a bunch of libc assumes access to certain
public files. But its a worthy goal. :)
My take-away from the chrome security model is that identifying and
patching the various libraries to prohibit access to bad stuff is a
painful game of whack-a-mole.
Lucas.
On Aug 20, 2009, at 10:46 PM, Rob Arnold wrote:
> On Thu, Aug 20, 2009 at 4:40 PM, Lucas Adamski <lu...@mozilla.com>
> wrote:
>
> I'm not too familiar with file descriptor security issues (as that's
> generally a domain of local elevation of privilege exploits and
> traditionally more of an OS-security problem), but it seems like we
> have a few area of concern here:
>
> a) file descriptors have been at the root (no pun intended) of
> several local escalation of privilege vulnerabilities, such as:
> http://www.net-security.org/advisory.php?id=2593
> http://www.securiteam.com/unixfocus/5SP0N157FK.html
> http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2007-01/msg00344.html
>
> These are all unix file descriptors - NT uses a common object
> manager for checking permissions and ensuring the validity of
> handles to operating system objects. I'm not saying that there are
> no security holes, but given that the code path is used quite
> frequently (moreso than unix file descriptors), I would be surprised
> if there are still OS level issues that cannot be solved by more
> careful application-level checks (ex: sharing access to symlinks).
>
> b) file descriptors can be implemented differently on different
> platforms; exposing it directly means we give up control and are at
> the mercy of platform implementations (and I'm not sure how we'd
> even do that on Windows). There has been enough recent work around
> properly securing file descriptors to make me pretty nervous:
> http://udrepper.livejournal.com/20407.html (I don't think his
> browser and plugin example is super relevant but the point is file
> descriptors are tricky from a security standpoint)
> http://www.nsa.gov/research/_files/selinux/papers/module/x92.shtml#FDPERMSCHANGES
>
> I'm not a fan of reinventing the wheel. Again, for what it's worth,
> those papers deal with unix file descriptors which operate
> differently that Windows handles. We may need to take separate
> approaches (what does Chrome do?).
>
> I suggest that you read up on the Windows file APIs/kernel design -
> it's quite informative. Files are a type of Executive (kernel if you
> will) objects. Processes access objects through handles - each
> process has its own handle table. Handles can be duplicated (similar
> to dup) with a different set of permissions from one process to
> another (including itself). A child process can also inherit its
> parents handles if both of the following apply:
> a) the handle is marked as inheritable (most code defaults to false
> here, including ours)
> b) The child process is created with a flag that says it gets to
> inherit handles.
>
> We would most likely be using the first method (DAC), opening the
> file in the content process as readonly, then duplicating the handle
> to the child, stripping all rights except for reading (the child
> process can close the handle, but the object is refcounted in the
> kernel).
>
> I don't know how you'd perform that on unix-based systems but in the
> event we cannot, we shouldn't penalize performance on the OS with
> the largest Firefox marketshare to workaround those limitations.
>
> c) defense-in-depth and minimizing privilege: we should not expose
> low-level OS primitives to content processes where avoidable; in
> particular for filesystem access where paranoia is advisable. In
> particular I'm not clear on how a process could receive permission
> to access a specific file without also exposing the rest of the OS
> to attack either directly or via low-level disk writes. Given one
> of the primary goals of electrolysis security is to protect the
> filesystem from remote content we shouldn't over-optimize here.
>
> It's not clear to me how an operating system can let a process use a
> file descriptor to a file to scribble over or read from the entire
> disk and claim to be stable/secure - we should not support such
> systems.
>
> On Windows, it is not possible to perform low level disk writes
> without being an Administrator - a UAC prompt may even be involved.
>
> I'm not sure how we would consider denial of service attacks via
> disk I/O from the content process - do you know of any papers on this?
>
> Since we are serializing graphics constantly it seems like a minimal
> performance hit to serialize all file I/O as well. Doing so will
> reduce platform-specific code in the content process, provide
> significant defense in depth and might even provide performance and
> stability benefits (since the chrome process will be in a better
> position to clean up any open files and other resources left behind
> a crashed content process).
>
> Giving the child process a native file descriptor lets us avoid
> excessive context switching and context switches are not cheap. I
> don't see how there's a reduction in platform specific code - it's
> either in the content process or the master process. This
> indirection will actually add more code. Why not let the OS do it's
> job? I'm not convinced that we should try to rewrite the wheel when
> there are existing solutions to this problem.
>
> At minimum it seems
> to invite escalation of privilege attacks. A better model might be
> for the broker process to handle the file I/O on behalf of the
> content process using a randomly generated file reference that is not
> an underlying file descriptor; something strongly coupled to that
> particular content process (to prevent rogue processes from trying to
> brute force other file references).
>
> This doesn't make a whole lot of sense to me given that file
> descriptors are meaningful only in the context of a particular
> process.
> You can't brute force them.
>
>
> If we serialize all file I/O we will need to provide some sort of
> file ID back to the content process; my point is that ID should be
> tied to the content process and not brute-forceable.
>
> If we go that route, then yes. Why not mimic what the OS does for
> file descriptor numbers or process ids? OpenBSD is particularly
> paranoid and uses a secure random numbe
>
> -Rob
Benjamin Smedberg
To clarify a few things:
I have been using "file descriptor" loosely. On Windows I mean a HANDLE, and
on *nixy systems an actual file descriptor. (On Windows a POSIX file
descriptor is a wrapper around a HANDLE).
> a) file descriptors have been at the root (no pun intended) of several
> local escalation of privilege vulnerabilities, such as:
> http://www.net-security.org/advisory.php?id=2593
> http://www.securiteam.com/unixfocus/5SP0N157FK.html
> http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2007-01/msg00344.html
File descriptors are a core part of OS operation. The IPC mechanism works at
all by opening a socketpair file descriptor in the parent process and
sending that to the child process, and then file descriptors for additional
sockets/pipes/anonymous memory mappings are duplicated to the child process
so that it can communicate with the parent.
I'm not sure that we should, or can, try to guard against this style of OS
security breach.
> that on Windows). There has been enough recent work around properly
> securing file descriptors to make me pretty nervous:
> http://udrepper.livejournal.com/20407.html (I don't think his browser
> and plugin example is super relevant but the point is file descriptors
> are tricky from a security standpoint)
We do have to guard against unintended file descriptors being available to
the child process, but that's beside the point of whether we intentionally
grant the child process access to files by duplicating a fd/handle to it.
The child process doesn't fork additional processes, so there is not a
chance of it leaking fds to other processes.
> c) defense-in-depth and minimizing privilege: we should not expose
> low-level OS primitives to content processes where avoidable; in
> particular for filesystem access where paranoia is advisable. In
> particular I'm not clear on how a process could receive permission to
> access a specific file without also exposing the rest of the OS to
> attack either directly or via low-level disk writes. Given one of the
> primary goals of electrolysis security is to protect the filesystem from
> remote content we shouldn't over-optimize here.
How not? On Windows, access checks are performed at the time you create/open
a HANDLE. So to grant access to a specific file, the chrome process creates
the handle with appropriate permissions (readonly access) and then
duplicates that handle to the child process.
The same basic mechanism is used on Linux/Mac with unix domain sockets.
> Since we are serializing graphics constantly it seems like a minimal
> performance hit to serialize all file I/O as well. Doing so will reduce
> platform-specific code in the content process, provide significant
> defense in depth and might even provide performance and stability
> benefits (since the chrome process will be in a better position to clean
> up any open files and other resources left behind a crashed content
> process).
We are not going to "serialize graphics constantly". We are going to use
anonymous mapped memory (based on file descriptors or handles) to ship large
network and graphics data between processes. Granting access to specific
other handles isn't going to be more risky.
Since the file handle is managed by the OS, a crashed process won't hold a
file open.
>>> At minimum it seems
>>> to invite escalation of privilege attacks. A better model might be
>>> for the broker process to handle the file I/O on behalf of the
>>> content process using a randomly generated file reference that is not
>>> an underlying file descriptor; something strongly coupled to that
>>> particular content process (to prevent rogue processes from trying to
>>> brute force other file references).
>>
>> This doesn't make a whole lot of sense to me given that file
>> descriptors are meaningful only in the context of a particular process.
>> You can't brute force them.
>>
>
> If we serialize all file I/O we will need to provide some sort of file
> ID back to the content process; my point is that ID should be tied to
> the content process and not brute-forceable.
What ID? You mean like the actor ID of the messages going back and forth?
Those are just integers assigned to particular message endpoints. I don't
see how that's any more or less random/guessable than a handle or file
descriptor. And the guessability shouldn't matter anyway, since you're only
"leaking" information that you're already intentionally granting to the process.
--BDS
Lucas Adamski
PST today as part of the platform work week.