4 ms·

> "We need to collectively admit memory safety is a problem." Yes, we need it badly. Because I am still seeing a lot of folks either deny that memory safety is

by devy 10y ago

> "We need to collectively admit memory safety is a problem." Yes, we need it badly. Because I am still seeing a lot of folks either deny that memory safety is a big problem of programming in C or some even accept the fact.[1] Without admitting that and start taking action to improve infrastructure software, I don't see how we can build a securer future. That's an intervention, it should start now. [1]: https://news.ycombinator.com/item?id=13979206 https://news.ycombinator.com/item?id=13979206

catdog 10y ago
The amount of problem denial in the line of "experienced C programmers make no mistakes" or "what? Memory safe languages can avoid only maybe half or so of security bugs, totally not worth it" is astonishing. Granted, it's not easy right now (sometimes close to impossible) for some types of projects to not use C but defending the obvious [1] flaws of the language is mind blowing. [1] Pretty obvious from the beginning. The creators of C made a pragmatic choice and created a language which basically does not guarantee anything. This allowed them to write a compiler fast enough for the limited computing power they had at hand. //edit: Also "C is great because I like programming in C" does not help here. If you like C nobody says you shouldn't ever use it anymore but you should be aware of the problems it drags along and maybe consider sth. else for security critical code.
dboreham 10y ago
Memory safety is certainly a problem. But so is the ability to execute data. I'm scared by the use of any language that has that capability for security-critical applications.
- asveikau 10y ago
  In the last 15 or so years that awareness has increased of that issue, the defaults for stack and heap allocations are to mark pages as non-executable. It is therefore harder than it used to be to execute data - you need to jump through some hoops. Not to mention if you could not execute data, your programs would not load.
  - dboreham 10y ago
    I was actually thinking of languages that allow (encourage, even) execution of data. For example : Ruby, Java. Interesting exercise : take a large Java server application and figure out if somewhere, somehow, it can be made to execute a string sent by a client.
  - makomk 10y ago
    The moment you have any kind of interpreter or JIT compiler, you're effectively bypassing non-executable protection on memory by providing a way of executing code that looks just like accessing data from the CPU's perspective.

by devy 10y ago

catdog 10y ago

The amount of problem denial in the line of "experienced C programmers make no mistakes" or "what? Memory safe languages can avoid only maybe half or so of security bugs, totally not worth it" is astonishing. Granted, it's not easy right now (sometimes close to impossible) for some types of projects to not use C but defending the obvious [1] flaws of the language is mind blowing. [1] Pretty obvious from the beginning. The creators of C made a pragmatic choice and created a language which basically does not guarantee anything. This allowed them to write a compiler fast enough for the limited computing power they had at hand. //edit: Also "C is great because I like programming in C" does not help here. If you like C nobody says you shouldn't ever use it anymore but you should be aware of the problems it drags along and maybe consider sth. else for security critical code.

dboreham 10y ago

Memory safety is certainly a problem. But so is the ability to execute data. I'm scared by the use of any language that has that capability for security-critical applications.

asveikau 10y ago
In the last 15 or so years that awareness has increased of that issue, the defaults for stack and heap allocations are to mark pages as non-executable. It is therefore harder than it used to be to execute data - you need to jump through some hoops. Not to mention if you could not execute data, your programs would not load.
- dboreham 10y ago
  I was actually thinking of languages that allow (encourage, even) execution of data. For example : Ruby, Java. Interesting exercise : take a large Java server application and figure out if somewhere, somehow, it can be made to execute a string sent by a client.
- makomk 10y ago
  The moment you have any kind of interpreter or JIT compiler, you're effectively bypassing non-executable protection on memory by providing a way of executing code that looks just like accessing data from the CPU's perspective.