4 ms·

My complaint about browsers is less about architecture (I mean, when using multiple processes is a vast improvement of the state of the art on the ground...), t

by hga 11y ago

My complaint about browsers is less about architecture (I mean, when using multiple processes is a vast improvement of the state of the art on the ground...), than what I gather is the vast amount of work required to get today's standard web pages to render well. There are, what, 4 state of the art rendering engines? (Two Microsoft, which has lots of money to spend, Webkit (now Apple and Google forked??), and Firefox's.) And there's much, much more to the security story for browsers. Then again, this is not a topic I've looked closely at, maybe there's more hope than I think, and continuing financial losses might prompt more rigor, although I don't recall the worse ones being purely browser exploits.

nickpsecurity 11y ago
Oh I see what you mean. Yes, it's become an oligopoly with a huge barrier to entry. The typical solution is to separate all these components with safer implementations, isolation, and/or interfaces. What I referenced do those. If you want to solve it directly, you have to make the code trustworthy. That's... another matter entirely. There are a few approaches to this. One is to apply compiler transformations that make the code memory-safe along with interface checks at sys-call level. An example is Softbound+CETS albeit I'm not saying it's worked on a browser. Several have compiled C programs to run in a Java or other managed environment. Another example is a lighter security approach called control flow integrity where you just try to block code injections with data or pointer protection. Control Pointer Integrity is most interesting right now with several HW accelerators. The next approach is using software or hardware obfuscation to make it where the incoming attack (a) wouldn't hit its target or (b) would be mangled/detected by crypto work at HW level. This has been ported to Linux. CheriBSD is another, DARPA-funded effort that uses custom hardware (CHERI) and tooling to let you incrementally protect legacy stuff with capabilities. So, quite a few ways to deal with it. As usual, the problem is that our machines and languages make it easy to cause a vulnerability with common, fundamental operations. Making those operations fundamentally safe[r] knocks out a lot of that risk. Traditional techniques, like separation kernels, can try to isolate and detect the rest. That's my take on how to deal with being stuck with codebases like Webkit. Still work but feels less impossible.
- hga 11y ago
  A few more thoughts, without having looked at your references or even having more than a vague idea of the (necessary) architecture of browsers (it's fiddly front end stuff I don't like all that much as a domain), and for that matter at this point I'm just looking at all this because I don't like how things are, how they've developed since Multics and the Lisp Machine (the latter, admittedly not a secure system), and looking for what to try to do next with my life: A lot of what you suggest for directly solving it strike me as hacks not to my taste, but I'll look harder at that sort of thing in the future. Absent that: If you're going to modularize it, the interfaces are going to be complex and error prone, in part what I view as the difference between relatively easier to trust ciphers such as AES and much more fragile cryptosystems/cryptographic protocols (the one bit of real research I've done here was in 1979, trying to design an public key based authentication server; no success then, I gather it took half a decade to get to the not obviously broken stage). It's got to be fast; for now, ever faster as web pages get more and more complicated. Although one cause of that, calling out to zillions of different sources, admits to speed ups if you can incrementally/concurrently deal with the bits as you get them ... which of course makes the system more complicated. (There's probably a space for a browser distribution that thoroughly pretends to be from a mobile source and gets those simpler pages. :-) Firefox/Mozilla may be in the process of killing itself, worsening the oligopoly: Objectively, I hear they're dramatically losing market share AKA $$$ for further development. Related to that, poor organizational management. I heard on HN that they're preparing to move to a multiprocess architecture which will nuke their extension ecosystem, which is one of their core advantages. This is one of those nasty security-usability tradeoffs, or at least probably due to some of the above resource and organizational issues, plus perhaps security issues, the API presented to extensions won't allow them to do much. Chrome of course has this "problem". I guess what I'll personally do is concentrate on the lower level, tentatively starting with an Raspberry Pi seL4 port (I know, stop laughing, it's the most stable (long life promise) and widely available ARM platform for learning), wait to see how Servo plays out (see above Mozilla problems), and then return to this, maybe it's less "impossible" than I sense right now. Although still plenty impossible in the approaches my taste prefers that can't be used for the foreseeable future. Thanks a lot for your contributions to all these HN security discussions!

by hga 11y ago

nickpsecurity 11y ago

Oh I see what you mean. Yes, it's become an oligopoly with a huge barrier to entry. The typical solution is to separate all these components with safer implementations, isolation, and/or interfaces. What I referenced do those. If you want to solve it directly, you have to make the code trustworthy. That's... another matter entirely. There are a few approaches to this. One is to apply compiler transformations that make the code memory-safe along with interface checks at sys-call level. An example is Softbound+CETS albeit I'm not saying it's worked on a browser. Several have compiled C programs to run in a Java or other managed environment. Another example is a lighter security approach called control flow integrity where you just try to block code injections with data or pointer protection. Control Pointer Integrity is most interesting right now with several HW accelerators. The next approach is using software or hardware obfuscation to make it where the incoming attack (a) wouldn't hit its target or (b) would be mangled/detected by crypto work at HW level. This has been ported to Linux. CheriBSD is another, DARPA-funded effort that uses custom hardware (CHERI) and tooling to let you incrementally protect legacy stuff with capabilities. So, quite a few ways to deal with it. As usual, the problem is that our machines and languages make it easy to cause a vulnerability with common, fundamental operations. Making those operations fundamentally safe[r] knocks out a lot of that risk. Traditional techniques, like separation kernels, can try to isolate and detect the rest. That's my take on how to deal with being stuck with codebases like Webkit. Still work but feels less impossible.

hga 11y ago
A few more thoughts, without having looked at your references or even having more than a vague idea of the (necessary) architecture of browsers (it's fiddly front end stuff I don't like all that much as a domain), and for that matter at this point I'm just looking at all this because I don't like how things are, how they've developed since Multics and the Lisp Machine (the latter, admittedly not a secure system), and looking for what to try to do next with my life: A lot of what you suggest for directly solving it strike me as hacks not to my taste, but I'll look harder at that sort of thing in the future. Absent that: If you're going to modularize it, the interfaces are going to be complex and error prone, in part what I view as the difference between relatively easier to trust ciphers such as AES and much more fragile cryptosystems/cryptographic protocols (the one bit of real research I've done here was in 1979, trying to design an public key based authentication server; no success then, I gather it took half a decade to get to the not obviously broken stage). It's got to be fast; for now, ever faster as web pages get more and more complicated. Although one cause of that, calling out to zillions of different sources, admits to speed ups if you can incrementally/concurrently deal with the bits as you get them ... which of course makes the system more complicated. (There's probably a space for a browser distribution that thoroughly pretends to be from a mobile source and gets those simpler pages. :-) Firefox/Mozilla may be in the process of killing itself, worsening the oligopoly: Objectively, I hear they're dramatically losing market share AKA $$$ for further development. Related to that, poor organizational management. I heard on HN that they're preparing to move to a multiprocess architecture which will nuke their extension ecosystem, which is one of their core advantages. This is one of those nasty security-usability tradeoffs, or at least probably due to some of the above resource and organizational issues, plus perhaps security issues, the API presented to extensions won't allow them to do much. Chrome of course has this "problem". I guess what I'll personally do is concentrate on the lower level, tentatively starting with an Raspberry Pi seL4 port (I know, stop laughing, it's the most stable (long life promise) and widely available ARM platform for learning), wait to see how Servo plays out (see above Mozilla problems), and then return to this, maybe it's less "impossible" than I sense right now. Although still plenty impossible in the approaches my taste prefers that can't be used for the foreseeable future. Thanks a lot for your contributions to all these HN security discussions!