I've built a web tester for this bug, find it at http://filippo.io/Heartbleed/ It actually exploit the bug, since it was quite trivial, and echo some memory. It's written in Go, no more than 100 lines. I'll release code in some time.
Interestingly, your tool claims our website (SSL-terminated at our ELB instance) is still vulnerable; while this other tool (http://possible.lv/tools/hb) claims we are unaffected.
Another, known unpatched, app is reported to be affected by both tools.
Is it possible that FiloSottile/Hearbleed may report false positives?
I've built a web tester for this bug, find it at http://filippo.io/Heartbleed/ It actually exploit the bug, since it was quite trivial, and echo some memory. It's written in Go, no more than 100 lines. I'll release code in some time.
Exactly what I was looking for, thanks! This should be part of the official heartbleed site not hidden away in comments here.
>The problem with C is that a lot of people don't write it well. There are languages that make it very very hard to write bad code. Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. C is a language that doesn't offer many advantages but offers very many disadvantages for its weak assurances. Things like the Haskell compiler show that you can get strong typing…
> Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. I really wish people would stop saying this. It's not in the slightest bit true. Making this assertion makes Haskellers seem dangerously naive.
This is especially true in the field of crypto, where timing attacks are a major issue. Knowing that your program will produce the correct result isn't enough, you need to know that the amount of time taken to compute that result doesn't leak information, and I don't think Haskell provides any way to ensure this.
I've built a web tester for this bug, find it at http://filippo.io/Heartbleed/ It actually exploit the bug, since it was quite trivial, and echo some memory. It's written in Go, no more than 100 lines. I'll release code in some time.
Would love to see the code and test it against a rebuilt a patched nginx.
Would you be somewhat better protected i.e. (not loosing private keys, etc) if your machine sat behind a load balancer ? The memory exposed would be that of the load balancer correct ?
Depends on if the LB was doing the SSL termination (offload). But still, the private keys are at risk. There are worse scenarios, but just barely. You were using [EC]DHE cipher suites, weren't you?
Its only a development environment so my risk is fairly low, However I was just curious, its an Amazon ELB.
There's no "just use X" type of answer in security. Sep 2013 "All versions of the open source Ruby on Rails Web application framework released in the past six years have a critical vulnerability that an attacker could exploit to execute arbitrary code, steal information from databases and crash servers." https://groups.google.com/forum/#!topic/rubyonrails-security... Nov 2013 "A lingering security issue in Ruby on Ra…
Rails does plenty of "make life easier for the programmer" things that I would expect to increase the risk of security issues. Do you have those kind of problems for e.g. Haskell?
Haskell problably has/would have the same kind of problems, but finding examples will be a lot harder in the absence of large well-used web platform à la RoR
I've built a web tester for this bug, find it at http://filippo.io/Heartbleed/ It actually exploit the bug, since it was quite trivial, and echo some memory. It's written in Go, no more than 100 lines. I'll release code in some time.
It says that the heartbleed.com site itself is vulnerable.
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.
There's no "just use X" type of answer in security. Sep 2013 "All versions of the open source Ruby on Rails Web application framework released in the past six years have a critical vulnerability that an attacker could exploit to execute arbitrary code, steal information from databases and crash servers." https://groups.google.com/forum/#!topic/rubyonrails-security... Nov 2013 "A lingering security issue in Ruby on Ra…