Hacker News new | ask | show | jobs
by bowlofstew 3966 days ago
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....

2 comments

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.

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