[Timmons]

This is quite ignorant of why C/C++ is used.

It is used for that exact memory control and access that this article demonizes so that we can have efficient and thought out systems.

When those systems aren't well thought out or secure you have security issues. C/C++ lets you build a wobbly treehouse _and_ a secure fortress. It is up to the developer which one is made...

[pjmlp]

> This is quite ignorant of why C/C++ is used.

C and C++ are used due to UNIX becoming widespread, opening the door to those languages in the industry, and killing safer systems programming languages in the process.

The majority of security exploits in C and C++ aren't possible in Modula-2, Ada, Algol, just to cite a few examples.

To quote Hoare on his award's speech, The Emperor's Old Clothes:

"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"

[justwannasing]

Becoming widespread? Outside the desktop, the most commonly used operating system is Unix and its "likes" and dominates the internet and mobile devices.

[pjmlp]

I only cared about C in 1993 and am into computers since 1986.

Only developers with access to expensive UNIX workstations cared about learning C.

Yes, the widespread of UNIX and C as its language is one of the reasons the CVE database gets updated every day.

[peterwaller]

A place where your reasoning breaks down is when one comes to define "the developer".

There are a few legendary developers in the world I would trust to write secure C/C++. Others may be able to do so, by luck.

Would I trust an organization of 2000 people all developing the same large code base? I know there are processes that can be adopted, such as using clever static analysis tools and rigorous review by security professionals.

But time and time again, the community says "Yay, we've invented X, this makes a huge class of security bugs obsolete". Then Y comes along and opens the playing field again. (e.g, X=Data execution prevention, Y=Return oriented programming).

This keeps happening. It takes some arrogance to believe that a safe large system can be built in an unsafe language, these days.

[bilbo0s]

"...But time and time again, the community says "Yay, we've invented X, this makes a huge class of security bugs obsolete". Then Y comes along and opens the playing field again..."

To be fair...

This issue exists with every other language as well. I would be very skeptical of any language claiming to be 100% secure.

The same is true of the developer argument. Cyclone, Rust, C#, Java... you name it... they are all capable of producing systems with security vulnerabilities owing to developer quality inconsistencies.

[JustSomeNobody]

This will happen regardless of C or C++.

[peterwaller]

I agree with this and bilbo0s. There exists no panacea. But C/C++ leave a lot of unholstered footguns lying around to play with :)

[bowlofstew]

I couldn't agree more. I like how he is very pointed at C/C++ and doesn't mention any of the safer, garbage collected languages....OH NOES, they have issues too!

Java: https://www.exploit-db.com/exploits/36101/

.NET: https://www.exploit-db.com/exploits/35280/

Python: https://www.exploit-db.com/exploits/33251/

At least my code/data running in "the cloud" is safe:

http://www.jcomputers.us/vol9/jcp0904-30.pdf

https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf

I can keep going here but you get the point. Perhaps he should have also taken it further and proposed that we move onto Mill processors since the underlying hardware has a history of issues:

sinkhole: https://www.exploit-db.com/exploits/37724/

rowhammer: https://www.exploit-db.com/exploits/36310/

Yes in C/C++ you can make mistakes (#gotofail) but in other languages, I would argue you can fuck-up in ways that are not nearly as obvious such that static analysis can't catch. A nicety about C/C++ is the tooling has gotten pretty damn good over the last 43 years (clang, gcc, valgrind, etc) and can catch most of these kind of bugs. The onus is on the developer to do the correct thing though and it appears that over at Adobe, etc that they (historically) could give 0 shits about doing this. It honestly seems to be though, that they are tightening up things.

Perhaps we should rebuild everything from the ground up....

[RegW]

Hmm - the Java attack seems to assume that a JMX server has not been configured to authenticate requests, can be connected to using RMI and has no class loader security manager.

I'm not sure this is really a problem with the Java language, or even the programmer. If I leave my front door wide open, I don't think I can blame the lock for failing to do its job.

[cautious_int]

Mill processors? Aren't they still in research stage, only using emulation and no hardware.

[serichsen]

> When those systems aren't well thought out or secure you have security issues.

All evidence says that there are no well thought out and secure systems written in C or C++.

If there is a way to do it, it has not been publicized yet.

[Timmons]

There are no secure systems written in ANY language (to my knowledge).

At the end of the day all computers and systems can be broken. Using C/C++ might open up that up to being more likely when someone isn't thoughtful enough in the implementation. The trade off comes in when you want to risk the higher chance of security problems for the better performance.

This is just my opinion, I believe that we spend way too much time writing in these 'safe' languages at the cost of performance when it often isn't really needed and in the long run just adds to the bloat of our systems. This comes from my belief that if anyone is willing to spend the time and money to break a system they will. So why are we burdening our piggy banks with the same security as our bank vaults?