5 ms·

Do people really believe in more secure languages? Are they the same people that think switches make networks secure? Switches don't and neither does a given

Do people really believe in more secure languages? Are they the same people that think switches make networks secure? Switches don't and neither does a given language. I recall a CTO that would not allow C++ development because he thought the language was insecure. Java was the only language allowed. Even college courses are still teaching that security is one of the benefits of the virtual machine. We only have to look at all the patches for java to see that it hasn't been secure. Then we look at every other software that has been patched to see that nothing is secure. Please stop perpetuating the myth that security is produced by a programming language. People make security happen just like they make it not happen. Obligatory Schneier: https://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html https://www.schneier.com/blog/archives/2008/03/the_security_...

lbarrow 12y ago
I don't think security is produced by picking one language or another, but I do believe that it's harder to write secure code in a language like C than a language like Java or Rust. There are simply way, way more ways to shoot yourself in the foot.
- AnthonyMouse 12y ago
  > I don't think security is produced by picking one language or another, but I do believe that it's harder to write secure code in a language like C than a language like Java or Rust. There are simply way, way more ways to shoot yourself in the foot. The trouble is that everything is a trade off. It's very hard to get a buffer overrun in Java but that doesn't make Java a good language. It tries so hard to keep you from hanging yourself that it won't let you have any rope, so in the instances when you actually need rope you're forced to create your own and hang yourself with that. For example, you're presented with garbage collection and then encouraged to ignore object lifetime. There are no destructors to clean up when an object goes out of scope. But when it does you still have to cleanup open files or write records to the database or notify network peers etc. Which leaves you to have to manage it manually and out of order, leading to bugs and race conditions. In other words, C and C++ encourage you to write simple dangerous bugs while Java encourages you to write complicated dangerous bugs. That isn't to say that some languages don't have advantages over others, but rather that the differences aren't scalar. And code quality is by far more important than the choice of language. BIND would still be less secure than djbdns even if it was written in Java.
- caf 12y ago
  Not that this really proves anything one way or the other, but remember that in regard to the Java SSL implementation shipping with the JDK, it was very recently found that: "...the JSSE implementation of TLS has been providing virtually no security guarantee (no authentication, no integrity, no confidentiality) for the past several years."
Dewie 12y ago
Is 'security' really something that requires faith or belief? It seems that "more secure" (not secure in an absolute sense) can be made tangible, and I think that programming languages can give you "more security", in the sense that they close off certain possibilities or make them much harder to exploit/mess up. Not that I know about security, but all you're doing right now is to fend off the claim of "more secure" by stating that java is not secure in an absolute sense - no one has claimed absolute security, only relatively more.
seanwilson 12y ago
I don't understand this argument. For example, if I use a language that doesn't allow buffer overflows to happen, I've eliminated an entire class of security bugs being caused by programmer error. Why would you not want to use such a language? Performance and existing libraries will factor in to this obviously but I don't understand why you wouldn't consider security built into the language as a benefit. Yes, security issues are found in Java and every other language, but when these are patched all programs that use that language are patched against the issue. The attack surface is much smaller.
- AnthonyMouse 12y ago
  > Yes, security issues are found in Java and every other language, but when these are patched all programs that use that language are patched against the issue. The attack surface is much smaller. All patches work like that; when there is a bug in libssl and OpenSSL patches it then all the programs using libssl are patched. The difference with Java is that when a C library has a bug only programs using that library are exposed but when Java has a bug all Java programs are exposed. Moreover, Java itself is huge. It's an enormous attack surface. Your argument would hold more weight if the "much smaller" attack surface actually produced a scarcity of vulnerabilities.
- weland 12y ago
  > For example, if I use a language that doesn't allow buffer overflows to happen, I've eliminated an entire class of security bugs being caused by programmer error. There are several assumptions behind "if I use a language that doesn't allow buffer overflows to happen" which you aren't taking into account. For instance, are you entirely sure that the implementation of that language's compiler will not allow buffer overflows to happen? We have a good example of a possible failure of that model in Heartbleed: when it came up, a bunch of people in the OpenBSD community raised their eyebrows, thinking hmm, that shouldn't happen for us, we have mitigation techniques for that. Turns out -- for performance reasons -- OpenSSL was implementing its own wrappers over native malloc() and free(), doing some caching of its own. This, in turn, rendered OpenBSD's own prevention mechanisms (e.g. overwriting malloc()-ed areas before using them) useless. The language specifications may not allow such behaviour, but that doesn't mean the implementation won't, too. You're also underestimating a programmer's ability to shoot himself in the foot. Since I already mentioned OpenBSD and Heartbleed, here's a good example of a Heartbleed-like bug in Rust: http://www.tedunangst.com/flak/post/heartbleed-in-rust http://www.tedunangst.com/flak/post/heartbleed-in-rust . The sad truth is that most vulnerabilities like this one don't stem from accidental mistakes that languages could have prevented; they stem from fundamental misunderstanding of the mode of operation which are otherwise safe constructs in their respective languages. Granted, this isn't a buffer overflow, which, in a language that doesn't allow arbitrary writes, would be an incorrect construct and would barf at runtime, if not at compile time; but then my remark about bugs above still stands (and I'm not talking out of my ass, I've seen buggy code produced by an Ada compiler allowing this to happen), buffer overflows can be increasingly well mitigated with ASLR, and the increased complexity in the language runtime is, in and by itself, an increased attack surface. Edit: just to be clear, I do think writing software in a language like Go or Rust would do away with the most trivial security issues (like blatant buffer overflows) -- and that is, in itself, a gain. However, those are also the kind of security issues that are typically resolved within months of the first release. Most of the crap that shows up five, ten, fifteen years after the first release is in perfectly innocent-looking code, which the compiler could infer to be a mistake only if it "knew" what the programmer actually wanted to achieve.
Ded7xSEoPKYNsDd 12y ago
> We only have to look at all the patches for java to see that it hasn't been secure. All those big security issues aren't in the Java language, they are in the JVM running untrusted Java byte code. Not to say that situation isn't bad, but you can't compare it to C++ because nobody ever thought running untrusted C++ code without some other sandboxing was a good idea. That aside, memory safety is great for security. Of course there are 1000 other things that are important, too, and so I'd trust a C program written by a security expert much more then the same program written by someone who thinks his program is secure because he used Java. But I'd feel even better if the security expert used a memory-safe language because I am certain that all C programs above a certain size are vulnerable to memory attacks.
- AnthonyMouse 12y ago
  > Not to say that situation isn't bad, but you can't compare it to C++ because nobody ever thought running untrusted C++ code without some other sandboxing was a good idea. This is actually kind of a point for the other side. You can sandbox code regardless of what language it's written in. Maybe what we need is not better languages but better sandboxes. Even when code is "trusted", if the developer knows it doesn't need to e.g. write to the filesystem or bind any sockets then it should never do those things and if it does the OS should deny access if not kill it immediately.
  - xorcist 12y ago
    True, and a malfunctioning sandbox is worse than useless. People tend to base security on them. Google did in their AppEngine cloud, but they put a lot of engineering resources and defence-in-depth behind it.
    - Padding 12y ago
      > a malfunctioning sandbox is worse than useless Are there any sandboxes in existence which are definitely not worse than useless?
      - 12y ago
rakoo 12y ago
> Please stop perpetuating the myth that security is produced by a programming language. Security happens by taking care of what you're doing; if a language can eliminate a whole class of bugs then you might as well use it. That's why people keep arguing that some languages can eliminate some kind of bugs, but that absolutely doesn't make programs implemented in these languages bug-free. Said differently: more secure (relatively) doesn't mean secure (in absolute). > We only have to look at all the patches for java to see that it hasn't been secure. We only have to look at all the patches for java to see how much it is analyzed; it doesn't mean java is relatively more or less secure than any other language. I've seen no patches for this nim interpreter for brainfuck [0], does that mean it's more secure than java ? Absolutely not. You can draw some parallel with crypto schemes: anybody can come up with some cipher, nobody will analyze it unless there is something to gain (that includes fun). When you've reached the state where you're under scrutiny of every crypto analyst and their student, and potential vulnerabilities are found, does that make it a weak scheme ? We don't know. Only a real analysis of the vulnerabilities can tell us. [0] https://github.com/def-/nim-brainfuck https://github.com/def-/nim-brainfuck

lbarrow 12y ago

I don't think security is produced by picking one language or another, but I do believe that it's harder to write secure code in a language like C than a language like Java or Rust. There are simply way, way more ways to shoot yourself in the foot.

AnthonyMouse 12y ago
> I don't think security is produced by picking one language or another, but I do believe that it's harder to write secure code in a language like C than a language like Java or Rust. There are simply way, way more ways to shoot yourself in the foot. The trouble is that everything is a trade off. It's very hard to get a buffer overrun in Java but that doesn't make Java a good language. It tries so hard to keep you from hanging yourself that it won't let you have any rope, so in the instances when you actually need rope you're forced to create your own and hang yourself with that. For example, you're presented with garbage collection and then encouraged to ignore object lifetime. There are no destructors to clean up when an object goes out of scope. But when it does you still have to cleanup open files or write records to the database or notify network peers etc. Which leaves you to have to manage it manually and out of order, leading to bugs and race conditions. In other words, C and C++ encourage you to write simple dangerous bugs while Java encourages you to write complicated dangerous bugs. That isn't to say that some languages don't have advantages over others, but rather that the differences aren't scalar. And code quality is by far more important than the choice of language. BIND would still be less secure than djbdns even if it was written in Java.
caf 12y ago
Not that this really proves anything one way or the other, but remember that in regard to the Java SSL implementation shipping with the JDK, it was very recently found that: "...the JSSE implementation of TLS has been providing virtually no security guarantee (no authentication, no integrity, no confidentiality) for the past several years."

Dewie 12y ago

Is 'security' really something that requires faith or belief? It seems that "more secure" (not secure in an absolute sense) can be made tangible, and I think that programming languages can give you "more security", in the sense that they close off certain possibilities or make them much harder to exploit/mess up. Not that I know about security, but all you're doing right now is to fend off the claim of "more secure" by stating that java is not secure in an absolute sense - no one has claimed absolute security, only relatively more.

seanwilson 12y ago

I don't understand this argument. For example, if I use a language that doesn't allow buffer overflows to happen, I've eliminated an entire class of security bugs being caused by programmer error. Why would you not want to use such a language? Performance and existing libraries will factor in to this obviously but I don't understand why you wouldn't consider security built into the language as a benefit. Yes, security issues are found in Java and every other language, but when these are patched all programs that use that language are patched against the issue. The attack surface is much smaller.

AnthonyMouse 12y ago
> Yes, security issues are found in Java and every other language, but when these are patched all programs that use that language are patched against the issue. The attack surface is much smaller. All patches work like that; when there is a bug in libssl and OpenSSL patches it then all the programs using libssl are patched. The difference with Java is that when a C library has a bug only programs using that library are exposed but when Java has a bug all Java programs are exposed. Moreover, Java itself is huge. It's an enormous attack surface. Your argument would hold more weight if the "much smaller" attack surface actually produced a scarcity of vulnerabilities.
weland 12y ago
> For example, if I use a language that doesn't allow buffer overflows to happen, I've eliminated an entire class of security bugs being caused by programmer error. There are several assumptions behind "if I use a language that doesn't allow buffer overflows to happen" which you aren't taking into account. For instance, are you entirely sure that the implementation of that language's compiler will not allow buffer overflows to happen? We have a good example of a possible failure of that model in Heartbleed: when it came up, a bunch of people in the OpenBSD community raised their eyebrows, thinking hmm, that shouldn't happen for us, we have mitigation techniques for that. Turns out -- for performance reasons -- OpenSSL was implementing its own wrappers over native malloc() and free(), doing some caching of its own. This, in turn, rendered OpenBSD's own prevention mechanisms (e.g. overwriting malloc()-ed areas before using them) useless. The language specifications may not allow such behaviour, but that doesn't mean the implementation won't, too. You're also underestimating a programmer's ability to shoot himself in the foot. Since I already mentioned OpenBSD and Heartbleed, here's a good example of a Heartbleed-like bug in Rust: http://www.tedunangst.com/flak/post/heartbleed-in-rust http://www.tedunangst.com/flak/post/heartbleed-in-rust . The sad truth is that most vulnerabilities like this one don't stem from accidental mistakes that languages could have prevented; they stem from fundamental misunderstanding of the mode of operation which are otherwise safe constructs in their respective languages. Granted, this isn't a buffer overflow, which, in a language that doesn't allow arbitrary writes, would be an incorrect construct and would barf at runtime, if not at compile time; but then my remark about bugs above still stands (and I'm not talking out of my ass, I've seen buggy code produced by an Ada compiler allowing this to happen), buffer overflows can be increasingly well mitigated with ASLR, and the increased complexity in the language runtime is, in and by itself, an increased attack surface. Edit: just to be clear, I do think writing software in a language like Go or Rust would do away with the most trivial security issues (like blatant buffer overflows) -- and that is, in itself, a gain. However, those are also the kind of security issues that are typically resolved within months of the first release. Most of the crap that shows up five, ten, fifteen years after the first release is in perfectly innocent-looking code, which the compiler could infer to be a mistake only if it "knew" what the programmer actually wanted to achieve.

Ded7xSEoPKYNsDd 12y ago

> We only have to look at all the patches for java to see that it hasn't been secure. All those big security issues aren't in the Java language, they are in the JVM running untrusted Java byte code. Not to say that situation isn't bad, but you can't compare it to C++ because nobody ever thought running untrusted C++ code without some other sandboxing was a good idea. That aside, memory safety is great for security. Of course there are 1000 other things that are important, too, and so I'd trust a C program written by a security expert much more then the same program written by someone who thinks his program is secure because he used Java. But I'd feel even better if the security expert used a memory-safe language because I am certain that all C programs above a certain size are vulnerable to memory attacks.

AnthonyMouse 12y ago
> Not to say that situation isn't bad, but you can't compare it to C++ because nobody ever thought running untrusted C++ code without some other sandboxing was a good idea. This is actually kind of a point for the other side. You can sandbox code regardless of what language it's written in. Maybe what we need is not better languages but better sandboxes. Even when code is "trusted", if the developer knows it doesn't need to e.g. write to the filesystem or bind any sockets then it should never do those things and if it does the OS should deny access if not kill it immediately.
- xorcist 12y ago
  True, and a malfunctioning sandbox is worse than useless. People tend to base security on them. Google did in their AppEngine cloud, but they put a lot of engineering resources and defence-in-depth behind it.
  - Padding 12y ago
    > a malfunctioning sandbox is worse than useless Are there any sandboxes in existence which are definitely not worse than useless?
    - 12y ago

rakoo 12y ago

> Please stop perpetuating the myth that security is produced by a programming language. Security happens by taking care of what you're doing; if a language can eliminate a whole class of bugs then you might as well use it. That's why people keep arguing that some languages can eliminate some kind of bugs, but that absolutely doesn't make programs implemented in these languages bug-free. Said differently: more secure (relatively) doesn't mean secure (in absolute). > We only have to look at all the patches for java to see that it hasn't been secure. We only have to look at all the patches for java to see how much it is analyzed; it doesn't mean java is relatively more or less secure than any other language. I've seen no patches for this nim interpreter for brainfuck [0], does that mean it's more secure than java ? Absolutely not. You can draw some parallel with crypto schemes: anybody can come up with some cipher, nobody will analyze it unless there is something to gain (that includes fun). When you've reached the state where you're under scrutiny of every crypto analyst and their student, and potential vulnerabilities are found, does that make it a weak scheme ? We don't know. Only a real analysis of the vulnerabilities can tell us. [0] https://github.com/def-/nim-brainfuck https://github.com/def-/nim-brainfuck