6 ms·

Firefox does not have a well-designed privsep model

110 points by bigato 8y ago

kev009 8y ago
As the oxidize projects continue to land this email will become more and more obsolete. There's simply no way for C++ to compete with Rust, and while there will be continued utility pledge() is pretty quaint versus memory safety.
- taborj 8y ago
  Doesn't every email explaining the current state of <insert item here> become more and more obsolete over time?
  - hundchenkatze 8y ago
    Not if <inserted item>'s state stops changing. :)
    - taborj 8y ago
      A good point
- greenhouse_gas 8y ago
  >As the oxidize projects continue to land this email will become more and more obsolete. There's simply no way for C++ to compete with Rust, Not everything is fixable with rust. JS, for one, is JIT compiled, so Rust wouldn't help much there (it's one of the reasons it's not being oxidized). "Also, Rust’s memory safety only applies to code written in Rust, but a JIT compiler also generates machine code and then jumps to it. That generated code does not benefit from rustc’s static analysis."[1] [1]. https://www.reddit.com/r/rust/comments/8ptnfr/servo_to_upgrade_its_js_engine_from_spidermonkey/e0for4h/ https://www.reddit.com/r/rust/comments/8ptnfr/servo_to_upgra...
- peterwwillis 8y ago
  > There's simply no way for C++ to compete with Rust There's no way for 8-track to compete with compact cassettes. There's no way for VHS to compete with Betamax. There's no way for C to compete with <insert any language>. Yet, against all odds, technical superiority does not always result in market dominance. Call me when there's more Rust jobs than C++ jobs, or when they're not entirely posted to Rust mailing lists.
  - adrianmonk 8y ago
    They're not talking about popularity of the language. They're talking about two particular pieces of software, and which one will be ahead of the other based on the choice of implementation language.
- yellowapple 8y ago
  "pledge() is pretty quaint versus memory safety." Compile-time memory safety does fsck all when it comes to actual runtime memory safety, especially when it comes to things like JIT compilers (which generate machine code that is not under the same guarantees as the language in which that JIT compiler was written). Put differently: Rust does not replace pledge. Pledge is a line of defense when Rust's compile-time guarantees are insufficient for whatever reason (e.g. when the program in question is generating machine code on-the-fly, like - again - with JIT compilers). Even for programs which don't generate and execute machine code during runtime, there's still the possibility for things like rustc bugs, memory corruption (whether on disk or in core, and whether caused by cosmic rays or an attacker deliberately corrupting memory through some other attack vector), etc. that are inherently immune to compiler-level defenses (whether because the compiler is the thing affected, like in the former case, or because the problem happens after the program is compiled, like in the latter case). It also doesn't do much against bugs that have little to do with memory safety (e.g. flaws in authentication/authorization checks, bad DIY crypto, etc.). Assuming you don't need other safeguards because you're writing your programs in Rust is incredibly naïve, to say the least. Don't get me wrong: Rust is a fantastic step in the right direction, and does eliminate a large swatch of real-world bugs. It ain't a silver bullet, though, and it's unwise to treat it as such.
pvg 8y ago
Oof, this is just drama-mongering, made worse by cherrypicking the grumpiest thing from the email to put in the title. Not much point bringing that drama for a re-warming here.
- sctb 8y ago
  We've updated the title from ‘Theo de Raadt on Firefox security: “all I see is lipstick on a pig”’. We'd rather use a representative phrase from the message, if someone can suggest one.
nwah1 8y ago
Would love to see an official response. Mozilla has worked hard at adding multi-process, and improving security all over the place, such as at the level of internet protocols and infrastructure. His focus on memory security is just his personal bias as a systems engineer writing in C, and this focus alone does not provide a comprehensive comparison.
- cjhopman 8y ago
  privsep isn't "memory security".
noelwelsh 8y ago
Famously outspoken developer is mildly outspoken? I am shocked!
ddtaylor 8y ago
> I doubt firefox will ever focus on security. The security mechanisms we are talking about require breaking compatibility or performance. This isn't the stuff one rearranges deck chairs for. They seem to be willing to break compatibility as illustrated by them ditching their massive library of legacy extensions. He seems to somewhat contradict himself by saying Mozilla won't do things to improve security then describes a security feature they have implemented for JIT that Chrome has yet to provide.
- jchw 8y ago
  W^X is simply the idea that code segments are either writable or executable, never both simultaneously. It does limit some attack surface area. That being said, while it'd be a welcome addition to V8, it almost definitely would come with some performance cost and a complexity increase, whereas Chrome has focused on sandboxing the JIT in such a way that gaining access to the JIT would not get you very far. So, while layered security is almost never a bad thing, I think that it's possible this trade-off is not a terrible one for Chrome security.
  - ddtaylor 8y ago
    His email starts off with this claim: > In a browser, there are 2 main security components you want: The main security advantage is privsep. The other is W^X jit. Other security effects will follow from those design choices, especially if you have privsep. For instance, the chrome privsep is nicely refined and pledge enforcements could be added. EDIT: Just to be clear I'm not arguing against DEP/W^X but simply appears he is contradicting himself.
    - jchw 8y ago
      To be more particular, though: - W^X defends against a subset of attacks that privsep defends against. - Privsep is a bigger architectural impact than W^X. The entire app, almost everything, is impacted by privsep. Only the JIT is impacted by W^X. So while it is nice that Firefox has been doing W^X, it doesn't mean they're closer to huge steps like Chrome-level privsep of processes. I hope they are, though.
jchw 8y ago
Moving a lot of critical code to a memory safe language will be a cool advantage for Firefox, performance benefits aside. That being said, I think it's easy enough to see why Chrome may have a lead given that it indeed was designed to be secure from the get-go. I hope Theo is wrong here, and that things are getting closer, but I guess time will tell.
- mtgx 8y ago
  Yes, I think rewriting Firefox core components in Rust should give Firefox an edge in some areas, but I still think Mozilla made was wrong to go with its "hybrid" approach for its multi-process architecture. Perhaps it's a win in the short-term, a win that maybe Firefox desperately needed to catch-up in performance, but they need to slowly transition away from that to a more secure model, as they start fixing other performance issues and fine-tune the browser more.
  - sp332 8y ago
    I don't know why you're getting downvoted since that's literally their roadmap. https://bugzilla.mozilla.org/show_bug.cgi?id=1432593 https://bugzilla.mozilla.org/show_bug.cgi?id=1432593 In addition to separating sites, they're breaking services out into their own processes, like moving all network access to a separate process https://bugzilla.mozilla.org/show_bug.cgi?id=1322426 https://bugzilla.mozilla.org/show_bug.cgi?id=1322426
- Caspy7 8y ago
  > I hope Theo is wrong here, and that things are getting closer, He kind of lost me when he said > I doubt firefox will ever focus on security. This just seems ridiculous. They just spent years working Firefox into a multiprocess design, in no small part for security. And the same for completely dropping the entrenched extension legacy model (thereby frustrating lots of devs and users). There are other past and current examples where Mozilla is focusing on and improving security in Firefox.
acobster 8y ago
privsep? W^X? Can someone post a link or two? :)
- pvg 8y ago
  Privilege separation and Write XOR Execute. Both have Wikipedia pages.
- faho 8y ago
  https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX: >W^X ("Write XOR Execute"; spoken as W xor X) is a security feature in operating systems and virtual machines. It is a memory protection policy whereby every page in a process's or kernel's address space may be either writable or executable, but not both. "privsep" stands for "privilege separation", which is fairly self-explanatory. See https://en.wikipedia.org/wiki/Privilege_separation https://en.wikipedia.org/wiki/Privilege_separation.
- blattimwind 8y ago
  > privsep? Have different processes / tasks do different things using different privileges. Example: parsing HTML does not require access to the file system or graphics APIs. So you could parse HTML in a process that is allowed neither. If someone exploits your HTML parser, they can't do much.
benatkin 8y ago
Chromium is an open source project, and we should treat it like one. Google paid for most of its development, but were able to pay many open source developers less because they were excited about working on an open source project (see the thread about compensation on today's Ask HN post about working for startups). Ditto for Android. Nobody should be shy about forking these projects. We don't owe Google for them, beyond what the license says. Fair is fair. If we can treat Chromium like an open source project, maybe we can retire Firefox.
- jacob019 8y ago
  Some of us love Firefox and do not want webkit hegemony, even if it is open source.
  - MBCook 8y ago
    It’s not even WebKit anymore.
  - digi_owl 8y ago
    IF that was true, then perhaps more effort should be directed towards making Gecko a drop in engine? The big "benefit" of webkit is that it is a engine without the whole "browser" thing tagging along. But the last time i poked at getting gecko to stand on its own, albeit some time ago, it involved grabbing Firefox and giving it some configure (or whatever that python thing that is masking as configure that Mozilla is using these days) options to have it barf out only Gecko.
    - genghizkhan 8y ago
      I think they're working on servo for that. It'll be able to be dropped in place of Chromium: it'll support the same API. Or so I remember.
- seba_dos1 8y ago
  Just from the usability and performance characteristics alone, I'd rather retire Chromium than Firefox.
agumonkey 8y ago
Firefox team has been making tons of effort for prolonged periods of time. I'd be extremely fond of them focusing on having a proper privsep model now.
deleted 8y ago
[deleted]
mfer 8y ago
We, the consumers, have to make trade-offs. For example, Chrome sends your browsing habits back to Google who uses that data to "personalize" other services. I think of ads when I see this. I wouldn't be surprised if using chrome caused google to get data on unreleased projects, corporate networks, and other bits leaked to them. I wonder how they use it. In any case, you trade one risk for another. Different people are going to evaluate those differently. I do like more disclosure to help people decide all around.
- MBCook 8y ago
  Consumers are not in a position to make informed choices about the security implications of the way a browser is implemented.
  - digi_owl 8y ago
    Frankly the idea of consumers making informed choice is hogwash from end to end. Either we do so on whims, or we pick whatever is in front of us because we can't go another day without. Neither allows for "informed" decisions in the sense the economics textbooks present.
    - oblio 8y ago
      Even if we study: I can only devote X hours per product while your average company has one or several full time company that know the market much better than I do and are also probably working on way to trick me, one way or another. It’s not a fair fight.
- d1zzy 8y ago
  You can always use Chromium (premade build or make your own build), get the benefits of Chrome's security without the potential tracking. Also, AFAIK Chrome doesn't send anything to Google if you disable corresponding options, I think the only thing that cannot be disabled is sending an unique installation ID when you first install it (so that they can track number of installations). Do you have some data on Chrome doing more than that which cannot be disabled from settings?
kevingadd 8y ago
Privsep is useful but I'm not sure I buy the argument that Firefox needs to go all in on it to be secure. Despite Chrome's engineering approach people still managed to privilege escalate all the way from their webassembly decoder (insecure C++) all the way to persistent root on Chromebooks, due to fundamental security engineering failures (multiple) that no amount of privilege separation could stop. More precisely limited capabilities for content processes, etc, are good but you also just need to write more secure, more stable code and Rust is a great investment towards that. I don't think Firefox needs to go all the way to Chrome's horribly slow 37-million-process-types model. The Chrome approach has significant downsides - any use of the GPU has measurable overhead which turns into higher battery usage (this is the main reason Edge uses less battery on Windows for things like video playback), and their privilege isolation turns cache hits for web content loads from <1ms to 20-60ms because of the multiple RPC trips and context switches necessary to load things out of the cache Because Security. Every decision made in Chrome probably had a reasonable security motivation but I don't think that necessarily justifies turning a page load from 0.5s to 2.0s just to protect against a hypothetical attack. DISCLAIMER: I got paid to work on Firefox and Chrome, so I have some sort of bias here

110 points by bigato 8y ago

As the oxidize projects continue to land this email will become more and more obsolete. There's simply no way for C++ to compete with Rust, and while there will be continued utility pledge() is pretty quaint versus memory safety.

taborj 8y ago
Doesn't every email explaining the current state of <insert item here> become more and more obsolete over time?
- hundchenkatze 8y ago
  Not if <inserted item>'s state stops changing. :)
  - taborj 8y ago
    A good point
greenhouse_gas 8y ago
>As the oxidize projects continue to land this email will become more and more obsolete. There's simply no way for C++ to compete with Rust, Not everything is fixable with rust. JS, for one, is JIT compiled, so Rust wouldn't help much there (it's one of the reasons it's not being oxidized). "Also, Rust’s memory safety only applies to code written in Rust, but a JIT compiler also generates machine code and then jumps to it. That generated code does not benefit from rustc’s static analysis."[1] [1]. https://www.reddit.com/r/rust/comments/8ptnfr/servo_to_upgrade_its_js_engine_from_spidermonkey/e0for4h/ https://www.reddit.com/r/rust/comments/8ptnfr/servo_to_upgra...
peterwwillis 8y ago
> There's simply no way for C++ to compete with Rust There's no way for 8-track to compete with compact cassettes. There's no way for VHS to compete with Betamax. There's no way for C to compete with <insert any language>. Yet, against all odds, technical superiority does not always result in market dominance. Call me when there's more Rust jobs than C++ jobs, or when they're not entirely posted to Rust mailing lists.
- adrianmonk 8y ago
  They're not talking about popularity of the language. They're talking about two particular pieces of software, and which one will be ahead of the other based on the choice of implementation language.
yellowapple 8y ago
"pledge() is pretty quaint versus memory safety." Compile-time memory safety does fsck all when it comes to actual runtime memory safety, especially when it comes to things like JIT compilers (which generate machine code that is not under the same guarantees as the language in which that JIT compiler was written). Put differently: Rust does not replace pledge. Pledge is a line of defense when Rust's compile-time guarantees are insufficient for whatever reason (e.g. when the program in question is generating machine code on-the-fly, like - again - with JIT compilers). Even for programs which don't generate and execute machine code during runtime, there's still the possibility for things like rustc bugs, memory corruption (whether on disk or in core, and whether caused by cosmic rays or an attacker deliberately corrupting memory through some other attack vector), etc. that are inherently immune to compiler-level defenses (whether because the compiler is the thing affected, like in the former case, or because the problem happens after the program is compiled, like in the latter case). It also doesn't do much against bugs that have little to do with memory safety (e.g. flaws in authentication/authorization checks, bad DIY crypto, etc.). Assuming you don't need other safeguards because you're writing your programs in Rust is incredibly naïve, to say the least. Don't get me wrong: Rust is a fantastic step in the right direction, and does eliminate a large swatch of real-world bugs. It ain't a silver bullet, though, and it's unwise to treat it as such.

pvg 8y ago

Oof, this is just drama-mongering, made worse by cherrypicking the grumpiest thing from the email to put in the title. Not much point bringing that drama for a re-warming here.

sctb 8y ago
We've updated the title from ‘Theo de Raadt on Firefox security: “all I see is lipstick on a pig”’. We'd rather use a representative phrase from the message, if someone can suggest one.

nwah1 8y ago

Would love to see an official response. Mozilla has worked hard at adding multi-process, and improving security all over the place, such as at the level of internet protocols and infrastructure. His focus on memory security is just his personal bias as a systems engineer writing in C, and this focus alone does not provide a comprehensive comparison.

cjhopman 8y ago
privsep isn't "memory security".

noelwelsh 8y ago

Famously outspoken developer is mildly outspoken? I am shocked!

ddtaylor 8y ago

> I doubt firefox will ever focus on security. The security mechanisms we are talking about require breaking compatibility or performance. This isn't the stuff one rearranges deck chairs for. They seem to be willing to break compatibility as illustrated by them ditching their massive library of legacy extensions. He seems to somewhat contradict himself by saying Mozilla won't do things to improve security then describes a security feature they have implemented for JIT that Chrome has yet to provide.

jchw 8y ago
W^X is simply the idea that code segments are either writable or executable, never both simultaneously. It does limit some attack surface area. That being said, while it'd be a welcome addition to V8, it almost definitely would come with some performance cost and a complexity increase, whereas Chrome has focused on sandboxing the JIT in such a way that gaining access to the JIT would not get you very far. So, while layered security is almost never a bad thing, I think that it's possible this trade-off is not a terrible one for Chrome security.
- ddtaylor 8y ago
  His email starts off with this claim: > In a browser, there are 2 main security components you want: The main security advantage is privsep. The other is W^X jit. Other security effects will follow from those design choices, especially if you have privsep. For instance, the chrome privsep is nicely refined and pledge enforcements could be added. EDIT: Just to be clear I'm not arguing against DEP/W^X but simply appears he is contradicting himself.
  - jchw 8y ago
    To be more particular, though: - W^X defends against a subset of attacks that privsep defends against. - Privsep is a bigger architectural impact than W^X. The entire app, almost everything, is impacted by privsep. Only the JIT is impacted by W^X. So while it is nice that Firefox has been doing W^X, it doesn't mean they're closer to huge steps like Chrome-level privsep of processes. I hope they are, though.

jchw 8y ago

Moving a lot of critical code to a memory safe language will be a cool advantage for Firefox, performance benefits aside. That being said, I think it's easy enough to see why Chrome may have a lead given that it indeed was designed to be secure from the get-go. I hope Theo is wrong here, and that things are getting closer, but I guess time will tell.

mtgx 8y ago
Yes, I think rewriting Firefox core components in Rust should give Firefox an edge in some areas, but I still think Mozilla made was wrong to go with its "hybrid" approach for its multi-process architecture. Perhaps it's a win in the short-term, a win that maybe Firefox desperately needed to catch-up in performance, but they need to slowly transition away from that to a more secure model, as they start fixing other performance issues and fine-tune the browser more.
- sp332 8y ago
  I don't know why you're getting downvoted since that's literally their roadmap. https://bugzilla.mozilla.org/show_bug.cgi?id=1432593 https://bugzilla.mozilla.org/show_bug.cgi?id=1432593 In addition to separating sites, they're breaking services out into their own processes, like moving all network access to a separate process https://bugzilla.mozilla.org/show_bug.cgi?id=1322426 https://bugzilla.mozilla.org/show_bug.cgi?id=1322426
Caspy7 8y ago
> I hope Theo is wrong here, and that things are getting closer, He kind of lost me when he said > I doubt firefox will ever focus on security. This just seems ridiculous. They just spent years working Firefox into a multiprocess design, in no small part for security. And the same for completely dropping the entrenched extension legacy model (thereby frustrating lots of devs and users). There are other past and current examples where Mozilla is focusing on and improving security in Firefox.

acobster 8y ago

privsep? W^X? Can someone post a link or two? :)

pvg 8y ago
Privilege separation and Write XOR Execute. Both have Wikipedia pages.
faho 8y ago
https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX: >W^X ("Write XOR Execute"; spoken as W xor X) is a security feature in operating systems and virtual machines. It is a memory protection policy whereby every page in a process's or kernel's address space may be either writable or executable, but not both. "privsep" stands for "privilege separation", which is fairly self-explanatory. See https://en.wikipedia.org/wiki/Privilege_separation https://en.wikipedia.org/wiki/Privilege_separation.
blattimwind 8y ago
> privsep? Have different processes / tasks do different things using different privileges. Example: parsing HTML does not require access to the file system or graphics APIs. So you could parse HTML in a process that is allowed neither. If someone exploits your HTML parser, they can't do much.

benatkin 8y ago

Chromium is an open source project, and we should treat it like one. Google paid for most of its development, but were able to pay many open source developers less because they were excited about working on an open source project (see the thread about compensation on today's Ask HN post about working for startups). Ditto for Android. Nobody should be shy about forking these projects. We don't owe Google for them, beyond what the license says. Fair is fair. If we can treat Chromium like an open source project, maybe we can retire Firefox.

jacob019 8y ago
Some of us love Firefox and do not want webkit hegemony, even if it is open source.
- MBCook 8y ago
  It’s not even WebKit anymore.
- digi_owl 8y ago
  IF that was true, then perhaps more effort should be directed towards making Gecko a drop in engine? The big "benefit" of webkit is that it is a engine without the whole "browser" thing tagging along. But the last time i poked at getting gecko to stand on its own, albeit some time ago, it involved grabbing Firefox and giving it some configure (or whatever that python thing that is masking as configure that Mozilla is using these days) options to have it barf out only Gecko.
  - genghizkhan 8y ago
    I think they're working on servo for that. It'll be able to be dropped in place of Chromium: it'll support the same API. Or so I remember.
seba_dos1 8y ago
Just from the usability and performance characteristics alone, I'd rather retire Chromium than Firefox.

agumonkey 8y ago

Firefox team has been making tons of effort for prolonged periods of time. I'd be extremely fond of them focusing on having a proper privsep model now.

deleted 8y ago

[deleted]

mfer 8y ago

We, the consumers, have to make trade-offs. For example, Chrome sends your browsing habits back to Google who uses that data to "personalize" other services. I think of ads when I see this. I wouldn't be surprised if using chrome caused google to get data on unreleased projects, corporate networks, and other bits leaked to them. I wonder how they use it. In any case, you trade one risk for another. Different people are going to evaluate those differently. I do like more disclosure to help people decide all around.

MBCook 8y ago
Consumers are not in a position to make informed choices about the security implications of the way a browser is implemented.
- digi_owl 8y ago
  Frankly the idea of consumers making informed choice is hogwash from end to end. Either we do so on whims, or we pick whatever is in front of us because we can't go another day without. Neither allows for "informed" decisions in the sense the economics textbooks present.
  - oblio 8y ago
    Even if we study: I can only devote X hours per product while your average company has one or several full time company that know the market much better than I do and are also probably working on way to trick me, one way or another. It’s not a fair fight.
d1zzy 8y ago
You can always use Chromium (premade build or make your own build), get the benefits of Chrome's security without the potential tracking. Also, AFAIK Chrome doesn't send anything to Google if you disable corresponding options, I think the only thing that cannot be disabled is sending an unique installation ID when you first install it (so that they can track number of installations). Do you have some data on Chrome doing more than that which cannot be disabled from settings?

kevingadd 8y ago

Privsep is useful but I'm not sure I buy the argument that Firefox needs to go all in on it to be secure. Despite Chrome's engineering approach people still managed to privilege escalate all the way from their webassembly decoder (insecure C++) all the way to persistent root on Chromebooks, due to fundamental security engineering failures (multiple) that no amount of privilege separation could stop. More precisely limited capabilities for content processes, etc, are good but you also just need to write more secure, more stable code and Rust is a great investment towards that. I don't think Firefox needs to go all the way to Chrome's horribly slow 37-million-process-types model. The Chrome approach has significant downsides - any use of the GPU has measurable overhead which turns into higher battery usage (this is the main reason Edge uses less battery on Windows for things like video playback), and their privilege isolation turns cache hits for web content loads from <1ms to 20-60ms because of the multiple RPC trips and context switches necessary to load things out of the cache Because Security. Every decision made in Chrome probably had a reasonable security motivation but I don't think that necessarily justifies turning a page load from 0.5s to 2.0s just to protect against a hypothetical attack. DISCLAIMER: I got paid to work on Firefox and Chrome, so I have some sort of bias here