5 ms·

It's important to clarify that memory safety is only one aspect of writing safe, secure software. To this list then I would also want to add and compare: OOM-s

It's important to clarify that memory safety is only one aspect of writing safe, secure software. To this list then I would also want to add and compare: OOM-safety under overload conditions, and fine-grained error handling safety, in particular because error handling tends to be one of the leading causes of faults in distributed systems [1]. To be fair, I was surprised that Rust did not have checked arithmetic on by default and that this needs to be turned on via compiler setting or linted against. The presence of integer overflow in a program can facilitate a whole range of exploits, even with memory safety. [1] - https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_osdi14.pdf https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_o...

littlestymaar 6y ago
> The presence of integer overflow in a program can facilitate a whole range of exploits, even with memory safety. Do you have examples that do not involve array indexing? (which are uncommon in Rust because iterators exist and are faster).
- jorangreef 6y ago
  Sure, almost anything that uses numbers, e.g. to control access or parse data structures or do "something important", here are two off the top of my head: * Rate limits for an OTP, which could be trivially reset through overflow. * Parsing zip files, where the hostile content is self-referencing, to sneak in cyclic references for a DoS, or to change file extension type for code execution after bypassing a content filter, or to change output destination (e.g. as part of a symbolic link or directory traversal) to overwrite system files. Unchecked arithmetic for me is by far one of the scariest exploit vectors because it's so easy to do, and one of the first things a trained attacker would look for. Programs in any language are always exploitable, in some way or another. Memory safety is no guarantee that a program is "safe" let alone correct.
  - littlestymaar 6y ago
    Thanks for the examples.
    - jorangreef 6y ago
      Hey it's a pleasure!
quietbritishjim 6y ago
> memory safety is only one aspect of writing safe, secure software A good example of this is the SQLite documentation page "Why Is SQLite Coded In C". Among other things, it describes those memory safety issues as "the easy problems" compared to "the rather more difficult problem of computing a correct answer to an SQL statement". Not all of our programs are like SQLite, of course (and not all of us mere mortals are like its developers). But I would certainly say that just because you've eliminated memory safety bugs doesn't mean you've eliminated all bugs. Depending on the program, you might not even have eliminated most bugs. [1] https://www.sqlite.org/whyc.html https://www.sqlite.org/whyc.html
- jorangreef 6y ago
  There's always a new treasure to be found in the SQLite documentation. Thanks for the link.
- jamii 6y ago
  Despite being an 'easy problem' it has led to code execution on android/ios: https://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/ https://research.checkpoint.com/2019/select-code_execution-f... > We established that simply querying a database may not be as safe as you expect. Using our innovative techniques of Query Hijacking and Query Oriented Programming, we proved that memory corruption issues in SQLite can now be reliably exploited. As our permissions hierarchies become more segmented than ever, it is clear that we must rethink the boundaries of trusted/untrusted SQL input. To demonstrate these concepts, we achieved remote code execution on a password stealer backend running PHP7 and gained persistency with higher privileges on iOS. We believe that these are just a couple of use cases in the endless landscape of SQLite.
  - dnautics 6y ago
    technically that's exactly the 'hard' problem, since QOP and QH are 'dealing with database problems' and not low-level problems like memory safety.
    - 6y ago
unanswered 6y ago
> Rust did not have checked arithmetic on by default Except it does, in debug mode, which is the default compilation mode. And you don't have to tweak compiler settings or linters to get checked arithmetic in release: you simply call the checked arithmetic functions, which give the added benefit of giving you complete freedom in how to handle overflow. Wherever you 'learned' this misinformation from, please stop considering it a trustworthy source :(

littlestymaar 6y ago

> The presence of integer overflow in a program can facilitate a whole range of exploits, even with memory safety. Do you have examples that do not involve array indexing? (which are uncommon in Rust because iterators exist and are faster).

jorangreef 6y ago
Sure, almost anything that uses numbers, e.g. to control access or parse data structures or do "something important", here are two off the top of my head: * Rate limits for an OTP, which could be trivially reset through overflow. * Parsing zip files, where the hostile content is self-referencing, to sneak in cyclic references for a DoS, or to change file extension type for code execution after bypassing a content filter, or to change output destination (e.g. as part of a symbolic link or directory traversal) to overwrite system files. Unchecked arithmetic for me is by far one of the scariest exploit vectors because it's so easy to do, and one of the first things a trained attacker would look for. Programs in any language are always exploitable, in some way or another. Memory safety is no guarantee that a program is "safe" let alone correct.
- littlestymaar 6y ago
  Thanks for the examples.
  - jorangreef 6y ago
    Hey it's a pleasure!

quietbritishjim 6y ago

> memory safety is only one aspect of writing safe, secure software A good example of this is the SQLite documentation page "Why Is SQLite Coded In C". Among other things, it describes those memory safety issues as "the easy problems" compared to "the rather more difficult problem of computing a correct answer to an SQL statement". Not all of our programs are like SQLite, of course (and not all of us mere mortals are like its developers). But I would certainly say that just because you've eliminated memory safety bugs doesn't mean you've eliminated all bugs. Depending on the program, you might not even have eliminated most bugs. [1] https://www.sqlite.org/whyc.html https://www.sqlite.org/whyc.html

jorangreef 6y ago
There's always a new treasure to be found in the SQLite documentation. Thanks for the link.
jamii 6y ago
Despite being an 'easy problem' it has led to code execution on android/ios: https://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/ https://research.checkpoint.com/2019/select-code_execution-f... > We established that simply querying a database may not be as safe as you expect. Using our innovative techniques of Query Hijacking and Query Oriented Programming, we proved that memory corruption issues in SQLite can now be reliably exploited. As our permissions hierarchies become more segmented than ever, it is clear that we must rethink the boundaries of trusted/untrusted SQL input. To demonstrate these concepts, we achieved remote code execution on a password stealer backend running PHP7 and gained persistency with higher privileges on iOS. We believe that these are just a couple of use cases in the endless landscape of SQLite.
- dnautics 6y ago
  technically that's exactly the 'hard' problem, since QOP and QH are 'dealing with database problems' and not low-level problems like memory safety.
  - 6y ago

unanswered 6y ago

> Rust did not have checked arithmetic on by default Except it does, in debug mode, which is the default compilation mode. And you don't have to tweak compiler settings or linters to get checked arithmetic in release: you simply call the checked arithmetic functions, which give the added benefit of giving you complete freedom in how to handle overflow. Wherever you 'learned' this misinformation from, please stop considering it a trustworthy source :(