Re: [dev-servo] State of Servo

[Ian Melven]

Hi,

just joined the list and making a small note in reply to this thread : 

On Wednesday, June 27, 2012 7:19:13 PM UTC-7, Boris Zbarsky wrote:
> On 6/27/12 6:49 PM, Robert O'Callahan wrote:
>>   and CSP can't actually dynamically change the origin of a
>> document, can they? If they can we'd better fix that before it's too late
>> :-).

> The proposal to do sandboxing via CSP and the fact that you can put your 
> CSP into a  tag mean that you can in fact dynamically change the 
> origin of a document, from whatever origin it had to a null principal, 
> when said  tag is parsed.  Devdatta is implementing that right now...

> I do think it's somewhat daft, but people really want to do sandboxing 
> via CSP

the current thinking after discussion with Dev and Dan Veditz
is that sandboxing via CSP in a  tag won't be allowed.

Ian Hickson has also stated the spec actually implies this, since it says that 
any changes to sandboxing
only take effect on the next navigation, making sandboxing in  CSP a nop.

There's also some concerns about CSP via  in general since an injections 
means
an attacker can affect the behavior of a page in unexpected ways if they can 
inject
a new CSP (modulo the restrictions imposed by the intersection logic)

Also, in general, i'm pretty curious about Servo's process model and its 
security architecture,
maybe that's best discussed in a new thread though (I really need to take some 
time
to understand Rust better as well). My particular interest is in how Servo 
relates to the process sandboxing project I'm working on and
any ideas around what Servo's possible addon model might be - 
Servo is often proposed as a solution to the needs driving the sandboxing 
project but it seems
there will still be unsafe, possibly exploitable code in certain parts of it. 

thanks,
ian









___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] State of Servo

[Patrick Walton]

On 7/11/12 10:09 AM, Ian Melven wrote:

Also, in general, i'm pretty curious about Servo's process model and its 
security architecture,
maybe that's best discussed in a new thread though (I really need to take some 
time
to understand Rust better as well). My particular interest is in how Servo 
relates to the process sandboxing project I'm working on and
any ideas around what Servo's possible addon model might be -
Servo is often proposed as a solution to the needs driving the sandboxing 
project but it seems
there will still be unsafe, possibly exploitable code in certain parts of it.


The memory safety and type safety of Rust isn't a substitute for a 
sandbox. Even with memory safety, it's still possible for someone to 
call os::exec("calc.exe"). And it's still potentially possible to 
exploit kernel32.dll, user32.dll, d3d9.dll, etc.


So we will need to use a sandbox. I think this sandboxing code should be 
part of the Rust cargo ecosystem, so that Rust programs can generally 
use it and the Rust community can contribute to it.


That said, memory safety definitely helps security in a big way. I think 
of memory safety and type safety as just one particularly powerful layer 
of protection. Just like any security layer, it rules out many sources 
of exploits, but other layers of protection are needed.


Patrick
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] State of Servo

[Brendan Eich]

Patrick Walton wrote:

On 7/11/12 10:09 AM, Ian Melven wrote:
Also, in general, i'm pretty curious about Servo's process model and 
its security architecture,
maybe that's best discussed in a new thread though (I really need to 
take some time
to understand Rust better as well). My particular interest is in how 
Servo relates to the process sandboxing project I'm working on and

any ideas around what Servo's possible addon model might be -
Servo is often proposed as a solution to the needs driving the 
sandboxing project but it seems
there will still be unsafe, possibly exploitable code in certain 
parts of it.


The memory safety and type safety of Rust isn't a substitute for a 
sandbox. Even with memory safety, it's still possible for someone to 
call os::exec("calc.exe"). And it's still potentially possible to 
exploit kernel32.dll, user32.dll, d3d9.dll, etc.


So we will need to use a sandbox. I think this sandboxing code should 
be part of the Rust cargo ecosystem, so that Rust programs can 
generally use it and the Rust community can contribute to it.


That said, memory safety definitely helps security in a big way. I 
think of memory safety and type safety as just one particularly 
powerful layer of protection. Just like any security layer, it rules 
out many sources of exploits, but other layers of protection are needed.


Agreed, memory and type safety are big wins. But based on experience 
with browsers, Java VMs, and the like, we probably need more.


The safety property called Control Flow Integrity [1] can be enforced 
separately from Memory Safety, and it looks like useful belt-and-braces 
on top of a memory-safe language and runtime due to inevitable low-level 
bugs. CFI involves static code analysis and residual runtime checks to 
ensure that all control flow transfers go where they should and nowhere 
else.


The hard cases are calls and returns, especially virtual calls, since 
Intel's lovely variable-length instructions enable ROP exploits.


Google Native Client [2] is a leading CFI-enforcing compiler and runtime 
system. Anyone know of better? MSR had Xax [3] but it seems defunct.


I noticed https://github.com/mozilla/servo/issues/23 ("Explore ways of 
integrating NaCl") get filed the other week. The main problem for NaCl 
adoption (by any app other than Chrome and OS other than ChromeOS) is 
its runtime API set, Pepper, which is large and unspecified -- rather, 
implemented by a pile of chromium.org code. Pepper includes lots of 
browser (WebKit + chromium) and OS abstraction, so it won't "port" to 
Rust and Servo easily.


With NaCl, you theoretically can do without process isolation and rely 
on the CFI enforcement, but last I checked, NaCl and Pepper in Chrome 
still used process isolation in addition.


Unsafe native code is one issue, but bugs in the smaller TCB of the Rust 
compiler and runtime that compromise CFI could still be exploited, fully 
in our experience in Firefox and other Gecko/SpiderMonkey-based apps.


So I wonder whether, independent of what we do about enforcing CFI in 
unsafe native code linked into Servo, we'll want to enforce CFI in the 
Rust compiler and runtime. I don't think anyone has had time to look 
into this, but it seems like a good research project.


/be

[1] http://research.microsoft.com/apps/pubs/default.aspx?id=64250
[2] http://code.google.com/p/nativeclient/
[3] http://research.microsoft.com/pubs/72878/xax-osdi08.pdf
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] State of Servo

[Robert O'Callahan]

On Thu, Jul 12, 2012 at 7:08 AM, Brendan Eich  wrote:

> Unsafe native code is one issue, but bugs in the smaller TCB of the Rust
> compiler and runtime that compromise CFI could still be exploited, fully in
> our experience in Firefox and other Gecko/SpiderMonkey-based apps.
>
> So I wonder whether, independent of what we do about enforcing CFI in
> unsafe native code linked into Servo, we'll want to enforce CFI in the Rust
> compiler and runtime. I don't think anyone has had time to look into this,
> but it seems like a good research project.
>

Many interesting options have been explored, such as certifying
compilation, where the compiler generates along with the object code a
proof that the safety properties of the source language have been preserved
by that run of the compiler. That proof can be typically be verified by a
very simple proof-checker. I suspect doing this for the Javascript
compiler, where the attacker controls the input source code, would be more
important than for the Rust compiler, where the attacker doesn't control
the input source code so they only get to try to exploit Rust compiler bugs
that were actually triggered during a particular Servo build.

I don't think adding levels of sandboxing or verification to Servo will be
important anytime soon, though. Those are orthogonal problems that are only
worth solving once we have a browser engine worth defending, and can be
readily solved at that point.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] State of Servo

[Brendan Eich]

Robert O'Callahan wrote:
On Thu, Jul 12, 2012 at 7:08 AM, Brendan Eich > wrote:


Unsafe native code is one issue, but bugs in the smaller TCB of
the Rust compiler and runtime that compromise CFI could still be
exploited, fully in our experience in Firefox and other
Gecko/SpiderMonkey-based apps.

So I wonder whether, independent of what we do about enforcing CFI
in unsafe native code linked into Servo, we'll want to enforce CFI
in the Rust compiler and runtime. I don't think anyone has had
time to look into this, but it seems like a good research project.


Many interesting options have been explored, such as certifying 
compilation, where the compiler generates along with the object code a 
proof that the safety properties of the source language have been 
preserved by that run of the compiler. That proof can be typically be 
verified by a very simple proof-checker. I suspect doing this for the 
Javascript compiler, where the attacker controls the input source 
code, would be more important than for the Rust compiler, where the 
attacker doesn't control the input source code so they only get to try 
to exploit Rust compiler bugs that were actually triggered during a 
particular Servo build.


I'm more concerned about runtime bugs -- the usual free memory read 
during a virtual call. Rust will have vtbls, IIRC, and it takes only one 
rooting or refcounting bug to enable an attacker to reclaim the live 
object's vtbl. At least, this has been the bane of browsers' existence 
for over seven years.


I don't think adding levels of sandboxing or verification to Servo 
will be important anytime soon, though. Those are orthogonal problems 
that are only worth solving once we have a browser engine worth 
defending, and can be readily solved at that point.


The topic already came up, and the NaCl issue was filed. I honestly 
don't know when we should get into this level of Servo security, but 
"adding Security later" is an anti-pattern. I don't believe we can use 
NaCl targeting Pepper in Servo, for instance. Seems worth a discussion 
up front, even if we defer.


/be
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] State of Servo

[Robert O'Callahan]

On Thu, Jul 12, 2012 at 4:44 PM, Brendan Eich  wrote:

> I'm more concerned about runtime bugs -- the usual free memory read during
> a virtual call. Rust will have vtbls, IIRC, and it takes only one rooting
> or refcounting bug to enable an attacker to reclaim the live object's vtbl.
> At least, this has been the bane of browsers' existence for over seven
> years.


That's fair. In Midori Microsoft formally verified the GC, but CFI may have
better cost/benefit. (Lower benefit, lower or at least different costs.)


>  I don't think adding levels of sandboxing or verification to Servo will
>> be important anytime soon, though. Those are orthogonal problems that are
>> only worth solving once we have a browser engine worth defending, and can
>> be readily solved at that point.
>>
>
> The topic already came up, and the NaCl issue was filed. I honestly don't
> know when we should get into this level of Servo security, but "adding
> Security later" is an anti-pattern. I don't believe we can use NaCl
> targeting Pepper in Servo, for instance. Seems worth a discussion up front,
> even if we defer.
>

You could use NaCl without the Pepper baggage.

Is there any reason to believe that a CFI scheme for C++ could fail to work
for Rust?

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] State of Servo

[Brendan Eich]

Brendan Eich wrote:
Google Native Client [2] is a leading CFI-enforcing compiler and 
runtime system. Anyone know of better? MSR had Xax [3] but it seems 
defunct.


devd (Devdatta Akhawe, whom I had not met yet) on #developers corrected 
me: NaCl does SFI, not CFI. SFI goes way back,


R. Wahbe, S. Lucco, T. Anderson, and S. Graham. Efficient
software-based fault isolation. ACM SIGOPS Operating
Systems Review, 27(5):203–216, 1993.

The CFI and NaCl papers have all the refs.

SFI is for securing arbitrary native code. Hence brson's bug, but the 
Pepper mismatch is a problem, and the overhead for IA64 and ARM, even 
ignoring PNaCl, is no picnic.


CFI could be done more cheaply in a managed language like Rust, maybe.

/be
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] State of Servo

[Brendan Eich]

Robert O'Callahan wrote:
On Thu, Jul 12, 2012 at 4:44 PM, Brendan Eich > wrote:


I'm more concerned about runtime bugs -- the usual free memory
read during a virtual call. Rust will have vtbls, IIRC, and it
takes only one rooting or refcounting bug to enable an attacker to
reclaim the live object's vtbl.



Really, reclaim the "live" object and pun its vtbl. In JS before Data 
Execute Protection (to use Windows jargon) you could even use a JS 
string allocation to do this, where the string chars contained x86 insns.



At least, this has been the bane of browsers' existence for over
seven years.


That's fair. In Midori Microsoft formally verified the GC, but CFI may 
have better cost/benefit. (Lower benefit, lower or at least different 
costs.)

I suspect so, unless someone has a verification plan for Rust's GC ;-).


You could use NaCl without the Pepper baggage.


How does this work? NaCl has its own libc and all the usual. I haven't 
had time to play with it, but in a browser instead of Unix system calls, 
it bottoms out in Pepper.


Is there any reason to believe that a CFI scheme for C++ could fail to 
work for Rust?




None that I know of. There could be subtleties.

I'm stirring the pot mainly in case there's interesting research-intern 
work here (sounds like there may be! I didn't know devd till tonight), 
and to scout ahead a bit. No rush, though.


/be
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo