Posts tagged bug
Heartbleed is a zero-day bug in many OpenSSL implementations, and effects a huge swatch of servers on the Internet. Here’s a list of resources I’ve been referencing:
- Heartbleed info – http://heartbleed.com/
- Heartbleed status on Heroku – https://status.heroku.com/incidents/606
- Heartbleed status on EngineYard – https://support.cloud.engineyard.com/entries/50554018
- Do we need to generate a new SSL key? – http://security.stackexchange.com/a/55210
- Info on how the Heartbleed bug works – http://security.stackexchange.com/q/55116
- Detailed info on who is vulnerable and how to fix it – http://unix.stackexchange.com/a/123712/33893
- Info on Postgres and Heartbleed – http://blog.hagander.net/archives/219-PostgreSQL-and-the-OpenSSL-Heartbleed-vulnerability.html
- Instructions for verifying openssl versions and patching on various distros – http://www.howtoforge.com/find_out_if_server_is_affected_from_openssl_heartbleed_vulnerability_cve-2014-0160_and_how_to_fix
- Reddit thread with good info – http://www.reddit.com/r/Bitcoin/comments/22gq5e/heartbleed_bug_major_openssl_vulnerability_could/
- Heartbleed status check tools – http://filippo.io/Heartbleed/, https://github.com/titanous/heartbleeder
- Info on Heartbleed bug on OS X – http://apple.stackexchange.com/q/126916
- Official announcement from openssl – https://www.openssl.org/news/secadv_20140407.txt
- Recommended additional steps after patching OpenSSL – http://security.stackexchange.com/a/55089
- Comic relief – http://xkcd.com/1353/
I am thankful today for SaaS platforms and virtual hosting environments, as they’ve meant I’ve had to do a minimal amount of work on my end to patch the applications I maintain.
Since I just spent the better part of Friday debugging this problem and then the better part of Friday night Googling for a work around, it’s worth noting that there is a “bug” in the Firefox implementation of the xmlHTTPRequest object when using it for synchronous calls (i.e. the rest of the script pauses and waits for the request to complete, unlike typical asynchronous AJAX calls). When using the xmlhttp object in a synchronous fashion, Firefox does not process the onreadystatechange handler. Thus, any libraries that are dependent on this (for running post processing functions for example) will fail to work under these conditions. Interestingly, having the Firebug extension installed causes the object to behave properly. So a secondary note is to always test your apps in a “clean” instance of Firefox.
Here are the details that I came across, along with a work around: Lukav’s Weblog » Blog Archive » Firefox firebug and synchronos calls problem.
I’ve also set up a set of tests to demonstrate the problem. Try in both Firefox and IE to see the differences.
* This post was originally published on June 5, 2007 at http://www.csb7.com/blogs/whyblogwhy/2007/06/05/a_note_about_synchronous_xmlhttp_request
<textarea id="description" name="description">Here is some text</textarea>
var myElement = document.getElementById('description');
alert(myElement.value.length); //alert: 17
Every time I tried to execute that code in IE it would complain that
'value.length' is null or not an object.
After a whole crap load of debugging I finally tracked it down to the fact that IE was actually referencing the <meta name=”description”> tag in the head section of the page. Yeah, see even though the function is getElementById, IE still thought I meant the element with the name attribute equal to “description”. Or as my brother put it in a comment to the original post (before the comments were wiped in the great Data Loss of ’06), maybe IE thought I was calling the getJustAboutAnythingIFeelLike() function…
Damn you IE for making me have to change my ID attributes to suite your leisurely implementation of the DOM!
* This post was originally published on April 5, 2007 at http://www.csb7.com/blogs/whyblogwhy/2007/04/05/ie_getelementbyid_bug_strikes_again