Unfortunately this test may give false positives because it is based only
on the version number.
Many Linux distribution will add a patch over the existing OpenSSL code,
without changing the version number.
Also the version check doesn't seem to work correctly because it is mostly
an API version more than an implementation number. So the version may stay
the same even if the binary of the library is updated with new code.

In my own check, I'm using an additional heuristic to check the build date.
https://gist.github.com/dolmen/10096474

Anyway, a proper check for heartbleed would really test the implementation
using real calls to the openssl API, exchanging real packets, using
inspiration from PaceMaker. But that's too much for my skills.
https://github.com/Lekensteyn/pacemaker



2014-04-16 23:46 GMT+02:00 A. Sinan Unur <na...@cpan.org>:

> *** Apologies if this message arrives on the mailing list twice, it's
> been about 45 minutes since I sent the first one, so I am assuming
> something went wrong with that ***
>
> Hello:
>
> I am the current maintainer of Crypt::SSLeay which provides HTTPS
> support using OpenSSL to LWP::UserAgent.
>
> In version 0.65_13, I added the plumbing and a test to check if the
> OpenSSL library against which Crypt::SSLeay was being built was
> vulnerable to the Heartbleed Bug.
>
> As of now, there are 36 fails for the 50 testers who ran this test.
> That is, those testers had a version of OpenSSL that is vulnerable to
> the Heartbleed Bug.
>
> It was good to see the failures as it showed the test actually did its
> job, but I also wanted to give a heads up to CPANTesters contributors
> that these machines have an OpenSSL version that is vulnerable.
>
> See <
> http://www.cpantesters.org/distro/C/Crypt-SSLeay.html#Crypt-SSLeay-0.64?grade=1&perlmat=2&patches=2&oncpan=2&distmat=3&perlver=ALL&osname=ALL&version=0.64
> >
> for the relevant test reports. Check the recent failures for 0.65_13.
>
> Thank you,
>
> -- Sinan
> https://metacpan.org/author/NANIS
>

Reply via email to