[trippy_biscuits]

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_...

[Ded7xSEoPKYNsDd]

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

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

[Already__Taken]

Isn't this exactly what SELinux does but nobody bothers to configure the rules?

[jiffytick]

But sandboxing does nothing to protect information if the information resides in the sandbox (sandboxing wouldn't have stopped heartbleed).

Rust and friends would aren't going to make all securty issues go away, just as sandboxing would not. There is no one true silver bullet in securty, at least not yet.

[Ded7xSEoPKYNsDd]

> This is actually kind of a point for the other side.

I wanted to move the goalpost from "Java is insecure" to "the Java sandbox is insecure". I completely agree with the second statement, so I don't think I made a point for any other side.

[trippy_biscuits]

You made the point that I was trying to make: implementations are not secure. A programming language can follow a philosophy but implementations never quite line up with the theory. We only use implementations of the theory and experience shows that implementations all have vulnerabilities.

[Ded7xSEoPKYNsDd]

I'm sorry if I misrepresented your post, but I feel you do the same to mine. I didn't say the JVM is insecure - I said the sandboxing part of the JVM is insecure and C++ doesn't have anything comparable.

[xorcist]

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]

> a malfunctioning sandbox is worse than useless

Are there any sandboxes in existence which are definitely not worse than useless?

[xorcist]

seccomp is simple and useful, in both incarnations.

[lbarrow]

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]

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

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

[seanwilson]

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]

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

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

[seanwilson]

My point is simply that every programmer will make mistakes when coding so I want the most automated assistance possible to point out those mistakes. If a programmer has a pressing need and the persistence to work around those checks, that's fine, at least the surface area for those mistakes are then limited to a smaller amount of code.

[Dewie]

From comments I read about that when it was written, it's not clear to me that the author actually demonstrated the same behaviour of Heartbleed. I'm not the person to be the judge of that, but for what it's worth here is the top comment from /r/rust on the topic. Then you can make up your own mind about that.

https://www.reddit.com/r/rust/comments/2uii0u/heartbleed_in_...

[weland]

That comment sort of illustrates my point:

> You should note that Rust does not allow unintialized value by design and thus it does prevent heartbleed from happening. But indeed no programming language will ever prevent logic bugs from happening.

Under OpenBSD, that values would not have been uninitialized, were it not for OpenSSL's silly malloc wrapper -- a contraption of the sort that, if they really wanted, they could probably implement on top of Rust as well. What is arguably a logic mistake compromised the protection of a runtime that, just like Rust, claimed that it would not allow uninitialized values, "by design".

Of course, idiomatic Rust code would not fall into that trap -- but then arguably neither would idiomatic C code. It's true that Rust also enforces some of the traits of its idioms (unlike C), but as soon as -- like the OpenSSL developers did in C, or like Unangst did in that trivial example -- you start making up your own, there's only that much the compiler can do.

At the end of the day, the only thing that is 100% efficient is writing correct code. Better languages help, but it's naive to hope they'll put an end to bugs like these when they haven't put an end to many other trivial bugs that we keep on making since the days of EDSAC and Z3.

[Dewie]

> Under OpenBSD, that values would not have been uninitialized, were it not for OpenSSL's silly malloc wrapper -- a contraption of the sort that, if they really wanted, they could probably implement on top of Rust as well. What is arguably a logic mistake compromised the protection of a runtime that, just like Rust, claimed that it would not allow uninitialized values, "by design".

I really disagree. Rust does not allow uninitialized values by design - end of story. If a piece of Rust code let's uninitialized values bleed through, then it is broken. The semantics of Rust demands this.

(OpenSSL on the other hand only broke/Overrode OpenBSD's malloc - they didn't break C.)

It is news to no one that you can break - break - Rust's semantics if you use anything that demands `unsafe`. That's why anyone who uses `unsafe` and intends to wrap that `unsafe` in a safe interface has to be very careful.

Complaining about Rust being unsafe - in the specific sense that the Rust devs use - by using the `unsafe` construct, is like complaining that Haskell is impure because you can use `unsafePerformIO` to `launchMissiles` from a non-IO context.

> Of course, idiomatic Rust code would not fall into that trap -- but then arguably neither would idiomatic C code.

It's not even a question of being idiomatic. If someone codes in safe (non-`unsafe`) Rust, then they should not fall into the trap that you describe. If they do, then someone who implemented something in an `unsafe` block messed up and broke Rust's semantics.

What if that same thing happened in C? Well, then it's just another bug.

---

I'd bet you'd be willing to take it to its next step, even if we assume that a language is 100% safe from X no matter what the programmer does - "what if the compiler implementation is broken?". And down the rabbit hole we go.

[weland]

> I really disagree. Rust does not allow uninitialized values by design - end of story. If a piece of Rust code let's uninitialized values bleed through, then it is broken. The semantics of Rust demands this. (OpenSSL on the other hand only broke/Overrode OpenBSD's malloc - they didn't break C.)

I'm not familiar enough with Rust (mostly on account of being more partial to Go...), so I will gladly stand corrected if I'm missing anything here.

If the OpenSSL did the same thing they did in C -- implement their own, custom allocator over a pre-allocated memory region, would anything in Rust prevent them from the same sequence of events? That is:

1. Program receives a packet and wants 100 bytes of memory for it. 2. It asks custom_allocator to give it a 100 byte chunk. custom_allocator gives it a fresh 100 byte chunk, which is correctly initialized because this is Rust. 3. Program is done with that chunk... 4. ...but custom_allocator is not. It marks the 100 byte chunk as free for it to use them again, but continues to retain ownership and does not clear its contents. 5. Program receives a packet that claims it has 100 bytes of payload, so it asks custom_allocator to give it a chunk of 100 bytes. custom_allocator gives it the same chunk as before, without asking the Rust runtime for another (initialized!) chunk. Program is free to roam around those 100 bytes, too.

I.e. the semantics of Rust do not allow for data to be uninitialized, but custom_allocator sidesteps that.

[rakoo]

> 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

[Dewie]

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.