-
-
Notifications
You must be signed in to change notification settings - Fork 463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
False positives #6
Comments
@robredpath I saw this a few minutes ago as well. 1 false positive e another false negative. |
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") |
Are you getting the same behaviour between the site and the CLI tool? |
I have a lot of false-positives using command line too. 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. |
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. |
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 notifications@github.com:
|
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:
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. |
Nice tool. I'm getting a false positive (red) via web ui / command line for a site running Openssl 0.9.8. |
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? |
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... |
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. |
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. |
Oh, the Irony. http://filippo.io/Heartbleed/#openssl.org:443 gets a red fail |
Thanks @FiloSottile - I'll have the net tab open on future tests, but so far I can't get it to happen again. |
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. |
@yourcelf Host please? |
@FiloSottile You have a private channel I can send to you? |
@yourcelf My GH profile email, grab the PGP keys if you want |
I have the same problem as @yourcelf with version 0.9.8k-7ubuntu8.15 |
OK, figured it out: a backported mod-spdy was pulling in a newer version of OpenSSL that was vulnerable. |
@yourcelf ha! disabling mod-spdy did the trick. thanks |
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 |
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: Please advise. |
@bradspry Did you forget to reboot after update? =) |
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'. |
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. |
Easiest way to check what @takinbo mentioned is to run |
False positive for dealloc.org. OpenSSL 0.9.8o (0.9.8o-4squeeze14)
|
@cjolowicz And what version of libssl? Do you use mod-spdy as described above or something else that may be causing your server to use some other version? Did you restart apache? |
Mine was a positive positive with openssl 0.9.8 (Ubuntu lucid). I had installed mod_spdy which includes a patched, vulnerable, ssl. I did not have spdy enabled, just installed. Updating mod-spdy-beta provided me with a non-vulnerable ssl. I just thought I would mention this. |
I checked a site and it is coming back consistantly red. But when I brought it to the attention of the technical team they said they aren't using OpenSSL. I'm not sure how to respond to them, and don't want to be a total dick if it's a false positive, but does that sound posible? A false positive if they aren't using OpenSSL? |
Upon my initial test, my website cam back as Red. All subsequent tests, however, return the timeout error. This is the expected result, due to the fact that I am using Litespeed and it blocks the request. I cannot figure out why the original test returned a red result, however. I flushed my firewall blocks before re-testing, and each test comes back with the timeout error. All other tools that I use to test also confirm that the website is not vulnerable, such as: https://www.ssllabs.com/ssltest/analyze.html Do you have any idea why an initial test would come back positive? Could this be a false positive? |
I used the filippo tool and my site came back marked as Vulnerable. However when I got on a chat with my hosting company to ask them about patching it, after the tech checked my server her reported that: I can see that your OpenSSL version is Is this correct? |
@iamthegrackle That's probably a question you should ask on a RedHat forum instead, but RedHat's security advisory suggests that your openssl version is good: https://rhn.redhat.com/errata/RHSA-2014-0376.html (under "Updated packages", openssl-1.0.1e-16.el6_5.7.x86_64.rpm is mentioned as good) You may have some other package that includes its own bad version of libssl. See the above comments for some examples. |
@horsepunchkid I do not use mod-spdy. The version of libssl is 0.9.8o (0.9.8o-4squeeze14). I have not been able to reproduce the false positive, i.e. the host is now always reported as unaffected. |
Just wanted to add that the test from Qualys is seeking to test for Heartbleed. Wasn't sure about that at first. |
I tested my OpenSSL using websites, all ok after patching. I had installed the Chrome extension though, and strangely enough, I happened to look down and it had found my IIS site support.ccnva.com as being vulnerable! Since I know this is not possible as IIS isn't effected, I just thought I would bring it up. Testing the main web tool does not show it as vulnerable, so the error is in the chrome extension. |
@gbhoover, IIS isn't affected, but OpenSSL could be somewhere else in your server stack. For example, an nginx load balancer. Read the section titled "Is it only sites on Apache and nginx that are affected?" in http://www.troyhunt.com/2014/04/everything-you-need-to-know-about.html for more info. |
It would seem that there's some concurrency issue and the response is from time to time somehow leaked from one check to another, or something like that. Queries directly to http://bleed-1161785939.us-east-1.elb.amazonaws.com/bleed/: {"code":1,"data":"","error":"","host":"www.google.com"} {"code":1,"data":"","error":"","host":"example.com"} I've seen it happen with multiple domains from time to time (not very often). Probably requires that somebody does a check against a vulnerable one at the same time or just before. |
you said, "You may have some other package that includes its own bad version of libssl. See the above comments for some examples." I have brought this thread and the examples mentioned to the attention of support at my hosting company, and they insist that everything is fine as long as I ran the server updates they outlined, which I did, yet my site still shows vulnerable using the filippo.io tool. The rep closed by saying, "Also, I have tested from the following link and it says site is not vulnerable. https://lastpass.com/heartbleed/?h=sales.mx You can just ignore any warning from 3rd party sites as openSSL version in your server is already updated." So either the filippo tool is wrong, or else they are totally disregarding the issues raised here and I would wonder just how many of the VPS customers at this very large host are still vulnerable ... |
That site is vulnerable. Full stop. Feel free to link support to this comment and if they have different evidence they can get in contact with me over email. The address is in my profile. |
thanks. I let them know. they responded with a link to filippo.io with my IP address (ip::2087) instead of my domain name like I was doing. And when the 'ignore certificate' is checked, then the result is that it is fixed or unaffected. So it my ip:2087 is used then it says fixed, if my domain is used then it says vulnerable. |
Have a look at the usual: load balancers, SSL terminators, different 2014-04-12 23:29 GMT+02:00 Michael notifications@github.com:
|
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?
The text was updated successfully, but these errors were encountered: