Any scope here for SSL companies to actually have to make good on warranties they offer here?
The Heartbleed Bug
511–520 of 547 posts
Re: The Heartbleed Bug
#512Heroku is working on it, but as of 07:02 UTC (30 mins ago) they have not released a fix: https://status.heroku.com/incidents/606
Since their own (status.heroku.com and heroku.com) certs are from 2013-10-03, this illustrates a bad situation post-heartbleed:
Were they using a 1.0.1* vulnerable OpenSSL, or not? or did they (unlikely but possible) not adequately fix the issue.
This is information only the service provider has, and thus poses a dilemma (in terms of transparency at least).
Here's hoping for the best.
Re: The Heartbleed Bug
#513Earlier quoted context omitted.
I've felt that C makes this code easy to write because it makes doing the right thing hard. What you are describing is just a lot of work in C, compared to a language with something akin to Java's generics, which are in turn an afterthought in the ML family of languages. What we're asking for is not that complicated from a PL standpoint. A generic streams library? Economics plays an invisible part here. Someone writi…
That's what I like about Ruby. ;) Even in C, Go or Python, I column align any text that is remotely similar, so differences are obvious. Clean code might be extra work but the net work (maintenance) should amortize less. Reducing cognitive load for large supportable production codebase cannot be underscored enough.
Re: The Heartbleed Bug
#514Earlier quoted context omitted.
> C and other languages without memory checks are unsuitable for writing secure code I vehemently disagree. Well-written C is very easy to audit. Much much moreso than languages like C# and Java, where something I could do with 200 lines in a single C source file requires 5 different classes in 5 different files. The problem with C is that a lot of people don't write it well. Have you looked at the OpenSSL source? It…
> The problem with C is that a lot of people don't write it well. Including people responsible for one of the most important security-related library in the world. No matter how good and careful a programmer is, they are still human and prone to errors. Why not put every chance on our side and use languages (e.g. Rust, Ada, ATS, etc.) that make entire classes of errors impossible? They won't fix all problems, and def…
> Why not put every chance on our side and use languages (e.g. Rust, Ada, ATS, etc.) that make entire classes of errors impossible?
Bugs will still occur, just in a different way: Java is advocated as being a much "safer" language, but how many exploits have we seen in the JRE? Going to more restrictive, more complex languages in an attempt to fix these problems will only lead to a neverending cycle of increasing ignorance and negligence, combined with even more restrictive languages and complexity. I believe the solution is in better education and diligence, and not technological.
Re: The Heartbleed Bug
#515Does linux sshd have this bug ?
Re: The Heartbleed Bug
#516Earlier quoted context omitted.
Do not like the term "C/C++", and especially in this context. Modern C++ makes avoiding this sort of bug as easy as doing so in the "managed" languages already discussed. This is as much a cultural as a technical problem; C really is in the last chance saloon for this sort of problem, we have the solution to hand, but a strong cadre of developers will still only consider C for this sort of work.
I don't think this is true. When it comes to copying bytes from a buffer supplied from the network, there isn't a wrapper/manager class that can do this for you. Somewhere down the pipeline some piece of code has to copy the unstructured, variable length byte stream into a manageable data structure. C++ does not give any way to do this beyond the mechanisms available in C.
What you can do is lower the surface area of vulnerability. Low level byte wrangling is kept in a small subset of generic classes and functions. Application logic then only uses the safe interfaces.
Re: The Heartbleed Bug
#517Earlier quoted context omitted.
Did you actually read my entire comment, or did you just see "C#" and post a knee-jerk reaction? If you extract code from C# to C, you don't need a GC or any of the .NET class libraries -- you'd just have a standalone C file to use like any other.
> If you extract code from C# to C, you don't need a GC or any of the .NET class libraries The problem is, you do need them. There's no 1:1 C# -> C extraction. You have to extract at least some part of the CLR along with.
Perhaps another way of saying this is that you will always need a runtime. And if you reimplement the portions of the runtime that you need in C, you've essentially re-implemented .NET.
Re: The Heartbleed Bug
#518Earlier quoted context omitted.
> The problem with C is that a lot of people don't write it well. Including people responsible for one of the most important security-related library in the world. No matter how good and careful a programmer is, they are still human and prone to errors. Why not put every chance on our side and use languages (e.g. Rust, Ada, ATS, etc.) that make entire classes of errors impossible? They won't fix all problems, and def…
> Why not put every chance on our side and use languages (e.g. Rust, Ada, ATS, etc.) that make entire classes of errors impossible? Bugs will still occur, just in a different way: Java is advocated as being a much "safer" language, but how many exploits have we seen in the JRE? Going to more restrictive, more complex languages in an attempt to fix these problems will only lead to a neverending cycle of increasing ign…
> Java is advocated as being a much "safer" language, but how many exploits have we seen in the JRE?
Very few. I don't think I can remember ever seeing an advisory for Java's SSL implementation.
Yes, bugs are possible in all languages, but that doesn't mean there's no difference between languages. I'm reminded of Asimov: "When people thought the earth was flat, they were wrong. When people thought the earth was spherical, they were wrong. But if you think that thinking the earth is spherical is just as wrong as thinking the earth is flat, then your view is wronger than both of them put together."
(There are a large number of bugs in the browser plugin used for java applets, but they have no relation to the JRE itself)
Re: The Heartbleed Bug
#519I haven't seen a discussion about whether this can also bypass those using 2-step verification. Does anyone here know?
Re: The Heartbleed Bug
#520Who the hell went through the trouble of buying a domain name, building a website, and designing a logo just to talk about one bug?
Someone who wanted to be sure that bug stuck in people's minds enough that they wouldn't just ignore it? Seems at least feasible.