Hacker News new | ask | show | jobs
by Someone1234 4123 days ago
In particular when you're developing in languages which are insecure by design.
1 comments

Insecure code can be written in any language.
Just like any car can crash. However some cars are more dangerous than other cars, just as some programming languages are more likely to produce insecure code than other programming languages.

Nobody is proposing re-writing a hypervisor in Java or Python, but C/C++ isn't the only game in town anymore for unmanaged code, and the alternatives are designed from the ground up with security in mind.

> Just like any car can crash. However some cars are more dangerous than other cars, just as some programming languages are more likely to produce insecure code than other programming languages.

> and the alternatives are designed from the ground up with security in mind

The RMS Titanic was billed as one of the safest ships on the sea -- yet due to poorly implemented protocols and practices, negligent leadership, and disregard for best practices, it resulted in one of the most catastrophic maritime disasters.

Using the most "secure" programming language in the world, one can still design very insecure code. Conversely, using the most "insecure" programming language in the world, one can still design very secure code. This would boil down to the skill of the engineers, competence of leadership and adherence to best practices.

The RMS Titanic sunk, but the engineers made it much harder to sink than ocean liners which preceded it.

C/C++ starts you in a position where it is extremely easy to write insecure code. Even a competent coder can produce insecure code in either language without a great deal of effort or stupidity on their part.

Other languages aren't "unsinkable" to come back to the Titanic, but they make it harder to sink, and the requirements on the developer aren't as high. Just like with the Titanic you have to hit the iceberg in a certain specific way to sink, rather than sinking from any old collision.

Certain C/C++ compilers have definitely made the situation better when in "strict mode" as well as a lot of tooling to identify potential problem points. However ultimately the language is plagued by "undefined behaviour" and a large code-base where developers are using various insecure tricks to save pennies (e.g. this exact exploit, where they are creating insecure code to save a single structure's worth of memory, which on an 8 GB stick of RAM is less than 1/2 of 1c worth (assuming $60/8 GB stick)).

> C/C++ starts you in a position where it is extremely easy to write insecure code.

It's worth mentioning K&R, which used to be where people learn C, has a huge number of instances of very risky practices.