False positives

[robredpath]

Thanks for a very useful tool :D

However, we've had some issues using it whereby the website would produce false positives (ie, consider that a server was vulnerable when it wasn't) on servers the first time it was run, but not subsequently. This included servers running OpenSSL 0.9.8. Annoyingly, it's stopped happening now, but I couldn't see a commit where this issue was directly addressed, so I'm not sure if it's fixed itself (urgh) or if it's something fixed by the developer.

We've not seen this when running it on the command line.

Anyone else seen this? Anyone still seeing this?

[plentz]

@robredpath I saw this a few minutes ago as well. 1 false positive e another false negative.

[plentz]

update: now it seems to be giving green light for every site(tested 3 sites that I know that aren't ok yet and all 3 received "all good")

[robredpath]

Are you getting the same behaviour between the site and the CLI tool?

[morsik]

I have a lot of false-positives using command line too. If you run:

for i in $(cat ssl_hosts)
do
    (
        curl -s "http://localhost/bleed/$i" &
    )
done

you'll get also a lot of false positives. Local server can't handle this correcty.

When i do linear checking - results looks correct.

[FiloSottile]

http://filippo.io/Heartbleed/faq.html#loadissue

[robredpath]

Awesome. Thanks for your work on this, @FiloSottile !

That's slightly different from what I was seeing this morning - false reds followed by lots of correct greens.

If it's possible, could some mechanism to verify that the result displayed is definitely from my server be provided? I'm not entirely sure what that would look like but it would help immensely with confidence in results.

[FiloSottile]

Be careful, I can't think of anything that could cause false reds.

More probably you have false greens, check better...

2014-04-08 15:56 GMT+02:00 Rob Redpath [email protected]:

Awesome. Thanks for your work on this, @FiloSottilehttps://github.com/FiloSottile!

That's slightly different from what I was seeing this morning - false reds followed by lots of correct greens.

If it's possible, could some mechanism to verify that the result displayed is definitely from my server be provided? I'm not entirely sure what that would look like but it would help immensely with confidence in results.

Reply to this email directly or view it on GitHubhttps://github.com/FiloSottile/Heartbleed/issues/6#issuecomment-39850310 .

[malgorithms]

I believe I saw a couple false positives on the site, too. @FiloSottile you said the command line tool is unaffected, and it's reporting keybase.io:443 as safe:

# passes repeated tests, no FAILS
>./Heartbleed keybase.io:443
2014/04/08 11:06:03 keybase.io:443 - SAFE

And so is the site now. But 20 minutes ago I got a FAIL on the site, reloaded a few more successes, and got a FAIL again. And someone tweeted at me they did too. Now I cannot reproduce this again.

Max updated to 1.0.1g last night.

[pielgrzym]

Nice tool. I'm getting a false positive (red) via web ui / command line for a site running Openssl 0.9.8.

[FiloSottile]

@malgorithms @pielgrzym

I can't honestly think of how a false positive (let's define it as a RED w/ dumped memory including YELLOW SUBMARINE) could happen.

Can you please provide hosts - logs?

[malgorithms]

I can't reproduce it again, but what's your take on Keybase's server right now? We haven't changed anything in the last hour since someone else and I both saw the positive. Can you get a positive?

I never saw a false positive in the command line app. Just on the website. Is there a chance there was a bug (during heavy load? or a race condition?) where site A was getting site B's results back? That would in effect be a presentation bug...

[mboylan]

I also saw a false positive a single time to a web server we have running OpenSSL 9.8. I cannot reproduce it on the website and the CLI tool is continuously reporting back that everything is safe. Unfortunately, for obvious reasons, I cannot share the URL of the server I was testing.

[egp]

I did see one red fail on http://filippo.io/Heartbleed/#keybase.io:443 recently(after Chris announced it was fixed), but now all I get is green pass.

[egp]

Oh, the Irony. http://filippo.io/Heartbleed/#openssl.org:443 gets a red fail

[FiloSottile]

http://filippo.io/Heartbleed/faq.html#falsepositive

[malgorithms]

Thanks @FiloSottile - I'll have the net tab open on future tests, but so far I can't get it to happen again.

[yourcelf]

I have a debian 0.9.8o-4squeeze14 server that is reporting as vulnerable, both with the command line and the hosted service. That OpenSSL version /should/ be safe according to http://heartbleed.com. Either this tool or heartbleed.com's vulnerability table seems to be wrong.

[FiloSottile]

@yourcelf Host please?

[yourcelf]

@FiloSottile You have a private channel I can send to you?

[FiloSottile]

@yourcelf My GH profile email, grab the PGP keys if you want

[r15ch13]

I have the same problem as @yourcelf with version 0.9.8k-7ubuntu8.15

[yourcelf]

OK, figured it out: a backported mod-spdy was pulling in a newer version of OpenSSL that was vulnerable.

[r15ch13]

@yourcelf ha! disabling mod-spdy did the trick. thanks

[mmckinst]

For people affected by mod-spdy, you'll need to disable mod_spdy.so and the mod_ssl_with_npn.so module it comes with. Then load mod_ssl.so instead of mod_ssl_with_npn.so .

mod-spdy bug report: https://code.google.com/p/mod-spdy/issues/detail?id=85

[bradspry]

Tool reports red fail against Debian openssl 1.0.1e-2+deb7u6

But Debian security tracker reports openssl 1.0.1e-2+deb7u6 status as FIXED: https://security-tracker.debian.org/tracker/CVE-2014-0160

Please advise.

[schlamar]

@bradspry Did you forget to reboot after update? =)

[bradspry]

Where I went wrong was using the 'apt-get install --only-upgrade openssl' method, which did not upgrade package 'libssl1.0.0'. Updating package 'openssl' was not enough... You must also update package 'libssl1.0.0'.

[takinbo]

One other thing to note are binaries that have been statically compiled with vulnerable versions of the library. You want to make sure that those are checked as well.

I had an nginx binary that I had to replace to fix the problem.

[pielgrzym]

Easiest way to check what @takinbo mentioned is to run nginx -V and look for custom library paths.

[cjolowicz]

False positive for dealloc.org.

OpenSSL 0.9.8o (0.9.8o-4squeeze14) Apache 2.2.16 (2.2.16-6+squeeze12)

([]uint8) {
 00000000  02 00 79 68 65 61 72 74  62 6c 65 65 64 2e 66 69  |..yheartbleed.fi|
 00000010  6c 69 70 70 6f 2e 69 6f  59 45 4c 4c 4f 57 20 53  |lippo.ioYELLOW S|
 00000020  55 42 4d 41 52 49 4e 45  a9 74 e8 72 ad 0d 71 7e  |UBMARINE.t.r..q~|
 00000030  28 0e 67 ef fe ab 05 c2  44 58 37 86 45 3b 61 af  |(.g.....DX7.E;a.|
 00000040  14 87 3c 78 70 71 14 d8  f2 05 78 f9 49 13 d5 54  |..<xpq....x.I..T|
 00000050  da d5 d3 72 cd 9e 1f 2f  3c eb fb 2f e6 80 90 37  |...r.../<../...7|
 00000060  76 97 40 7f fd 5c 6d ee  96 61 60 92 5b f3 86 f8  |v.@..\m..a`.[...|
 00000070  c5 7d 92 bd 2d 2c 9d ab  e1 8d 7d 7b 6c 84 07 80  |.}..-,....}{l...|
 00000080  50 29 91 7c b1 6c 08 c5  3e 35 3f 98              |P).|.l..>5?.|
}