5 ms·

C code will continue to dereference pointers after object deallocation, access arrays out of bounds, and not complain about integer overflow. Even if input is n

C code will continue to dereference pointers after object deallocation, access arrays out of bounds, and not complain about integer overflow. Even if input is not an RCE, you will silently get an incorrect result of computation. A safer language helps in cases other than security.

majewsky 10y ago
And there are newer languages that have this problem. I was shocked to see that I could produce a SIGSEGV in Nim within the first 15 lines of code that I wrote.
- dom96 10y ago
  Why were you shocked? Is it because you're used to languages that prevent null values by default or do you have concerns about the safety of Nim because of this error? Whatever the case, as far as I am aware, sooner or later Nim will prevent nil values by default.
  - majewsky 10y ago
    If that happens, I'll gladly look at it again. My point is that we have enough languages with unchecked access to nil values by now.
    - jwatte 10y ago
      But how is a nil pointer segv different from a irrefutable pattern mismatch in Haskell, or "undefined is not a function" in JavaScript?
- SamReidHughes 10y ago
  A segfault on a null pointer isn't a memory safety problem, so that's not the same thing at all.
  - nickpsecurity 10y ago
    Sure it is. It means your language and tooling allowed an unauthorized access that resulted in a segfault. Many don't. There's even system-level languages like Clay and Rust that can catch those things. Also, tools like Softbound+CETS neutralize them in C code. The category is called "temporal, memory safety." Definitely a memory safety issue. Definitely worth preventing if possible. If not preventable, definitely worth handling better than mere segfaults.
    - SamReidHughes 10y ago
      No, it's the same as a .unwrap() in Rust, or malloc exiting when it fails. It means the language doesn't force you to handle all cases, not that it's "unsafe."
      - steveklabnik 10y ago
        unwrap won't cause a segfault, it will either unwind the stack, or abort.
        SamReidHughes 10y ago
        The point about it being like .unwrap is that the bug is a completeness bug. My theory is that people have converted "memory unsafety can cause segfaults" into "segfaults are memory unsafe." Segfaults are actually the desired outcome, and initializing a pointer with null, instead of leaving it uninitialized is how that outcome is achieved.
        steveklabnik 10y ago
        Segfaults can often be turned into an actual exploit; unwinding the stack cannot. It would be better to explicitly abort than to purposefully cause a segfault.
        SamReidHughes 10y ago

majewsky 10y ago

And there are newer languages that have this problem. I was shocked to see that I could produce a SIGSEGV in Nim within the first 15 lines of code that I wrote.

dom96 10y ago
Why were you shocked? Is it because you're used to languages that prevent null values by default or do you have concerns about the safety of Nim because of this error? Whatever the case, as far as I am aware, sooner or later Nim will prevent nil values by default.
- majewsky 10y ago
  If that happens, I'll gladly look at it again. My point is that we have enough languages with unchecked access to nil values by now.
  - jwatte 10y ago
    But how is a nil pointer segv different from a irrefutable pattern mismatch in Haskell, or "undefined is not a function" in JavaScript?
SamReidHughes 10y ago
A segfault on a null pointer isn't a memory safety problem, so that's not the same thing at all.
- nickpsecurity 10y ago
  Sure it is. It means your language and tooling allowed an unauthorized access that resulted in a segfault. Many don't. There's even system-level languages like Clay and Rust that can catch those things. Also, tools like Softbound+CETS neutralize them in C code. The category is called "temporal, memory safety." Definitely a memory safety issue. Definitely worth preventing if possible. If not preventable, definitely worth handling better than mere segfaults.
  - SamReidHughes 10y ago
    No, it's the same as a .unwrap() in Rust, or malloc exiting when it fails. It means the language doesn't force you to handle all cases, not that it's "unsafe."
    - steveklabnik 10y ago
      unwrap won't cause a segfault, it will either unwind the stack, or abort.
      - SamReidHughes 10y ago
        The point about it being like .unwrap is that the bug is a completeness bug. My theory is that people have converted "memory unsafety can cause segfaults" into "segfaults are memory unsafe." Segfaults are actually the desired outcome, and initializing a pointer with null, instead of leaving it uninitialized is how that outcome is achieved.
        steveklabnik 10y ago
        Segfaults can often be turned into an actual exploit; unwinding the stack cannot. It would be better to explicitly abort than to purposefully cause a segfault.
        SamReidHughes 10y ago