Re: Electrolysis security

On Thu, Aug 20, 2009 at 4:40 PM, Lucas Adamski <[email protected]> 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