5 ms·
I'm not sure I understand why one particular language would lend itself to more vulnerability than another. The less skilled someone is at a particular language
by akg 15y ago
I'm not sure I understand why one particular language would lend itself to more vulnerability than another. The less skilled someone is at a particular language, the more bugs/vulnerabilities he is likely to produce. It is a function of technical skill rather than a quality of the language.
For example a Ruby interpreter or a Java runtime that you trust to handle all your HTTP requests are prominently written in C/C++.
I think what makes popular packages like Ruby/Java/Rails (etc.) more secure is the sheer number of users they have. Those technologies have been hammered out over several projects and by a plethora of users and developers. Writing a component that rivals that number of interactions is tough, but certainly doable.
- simonw 15y ago"I'm not sure I understand why one particular language would lend itself to more vulnerability than another." http://en.wikipedia.org/wiki/Buffer_overflow http://en.wikipedia.org/wiki/Buffer_overflow From that page: "Programming languages commonly associated with buffer overflows include C and C++, which provide no built-in protection against accessing or overwriting data in any part of memory and do not automatically check that data written to an array (the built-in buffer type) is within the boundaries of that array."
- akg 15y agoI would call that a programmer error. The language certainly does make it harder to write "safe" code, but it is certainly doable. I guess my point is that the tools/libraries/frameworks on top of the language are what make it useful or not useful, independent of the language itself. For example, writing a web app in Ruby may not help you against SQL injection (http://en.wikipedia.org/wiki/SQL_injection http://en.wikipedia.org/wiki/SQL_injection) unless you have a well designed query language on top of that.
- tptacek 15y agoEveryone calls it programmer error. But when you make the same error of copying arbitrary-sized inputs from attackers into a Java program, you do not enable that attacker to upload their own code into the JVM process and run it.
- akg 15y agoBut doesn't the use of Java's JNI invalidate any security the JVM offers? As far as I know, any protections the JVM puts up are invalidated once you inject native code, which would potentially enable an attacker to potentially inject malicious code that hijacks the JVM. Then again, one could argue that the JNI is no longer a "Java" program.
- tptacek 15y agoYes, when you write C code and attach it to JVM processes, that puts the JVM process at risk. More C code, more problems.
- dextorious 15y ago"""I would call that a programmer error. The language certainly does make it harder to write "safe" code, but it is certainly doable.""" Everything is "certainly doable" in a turing-complete way, but that fact has not mattered at all in the evolution of programming languages. It doesn't matter if it's "certainly doable", what matters is how easy it is.
- tptacek 15y agoThere's one (mainstream) C Ruby that needs to be audited. But every C CGI program needs to be audited. C programs are susceptible to memory corruption. Programs written in practically every mainstream high level language are not susceptible to those problems (until they start using third-party C extensions). That's the security win of not using C code.
- deleted 15y ago[deleted]
- nl 15y agoThings like memory protection by default do make some languages safer than others.
- akg 15y agoYes, however, there are libraries in place that can circumvent some of these issues: e.g., boost::shared_ptr in C++.
- tptacek 15y agoNo, Boost shared_ptr exacerbates the issue by creating a second regime of reference counting that, if contravened anywhere in the program (for instance, in any third-party piece of library code, which every C++ program of any real size is replete with) creates use-after-free conditions. I invite you to continue coming up with examples of ways to reliably mitigate memory corruption flaws in C/C++ programs, because I enjoy this topic very much, but as your attorney in this matter I have to advise you that you're going to lose the argument. :)
- akg 15y agoAfter doing some research on the topic, I will have to say that I concede my point. ;-)
- roel_v 15y agoI agree with you on the gist of your argument (I think), but there are 'ways to reliably mitigate memory corruption flaws in C/C++ programs'. For example, using std::string rather than malloc()'ing a char* every time you do something that works with strings is certainly a way to reliably mitigate memory corruption flaws in C++.
- tptacek 15y agoTrue as far as it goes; std::string is safer than libc strings. If all your program does is manipulate strings, and not marshaled binary data structures or protocols, and your data structures are simple and you're very careful with your iterators (which themselves often decompose to pointers) and your object lifecycles are simple enough that you can reliably free things and know you're not going to accidentally touch the memory later, and-and-and, you can write a safe C++ program.
- akg 15y agoAfter doing some thorough research on the topic, I would like to say that I concede my point about the vulnerabilities of C/C++. Thanks tptacek.
- tptacek 15y agoHappy to help! :)