3 ms·

These are all errors that would be impossible in a language with, oh, bounds checking. There may be ranges of security-critical code that make sense to write i

These are all errors that would be impossible in a language with, oh, bounds checking. There may be ranges of security-critical code that make sense to write in C, for example ensuring that algorithms run in constant time, although with modern compilers I have difficulty trusting that the compiler won't accidentally optimize away the constant-time-ness. Surely ASN.1 encoding isn't part of that range, however?

pjmlp 11y ago
Hoare quote during Turing award in 1981: "The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself. Thus no core dumps should ever be necessary. It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time. A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." -- C.A.R. Hoare, Communications of the ACM, 1981
- codezero 11y ago
  Making it illegal to write code without bounds checking is an interesting and fun concept to imagine.
  - masklinn 11y ago
    Why? That's how the vast majority of modern languages work. You can't opt out of bounds checking in Java or Python.
    - outworlder 11y ago
      Yes, but they now opt out of other things. Such as nullable variable references.
    - codezero 11y ago
      I was thinking of it more playfully – what would this legislation look like, how would it affect productivity of engineers, it's a curiosity, I don't actually have any stake in it happening.
- jftuga 11y ago
  C.A.R. Hoare was the author of the Quicksort algorithm in 1959.
  - masklinn 11y ago
    C.A.R. Hoare is both still alive and the author of much more than just Quicksort.
  - nickpsecurity 11y ago
    Were you alluding to how it allows worst-case behavior to throw your system way off in unpredictable ways to enable higher performance on average case? And thus contradicting his claim? Well, he did design that before making that claim in the 80's. Apparently, he learned his lesson. :)
CiPHPerCoder 11y ago
> These are all errors that would be impossible in a language with, oh, bounds checking. How would that prevent the timing leak that caused Lucky 13 or the padding oracle that resulted from not erroring when the message was too short? The problem with CVE-2016-2107 (and the vulns that precede it) stems from TLS not using Encrypt-Then-MAC (checking the MAC before checking the padding is less error-prone than checking the padding before the MAC). You can design a cryptographically doomed protocol in any language, even memory-safe ones. Here's one in Haskell: https://github.com/RNCryptor/rncryptor-hs/issues/2#issuecomment-174385279 https://github.com/RNCryptor/rncryptor-hs/issues/2#issuecomm... Further reading on the Cryptographic Doom Principle: https://moxie.org/blog/the-cryptographic-doom-principle/ https://moxie.org/blog/the-cryptographic-doom-principle/
- pjmlp 11y ago
  Yes you can, but you cannot corrupt memory in them and that is already helpful.
  - CiPHPerCoder 11y ago
    That's nice, but irrelevant. The quote I was replying to said, "These are all errors that would be impossible in a language with, oh, bounds checking." Them: All X is Y. Me: But here's an X that isn't Y. That's my point. Blanket statements about the superiority/inferiority of programming languages aren't useful here.
  - coherentpony 11y ago
    Sure you can. Compilers (and interpreters) have bugs in them.
    - pjmlp 11y ago
      A compiler, interpreter bug in terms of attack surface is much different than a programming language where every single string and array access might cause memory corruption.
- lmm 11y ago

pjmlp 11y ago

Hoare quote during Turing award in 1981: "The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself. Thus no core dumps should ever be necessary. It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time. A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." -- C.A.R. Hoare, Communications of the ACM, 1981

codezero 11y ago
Making it illegal to write code without bounds checking is an interesting and fun concept to imagine.
- masklinn 11y ago
  Why? That's how the vast majority of modern languages work. You can't opt out of bounds checking in Java or Python.
  - outworlder 11y ago
    Yes, but they now opt out of other things. Such as nullable variable references.
  - codezero 11y ago
    I was thinking of it more playfully – what would this legislation look like, how would it affect productivity of engineers, it's a curiosity, I don't actually have any stake in it happening.
jftuga 11y ago
C.A.R. Hoare was the author of the Quicksort algorithm in 1959.
- masklinn 11y ago
  C.A.R. Hoare is both still alive and the author of much more than just Quicksort.
- nickpsecurity 11y ago
  Were you alluding to how it allows worst-case behavior to throw your system way off in unpredictable ways to enable higher performance on average case? And thus contradicting his claim? Well, he did design that before making that claim in the 80's. Apparently, he learned his lesson. :)

CiPHPerCoder 11y ago

> These are all errors that would be impossible in a language with, oh, bounds checking. How would that prevent the timing leak that caused Lucky 13 or the padding oracle that resulted from not erroring when the message was too short? The problem with CVE-2016-2107 (and the vulns that precede it) stems from TLS not using Encrypt-Then-MAC (checking the MAC before checking the padding is less error-prone than checking the padding before the MAC). You can design a cryptographically doomed protocol in any language, even memory-safe ones. Here's one in Haskell: https://github.com/RNCryptor/rncryptor-hs/issues/2#issuecomment-174385279 https://github.com/RNCryptor/rncryptor-hs/issues/2#issuecomm... Further reading on the Cryptographic Doom Principle: https://moxie.org/blog/the-cryptographic-doom-principle/ https://moxie.org/blog/the-cryptographic-doom-principle/

pjmlp 11y ago
Yes you can, but you cannot corrupt memory in them and that is already helpful.
- CiPHPerCoder 11y ago
  That's nice, but irrelevant. The quote I was replying to said, "These are all errors that would be impossible in a language with, oh, bounds checking." Them: All X is Y. Me: But here's an X that isn't Y. That's my point. Blanket statements about the superiority/inferiority of programming languages aren't useful here.
- coherentpony 11y ago
  Sure you can. Compilers (and interpreters) have bugs in them.
  - pjmlp 11y ago
    A compiler, interpreter bug in terms of attack surface is much different than a programming language where every single string and array access might cause memory corruption.
lmm 11y ago