4 ms·

Its kind of sad that text and image documents today are so complicated that security vulnerabilities in software that reads them are considered inevitable.

by ufo 11y ago

SquareWheel 11y ago
Web browsers are one of the most complicated pieces of software on your computer. Many webpages are now webapps, and more comparable to programs than text documents. This is not necessarily a bad thing as it allows much more interaction between user and server. But complexity often means more bugs, and thus more vulnerabilities.
pcwalton 11y ago
Complexity is inevitable. The problem (well, one of the largest problems) is that we have collectively failed to come up with effective mitigations for these basic memory safety issues (other than sandboxing). At best we don't invest enough in effective solutions; at worst we incorrectly convince ourselves that "good programmers" never create exploitable security vulnerabilities. Just look at the list: http://webkitgtk.org/security/WSA-2015-0002.html http://webkitgtk.org/security/WSA-2015-0002.html "Memory corruption and application crash" appears more times than I can count.
- sebcat 11y ago
  Sandboxing is great. Isolate certain functionality in a separate process, sandbox it with OS-provided solutions like seccomp-bpf or capsicum, make it terminate on a violation, design its API to be idempotent so you can just restart the process on failure. Have rlimits on process memory usage. There are technical solutions and development processes to write better, more secure software. The problem is of course that software has to be designed for this, it's not something that can easily be slapped on as an afterthought. It demands more of the design, and that's not easy to motivate in most organisations. Forcing the developer to take security into consideration would be better, but the root of the problem is that most organisations don't consider security that important, even if they say they do.
  - pcwalton 11y ago
    I fully agree, but I don't think we should stop at sandboxing. Pwn2Own has compromised too many sandboxed browsers for comfort. I think we also need to have a robust mitigation strategy for memory safety problems.
    - simoncion 11y ago
      > Pwn2Own has compromised too many sandboxed browsers for comfort. AFAIK, (but it's entirely likely that I'm ignorant) there is no mainstream seccomp or capsicum sandboxed browser.
      - zurn 11y ago
        Chrome sandbox uses seccomp by default on Linux (Normal desktop and Chrome OS, don't know about Android). https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md https://chromium.googlesource.com/chromium/src/+/master/docs...
  - mike_hearn 11y ago
    It'd be much, much nicer if we could just use memory safe languages all the time, everywhere. Sandboxing is ultimately a kludge: a recognition that our tools are so dangerous that failure is not just a possibility but an inevitability. It comes at a huge cost in developer productivity, code complexity and sometimes runtime performance suffers too. pcwalton works on Rust, I believe. A rendering engine written in a memory-safe style is something humanity just needs to build and I applaud Mozilla in at least starting down that long road with Servo. That said, HTML5 has sprawled to the point that it appears (to me) essentially unimplementable from scratch unless you are Google, Microsoft or Apple. That seems like a problem. If web servers indicated what HTML features a page they were serving needed, it'd let browsers pick different rendering engines on the fly, but of course ... malicious web pages would simply always ask for the least secure engine. There doesn't seem to be a good workaround for that. It's the downside of trying to force the web into being an app platform. It's also unclear to me how the balance between safe and unsafe code works out in Rust. Looking at Servo it appears that unsafe code is used all over the place including in very core parts: https://github.com/servo/servo/search?utf8=%E2%9C%93&q=unsafe+filetype%3Arust&type=Code https://github.com/servo/servo/search?utf8=%E2%9C%93&q=unsaf... My guess is that Rust's memory model simply requires unsafe code more often than a traditional GCd range checked language does. A part of me wishes the Java guys would hurry up and get value types done already (it's years away), as combined with a lot of the auto-vectorisation optimisations being added at the moment by Intel it feels like at that point a performance competitive rendering engine written in entirely memory safe code would become realistic. Perhaps it even already is, unfortunately none of the above mentioned companies are interested in trying and nobody else can afford HTML5. This line of thought is how I ended up concluding we need an entirely new mobile code oriented app platform.
zurn 11y ago
Web browsers were full of security holes in simpler days too. Security gets in the way a lot if you have to take it seriously, especially when you're surrounded by C culture. By now everyone's used to the vulnerabilities.

Its kind of sad that text and image documents today are so complicated that security vulnerabilities in software that reads them are considered inevitable.

by ufo 11y ago

Its kind of sad that text and image documents today are so complicated that security vulnerabilities in software that reads them are considered inevitable.

SquareWheel 11y ago

Web browsers are one of the most complicated pieces of software on your computer. Many webpages are now webapps, and more comparable to programs than text documents. This is not necessarily a bad thing as it allows much more interaction between user and server. But complexity often means more bugs, and thus more vulnerabilities.

pcwalton 11y ago

Complexity is inevitable. The problem (well, one of the largest problems) is that we have collectively failed to come up with effective mitigations for these basic memory safety issues (other than sandboxing). At best we don't invest enough in effective solutions; at worst we incorrectly convince ourselves that "good programmers" never create exploitable security vulnerabilities. Just look at the list: http://webkitgtk.org/security/WSA-2015-0002.html http://webkitgtk.org/security/WSA-2015-0002.html "Memory corruption and application crash" appears more times than I can count.

sebcat 11y ago
Sandboxing is great. Isolate certain functionality in a separate process, sandbox it with OS-provided solutions like seccomp-bpf or capsicum, make it terminate on a violation, design its API to be idempotent so you can just restart the process on failure. Have rlimits on process memory usage. There are technical solutions and development processes to write better, more secure software. The problem is of course that software has to be designed for this, it's not something that can easily be slapped on as an afterthought. It demands more of the design, and that's not easy to motivate in most organisations. Forcing the developer to take security into consideration would be better, but the root of the problem is that most organisations don't consider security that important, even if they say they do.
- pcwalton 11y ago
  I fully agree, but I don't think we should stop at sandboxing. Pwn2Own has compromised too many sandboxed browsers for comfort. I think we also need to have a robust mitigation strategy for memory safety problems.
  - simoncion 11y ago
    > Pwn2Own has compromised too many sandboxed browsers for comfort. AFAIK, (but it's entirely likely that I'm ignorant) there is no mainstream seccomp or capsicum sandboxed browser.
    - zurn 11y ago
      Chrome sandbox uses seccomp by default on Linux (Normal desktop and Chrome OS, don't know about Android). https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md https://chromium.googlesource.com/chromium/src/+/master/docs...
- mike_hearn 11y ago
  It'd be much, much nicer if we could just use memory safe languages all the time, everywhere. Sandboxing is ultimately a kludge: a recognition that our tools are so dangerous that failure is not just a possibility but an inevitability. It comes at a huge cost in developer productivity, code complexity and sometimes runtime performance suffers too. pcwalton works on Rust, I believe. A rendering engine written in a memory-safe style is something humanity just needs to build and I applaud Mozilla in at least starting down that long road with Servo. That said, HTML5 has sprawled to the point that it appears (to me) essentially unimplementable from scratch unless you are Google, Microsoft or Apple. That seems like a problem. If web servers indicated what HTML features a page they were serving needed, it'd let browsers pick different rendering engines on the fly, but of course ... malicious web pages would simply always ask for the least secure engine. There doesn't seem to be a good workaround for that. It's the downside of trying to force the web into being an app platform. It's also unclear to me how the balance between safe and unsafe code works out in Rust. Looking at Servo it appears that unsafe code is used all over the place including in very core parts: https://github.com/servo/servo/search?utf8=%E2%9C%93&q=unsafe+filetype%3Arust&type=Code https://github.com/servo/servo/search?utf8=%E2%9C%93&q=unsaf... My guess is that Rust's memory model simply requires unsafe code more often than a traditional GCd range checked language does. A part of me wishes the Java guys would hurry up and get value types done already (it's years away), as combined with a lot of the auto-vectorisation optimisations being added at the moment by Intel it feels like at that point a performance competitive rendering engine written in entirely memory safe code would become realistic. Perhaps it even already is, unfortunately none of the above mentioned companies are interested in trying and nobody else can afford HTML5. This line of thought is how I ended up concluding we need an entirely new mobile code oriented app platform.

zurn 11y ago

Web browsers were full of security holes in simpler days too. Security gets in the way a lot if you have to take it seriously, especially when you're surrounded by C culture. By now everyone's used to the vulnerabilities.