4 ms·

I find it quite discouraging to see how they basically give up trying to construct code without security flaws, and instead hope for some magic hardware mitigat

by fefe23 4y ago

I find it quite discouraging to see how they basically give up trying to construct code without security flaws, and instead hope for some magic hardware mitigation to rescue them. Investing in mitigations is not free. The time and effort it takes to develop them is not available for constructing bug-free code. And once you have them, there will be even less reason to construct bug-free code. After all the magic hardware-assisted mitigations will save us now. We've been through this before multiple times now. Someone will find a way to exploit around your mitigation, and you will then double down and come up with the next mitigation that will also be circumvented eventually. Personally I believe that "retrofitting" security can never work well. Security must be constructed, not retrofitted. Why is this example code using raw allocations? Construct secure code by using containers, not manual allocations. This has been the recommendation for years now.

charcircuit 4y ago
They haven't given up in trying. Trying is just not enough. The system should degrade into a state which is still safe when a memory bug happens.
pjmlp 4y ago
Google C++ guidelines is well know among the community for not being the best in what concerns C++ good practices, only C++ outsiders look at it as something of value. Something like C++ Core Guidelines, which include your remarks, is what should be looked into. Naturally Chrome follows Google's C++ guidelines, so.
- johannes1234321 4y ago
  right, it is nitworthy that Google guidlines are soecific to a code base within an organisation. There is quite some value in reading the rules and reasoning, but it isn't Gospel by any means.
- saagarjha 4y ago
  Google's C++ guidelines have almost nothing to do with Chrome's memory safety efforts. The concerns brought up in the article are relevant to other browsers too.
  - pjmlp 4y ago
    Yes and no. Certainly the efforts are welcome in any context in regards to C++ security improvements in mitigations, and C as well. Now, the guidelines aren't the best up to date in what concerns writing secure C++, as per security standards.
ulan 4y ago
I guess the authors used a raw allocation in the example code to show the simplest possible use-after-free. Any software with complex object ownership written in a language without GC has to balance between user-after-free (freeing an object too early) and memory leaks (keeping an object alive longer than needed). Maybe constructing secure code here would mean simplifying object ownership, but that doesn't seem practical for a beast such a modern browser with millions of lines of code. MTE with the heap scanning sounds like a real solution for the user-after-free problem, not merely a mitigation. The trade-off is that the memory is not immediately freed, but the measured increase of only 1% is promising.
- dan-robertson 4y ago
  https://smallcultfollowing.com/babysteps/blog/2022/06/15/what-it-feels-like-when-rust-saves-your-bacon/ https://smallcultfollowing.com/babysteps/blog/2022/06/15/wha... Gives a good example (in rust) of a case where complex object ownership could lead to a bug. The summary of the example there looks like: - you have some AST object and want to lower it in the compiler into an intermediate representation - you want to add some interesting parts of the AST to your state while lowering and refer to them later in the lowering process - This seems fine: the AST is first created, then you lower to the intermediate representation, then you can destroy the AST, so while you’re doing the lowering, the AST objects should all be alive and therefore ok to store references to in the lowerer-state - However there is some mostly unnoticed code that is roughly desugaring some syntax by constructing temporary AST nodes - So your addition may have your state including references to these temporary nodes - And those temporary nodes are freed shortly after being created rather than after the lowering is all done - Giving a quite subtle use-after-free.
- UncleMeat 4y ago
  It isn't a complete solution because it does not address stack-allocated data but it is very very close to being a full solution.
retroshit 4y ago
Constructing bug-free code is infeasible. Even the most skilled programmers write code with bugs in, and most programmers, including many who work on browsers components, are only moderately skilled, often writing buggy code. Perhaps the longer-term solution is to use languages that are memory safe by design, such as Rust, to avoid that class of bugs. But there will still be a huge deal of legacy C++ code to contend with in the meantime, so we do still need exploit mitigations.
- fefe23 4y ago
  I wrote construct instead of write for a reason. Clearly you can't expect programmers to just write secure code. If that worked, we would have seen evidence for it working by now. By construct I mean: follow a clear method or path, that is a) feasible to follow and b) will lead to bug-free code. Maybe not bug free in all respects but I posit it should be possible to construct code without memory safety issues (just look at Perl or Rust). My point is: It should not be up to the programmer to "simply not make mistakes". The method should be clear and have little ambiguity, and it should be obvious to see if code actually follows it or not. I can't be more concrete or specific than that because I think we still need to find that method. We should be working on it, though.
usefulcat 4y ago
> Investing in mitigations is not free. The time and effort it takes to develop them is not available for constructing bug-free code. I feel like this is a bit of a false dichotomy. Writing bug-free code is one approach to getting bug-free software. Attempting to detect UAF at run time is another approach. And there are many other options beyond those two (static analysis, sanitizers, testing, ...). In theory, we need only the ability to write bug-free code. If we could do this reliably, repeatedly, in a reasonable amount of time and at a large scale (Chromium, in this case), then there would be no value in investing in any of these other approaches. In practice, fixing every last bug in a large codebase can take a truly immense amount of time. And that is for a codebase that is not changing at all (including bug fixes!), which certainly does not describe Chromium or most large projects for that matter. Given all that, it's entirely reasonable to think about how one can find the most bugs with the least amount of effort. And that's basically what this is--another form of automated bug detection. I really don't think it's intended as a substitute for correct code.
- fefe23 4y ago
  You misconstrued my argument. I'm not advocating for "fixing all the bugs". On the contrary. I argue that retrofitting security does not work. I argued that we need to find a way to construct secure software, not to make existing insecure software more secure retroactively. We have tried writing shitty software first and then try to make it more secure for decades now. The track record is not good. We should try something else. Like constructing secure software from the start.
UncleMeat 4y ago
Many decades of work has demonstrated fairly clearly that it is not feasible to simply demand that people write secure code. "Just write it correctly" also does not help people who are starting at giant piles of C++ code that is a major security risk but also don't want to rewrite from scratch.

by fefe23 4y ago

charcircuit 4y ago

They haven't given up in trying. Trying is just not enough. The system should degrade into a state which is still safe when a memory bug happens.

pjmlp 4y ago

Google C++ guidelines is well know among the community for not being the best in what concerns C++ good practices, only C++ outsiders look at it as something of value. Something like C++ Core Guidelines, which include your remarks, is what should be looked into. Naturally Chrome follows Google's C++ guidelines, so.

johannes1234321 4y ago
right, it is nitworthy that Google guidlines are soecific to a code base within an organisation. There is quite some value in reading the rules and reasoning, but it isn't Gospel by any means.
saagarjha 4y ago
Google's C++ guidelines have almost nothing to do with Chrome's memory safety efforts. The concerns brought up in the article are relevant to other browsers too.
- pjmlp 4y ago
  Yes and no. Certainly the efforts are welcome in any context in regards to C++ security improvements in mitigations, and C as well. Now, the guidelines aren't the best up to date in what concerns writing secure C++, as per security standards.

ulan 4y ago

I guess the authors used a raw allocation in the example code to show the simplest possible use-after-free. Any software with complex object ownership written in a language without GC has to balance between user-after-free (freeing an object too early) and memory leaks (keeping an object alive longer than needed). Maybe constructing secure code here would mean simplifying object ownership, but that doesn't seem practical for a beast such a modern browser with millions of lines of code. MTE with the heap scanning sounds like a real solution for the user-after-free problem, not merely a mitigation. The trade-off is that the memory is not immediately freed, but the measured increase of only 1% is promising.

dan-robertson 4y ago
https://smallcultfollowing.com/babysteps/blog/2022/06/15/what-it-feels-like-when-rust-saves-your-bacon/ https://smallcultfollowing.com/babysteps/blog/2022/06/15/wha... Gives a good example (in rust) of a case where complex object ownership could lead to a bug. The summary of the example there looks like: - you have some AST object and want to lower it in the compiler into an intermediate representation - you want to add some interesting parts of the AST to your state while lowering and refer to them later in the lowering process - This seems fine: the AST is first created, then you lower to the intermediate representation, then you can destroy the AST, so while you’re doing the lowering, the AST objects should all be alive and therefore ok to store references to in the lowerer-state - However there is some mostly unnoticed code that is roughly desugaring some syntax by constructing temporary AST nodes - So your addition may have your state including references to these temporary nodes - And those temporary nodes are freed shortly after being created rather than after the lowering is all done - Giving a quite subtle use-after-free.
UncleMeat 4y ago
It isn't a complete solution because it does not address stack-allocated data but it is very very close to being a full solution.

retroshit 4y ago

Constructing bug-free code is infeasible. Even the most skilled programmers write code with bugs in, and most programmers, including many who work on browsers components, are only moderately skilled, often writing buggy code. Perhaps the longer-term solution is to use languages that are memory safe by design, such as Rust, to avoid that class of bugs. But there will still be a huge deal of legacy C++ code to contend with in the meantime, so we do still need exploit mitigations.

fefe23 4y ago
I wrote construct instead of write for a reason. Clearly you can't expect programmers to just write secure code. If that worked, we would have seen evidence for it working by now. By construct I mean: follow a clear method or path, that is a) feasible to follow and b) will lead to bug-free code. Maybe not bug free in all respects but I posit it should be possible to construct code without memory safety issues (just look at Perl or Rust). My point is: It should not be up to the programmer to "simply not make mistakes". The method should be clear and have little ambiguity, and it should be obvious to see if code actually follows it or not. I can't be more concrete or specific than that because I think we still need to find that method. We should be working on it, though.

usefulcat 4y ago

> Investing in mitigations is not free. The time and effort it takes to develop them is not available for constructing bug-free code. I feel like this is a bit of a false dichotomy. Writing bug-free code is one approach to getting bug-free software. Attempting to detect UAF at run time is another approach. And there are many other options beyond those two (static analysis, sanitizers, testing, ...). In theory, we need only the ability to write bug-free code. If we could do this reliably, repeatedly, in a reasonable amount of time and at a large scale (Chromium, in this case), then there would be no value in investing in any of these other approaches. In practice, fixing every last bug in a large codebase can take a truly immense amount of time. And that is for a codebase that is not changing at all (including bug fixes!), which certainly does not describe Chromium or most large projects for that matter. Given all that, it's entirely reasonable to think about how one can find the most bugs with the least amount of effort. And that's basically what this is--another form of automated bug detection. I really don't think it's intended as a substitute for correct code.

fefe23 4y ago
You misconstrued my argument. I'm not advocating for "fixing all the bugs". On the contrary. I argue that retrofitting security does not work. I argued that we need to find a way to construct secure software, not to make existing insecure software more secure retroactively. We have tried writing shitty software first and then try to make it more secure for decades now. The track record is not good. We should try something else. Like constructing secure software from the start.

UncleMeat 4y ago

Many decades of work has demonstrated fairly clearly that it is not feasible to simply demand that people write secure code. "Just write it correctly" also does not help people who are starting at giant piles of C++ code that is a major security risk but also don't want to rewrite from scratch.