6 ms·

The equivalent errors in dynamically typed languages don't lead to critical security vulnerabilities like they do in C. You get a nice exception and a clean cr

by jfager 14y ago

The equivalent errors in dynamically typed languages don't lead to critical security vulnerabilities like they do in C. You get a nice exception and a clean crash, not a hook to grab root.

PommeDeTerre 14y ago
Realistically, just about every mainstream dynamic language today has its major implementation(s) written using C or C++. Some of them have significant amounts of C code underlying their common libraries, as well. Some of the most popular third-party libraries or modules are in fact nothing more than thin wrappers over existing C or C++ code. Don't think that you're escaping C or C++ just because you're using Ruby, or JavaScript, or Python, or Perl, or Tcl, or even Java. Don't think that you aren't as vulnerable using a dynamic language as you are using C or C++ directly. Furthermore, it is quite easy for dynamically typed languages to suffer from very serious security vulnerabilities. There was one affecting Ruby and Ruby on Rails widely publicized just a few days ago. You can read more about it at: http://news.ycombinator.com/item?id=5002006 http://news.ycombinator.com/item?id=5002006
- pretoriusB 14y ago
  >Don't think that you're escaping C or C++ just because you're using Ruby, or JavaScript, or Python, or Perl, or Tcl, or even Java. Don't think that you aren't as vulnerable using a dynamic language as you are using C or C++ directly. Actually this is completely backwards. Think exactly that you are NOT AS vulnerable as using C or C++ directly. That it's C/C++ underneath has little importance. It FAR MORE difficult and FAR LESS common to reach runtime/interpreter bugs that to produce bugs of your own in the higher level language. >Furthermore, it is quite easy for dynamically typed languages to suffer from very serious security vulnerabilities. Of a different kind, that doesn't pertain to the current discussion.
- zxcdw 14y ago
  But the beauty of modern programming languages is that the responsibility has gone from sole programmers to actual implementation developers. You would expect that people who implement the runtmies and libraries are far, far more knowledgeable, experienced and trustworthy. And it often is so -- the end user(programmer) can't be trusted to know all about security implications, possible vulberabilities let alone how to exploit them! The whole idea that "Well it's insecure because you program in insecure way!" is outright idiotic, and should be killed. If that means getting rid of C and C++ and people who write in these languages(Hey, myself included!) then so be it. The faster the better. Sure, there are cases in which it's hardly possible, but I'd take 10 times slower computer for 1) fewer bugs 2) more advanced software 3) cheaper software 4) far less security concerns any day. Now, I'm going to close the C++ project and go write some Python. Makes me feel happy and far less stressed, although C++ does damn well in comparison to C.
  - PommeDeTerre 14y ago
    But using a language like Ruby or PHP, for instance, doesn't really lead to fewer bugs, or more advanced software, or cheaper software, or fewer security concerns in practice. What it often actually leads to is untalented developers creating a lot of bug-ridden and vulnerable code extremely quickly. It's efficiency in all the wrong ways. Do you remember that Diaspora social networking project that received a lot of hype a couple of years ago? It was a Ruby on Rails app, and the early releases were absolutely filled with some particularly nasty bugs and security flaws. The only reason they were eventually fixed is because the code was made public, and people pointed out these flaws. There is a lot of Ruby code out there, for instance, that isn't public, yet is still riddled with the same types of problems. That's not to say that the same isn't true for Python, or Java, or C#, or C++, or any other language. But we shouldn't be claiming that using a language like Ruby or Python somehow leads to more secure code. It doesn't, and it's dangerous to think that it does.
    - zxcdw 14y ago
      > But using a language like Ruby or PHP, for instance, doesn't really lead to fewer bugs, or more advanced software, or cheaper software, or fewer security concerns in practice. Which domain are we talking about? Of course web-based applications have their own problems, but imagine if idiomatic Ruby or PHP code was vulberable to buffer overflows, double-free/use-after-free or format string vulnerabilities on top of the current problems, would you still say that languages don't matter when it comes to software development problems and issues? Essentially, what you're saying is that modern programming languages aren't any more better in practice in said regards than C. Honestly? Of course no language can prevent outright bad code, but a language, by it's design, can eliminate issues related to for example type safety and memory safety. Consider Rust as an example of this. What this means in practice is that the language by it's design manages to eliminate these issues. Code is less prone to bugs and has no security concerns related to these issues. More time for validating correct behavior and fixing misbehaving parts. > But we shouldn't be claiming that using a language like Ruby or Python somehow leads to more secure code. It doesn't, and it's dangerous to think that it does. What on earth am I reading? What are the equivalents to buffer overflow or format string vulnerability in Python or Ruby? How do I execute arbitrary machine code with Python or Ruby if malicious input is given to the vulnerable program?
- eru 14y ago
  Why not use a modern statically typed language instead?
- rimantas 14y ago
  > There was one affecting Ruby and Ruby on Rails What has it to do with Ruby, besides the fact that RoR is written in Ruby?
Evbn 14y ago
So they have infinity minus one problems. You still have critical systems crashing or silently misbehaving.

by jfager 14y ago

The equivalent errors in dynamically typed languages don't lead to critical security vulnerabilities like they do in C. You get a nice exception and a clean crash, not a hook to grab root.

PommeDeTerre 14y ago

Realistically, just about every mainstream dynamic language today has its major implementation(s) written using C or C++. Some of them have significant amounts of C code underlying their common libraries, as well. Some of the most popular third-party libraries or modules are in fact nothing more than thin wrappers over existing C or C++ code. Don't think that you're escaping C or C++ just because you're using Ruby, or JavaScript, or Python, or Perl, or Tcl, or even Java. Don't think that you aren't as vulnerable using a dynamic language as you are using C or C++ directly. Furthermore, it is quite easy for dynamically typed languages to suffer from very serious security vulnerabilities. There was one affecting Ruby and Ruby on Rails widely publicized just a few days ago. You can read more about it at: http://news.ycombinator.com/item?id=5002006 http://news.ycombinator.com/item?id=5002006

pretoriusB 14y ago
>Don't think that you're escaping C or C++ just because you're using Ruby, or JavaScript, or Python, or Perl, or Tcl, or even Java. Don't think that you aren't as vulnerable using a dynamic language as you are using C or C++ directly. Actually this is completely backwards. Think exactly that you are NOT AS vulnerable as using C or C++ directly. That it's C/C++ underneath has little importance. It FAR MORE difficult and FAR LESS common to reach runtime/interpreter bugs that to produce bugs of your own in the higher level language. >Furthermore, it is quite easy for dynamically typed languages to suffer from very serious security vulnerabilities. Of a different kind, that doesn't pertain to the current discussion.
zxcdw 14y ago
But the beauty of modern programming languages is that the responsibility has gone from sole programmers to actual implementation developers. You would expect that people who implement the runtmies and libraries are far, far more knowledgeable, experienced and trustworthy. And it often is so -- the end user(programmer) can't be trusted to know all about security implications, possible vulberabilities let alone how to exploit them! The whole idea that "Well it's insecure because you program in insecure way!" is outright idiotic, and should be killed. If that means getting rid of C and C++ and people who write in these languages(Hey, myself included!) then so be it. The faster the better. Sure, there are cases in which it's hardly possible, but I'd take 10 times slower computer for 1) fewer bugs 2) more advanced software 3) cheaper software 4) far less security concerns any day. Now, I'm going to close the C++ project and go write some Python. Makes me feel happy and far less stressed, although C++ does damn well in comparison to C.
- PommeDeTerre 14y ago
  But using a language like Ruby or PHP, for instance, doesn't really lead to fewer bugs, or more advanced software, or cheaper software, or fewer security concerns in practice. What it often actually leads to is untalented developers creating a lot of bug-ridden and vulnerable code extremely quickly. It's efficiency in all the wrong ways. Do you remember that Diaspora social networking project that received a lot of hype a couple of years ago? It was a Ruby on Rails app, and the early releases were absolutely filled with some particularly nasty bugs and security flaws. The only reason they were eventually fixed is because the code was made public, and people pointed out these flaws. There is a lot of Ruby code out there, for instance, that isn't public, yet is still riddled with the same types of problems. That's not to say that the same isn't true for Python, or Java, or C#, or C++, or any other language. But we shouldn't be claiming that using a language like Ruby or Python somehow leads to more secure code. It doesn't, and it's dangerous to think that it does.
  - zxcdw 14y ago
    > But using a language like Ruby or PHP, for instance, doesn't really lead to fewer bugs, or more advanced software, or cheaper software, or fewer security concerns in practice. Which domain are we talking about? Of course web-based applications have their own problems, but imagine if idiomatic Ruby or PHP code was vulberable to buffer overflows, double-free/use-after-free or format string vulnerabilities on top of the current problems, would you still say that languages don't matter when it comes to software development problems and issues? Essentially, what you're saying is that modern programming languages aren't any more better in practice in said regards than C. Honestly? Of course no language can prevent outright bad code, but a language, by it's design, can eliminate issues related to for example type safety and memory safety. Consider Rust as an example of this. What this means in practice is that the language by it's design manages to eliminate these issues. Code is less prone to bugs and has no security concerns related to these issues. More time for validating correct behavior and fixing misbehaving parts. > But we shouldn't be claiming that using a language like Ruby or Python somehow leads to more secure code. It doesn't, and it's dangerous to think that it does. What on earth am I reading? What are the equivalents to buffer overflow or format string vulnerability in Python or Ruby? How do I execute arbitrary machine code with Python or Ruby if malicious input is given to the vulnerable program?
eru 14y ago
Why not use a modern statically typed language instead?
rimantas 14y ago
> There was one affecting Ruby and Ruby on Rails What has it to do with Ruby, besides the fact that RoR is written in Ruby?

Evbn 14y ago

So they have infinity minus one problems. You still have critical systems crashing or silently misbehaving.