I think when I started out I thought of security as its own narrow, specific thing distinct from other aspects of software correctness. With time many mitigations (hw and sw) start to look more like lightweight checks for correct, or at least reasonable-looking, operation of the program: do we expect the kernel to be reading this user page now? does this kind of process want to make this kind of syscall? does it look like this pointer was computed normally (thinking of pointer authentication here)? is this an expected indirect jump destination? And other security-related stuff like fuzzers, sanitizers, static analysis, etc. are forms of QA that can catch non-security bugs. Selective use of GC in C++ (Chrome’s Oilpan, Edge’s MemGC) look like what some other languages to to prevent UAF bugs.
Realize it’s not at all an original observation that security and broader correctness are related. I guess it just starts to stand out more as we move on from earlier things like adding ASLR and avoiding strcpy to more and deeper changes.
First, I don’t think I’m slamming Chrome at all, I certainly don’t intend to.
Second, I wrote this because as I read the description from the Google team, and started talking with friends and colleagues it became clear that, both through my work on Firefox’s sandboxing as well as my broader open source security work, I had a bunch of knowledge that other people found useful and interesting about what had changed such that this vulnerability was exploitable only against Windows 7, and I wanted to share that. Both because I think this stuff is interesting and others would enjoy learning about it, and because it’s part of a broader interest of mine in expanding how we think about building secure systems, away from an emphasis on simply fixing bugs and counting how many there are, and towards thinking about resilience and failure modes as a measure of security.
I think when I started out I thought of security as its own narrow, specific thing distinct from other aspects of software correctness. With time many mitigations (hw and sw) start to look more like lightweight checks for correct, or at least reasonable-looking, operation of the program: do we expect the kernel to be reading this user page now? does this kind of process want to make this kind of syscall? does it look like this pointer was computed normally (thinking of pointer authentication here)? is this an expected indirect jump destination? And other security-related stuff like fuzzers, sanitizers, static analysis, etc. are forms of QA that can catch non-security bugs. Selective use of GC in C++ (Chrome’s Oilpan, Edge’s MemGC) look like what some other languages to to prevent UAF bugs.
Realize it’s not at all an original observation that security and broader correctness are related. I guess it just starts to stand out more as we move on from earlier things like adding ASLR and avoiding strcpy to more and deeper changes.
[Comment from banned user removed]
First, I don’t think I’m slamming Chrome at all, I certainly don’t intend to.
Second, I wrote this because as I read the description from the Google team, and started talking with friends and colleagues it became clear that, both through my work on Firefox’s sandboxing as well as my broader open source security work, I had a bunch of knowledge that other people found useful and interesting about what had changed such that this vulnerability was exploitable only against Windows 7, and I wanted to share that. Both because I think this stuff is interesting and others would enjoy learning about it, and because it’s part of a broader interest of mine in expanding how we think about building secure systems, away from an emphasis on simply fixing bugs and counting how many there are, and towards thinking about resilience and failure modes as a measure of security.
How did you manage to turn “here are some helpful exploit mitigations” into “let’s slam chrome”?
Seems like just sharing knowledge which author happens to have, I did not see much slamming.