KB2963983 IE Remote Code Exploit

Microsoft has released a bulletin warning of a bug in pretty much all versions of IE (6-11) which could allow remote code to be executed with the privileges of the running user.

Call me jaded but if you are still using IE, there is no hope for you. Sure – Microsoft has tried (and failed) to fix their product. The best thing they could do is concede defeat and bring us a rebranded OSS browser, perhaps based on WebKit. Huh? They are doing that?? It could just be my imagination.



Complex Tech has an excellent article on the recently declassified documents that reveal further operational information. Unsurprisingly the court refused to allow the phone companies the right to protect their customer’s data from illegal search and seizure from the NSA. Why there has not been a 2014 revolution is anyone’s guess but I would bet that those in the seats of power are feeling very uneasy right about now. Better put off your Hawaiian holiday govt folks.

RCMP Alleges Juvenile Cyber Thief Exploited Heartbleed


The RCMP alleges that 19 year old security “enthusiast” Stephen Arthuro Solis-Reyes took advantage of the recently disclosed Heartbleed TLS vulnerability to steal 900 social insurance numbers from a government website. The publication The Financial Post made the aforementioned claims in a recent article on their website. I strongly suspect given the large number of individual records collected that another vulnerability – such as a database with a weak or default password or the lack of input sanitation allowing the alleged attacker access to generate his own queries and that the Heartbleed angle has been tacked on erroneously. Others may disagree but I believe the aforementioned attacks are far more likely when all of the information in the public eye is assessed.

SSL Implementations, Code Quality and Common Sense


The far reaching consequences of the Heartbleed vulnerability have been discussed at length in a thread on Bruce Schneier’s blog. In response to a comment on the code quality I wrote the following:

“I nodded in agreement so hard [at another user’s comment on OpenSSL code quality] I might have to see a chiropractor.

OpenSSL’s src is a mess. If cyaSSL can mirror its basic functionality and do such a thing with code that is both legible and importantly it is advertized as 20 times smaller than OpenSSL. Of course it is targeted towards the embedded market but I would rather audit a significantly smaller codebase that a lay sysadmin can likely understand than try and analyze the Pandora’s box that is OpenSSL’s source. It really is a disgrace.

Feature creep is a terrible thing. Security critical libraries should focus on their task. At least move redundant or niche usage extensions and other foolery out of the core and disable them unless uncommented in the Makefile at compile time.”

Now, of course I wouldn’t see a chiropractor. All scientific evidence points to the practice as ineffective folk medicine. But I digress. The point of my post is to highlight the (perhaps obvious) fact that as a library grows and more lines of code are written, so too does the potential for a potentially catastrophic bug to occur.

Good programming in the true style of our BSDite forefathers focuses on a few key laws, and these hold true regardless of what you are coding and what language you happen to be coding in. Essentially these boil down to the KISS principle – write good, well commented code and code with grace. What can be done in five lines may be done in one, but only if this does not negatively affect the readability (and thus the ability of others to audit) of your code. Extending upon this, be sure to separate out any unnecessary fluff from your core code. A feature that is used by perhaps one percent of your users should not be compiled in by default, especially in the case of a security critical library. The final tip is to sanity check everything and always distrust information pulled from external sources (i.e. the foreign host).

Of course all of the above is common sense. Unfortunately this has been lacking in many open source projects, and has been an issue ever since Stallman wanted EMACS to be everything including the kitchen sink.

Updated Warrant Canary

Given the reasonably long hiatus I have taken from actively participating in security blogs I felt that an updated warrant canary wouldn’t be such a bad thing. Here goes.

Hash: SHA1

I - the writer of this blog, identified by the pseudonym "Mike The Crypto Goat" and with PGP key ID B7A04065 (current key, 4096R, expires 2015-10-26 and issued to replace 6054D4D2 on 2014-01-04) state, under penalty of perjury, that I am categorically not in the employment of the United States government, nor do I perform any task for the aforementioned entity in any capacity. Furthermore I state that I am not an agent, employee or intelligent asset of any government. As of this day I have not received an order under FISA or any other secret (or otherwise) court and am under no duress as I write this statement to this effect. While I understand that the mentioned law, while abhorrent and unconstitutonal (and thus invalid) can effectively be used to 'gag' the free expression of this individual, I will not and shall not sign such a declaration if any information contained within it is not truthful, or where the information within it may be misleading. I will comply with this even if it ultimately results in the contravention of a court (an illegal and unconstitional one at that) order.

As I write this declaration it is 19:05 UTC on Friday April 11 2014, and the DOW sits at 16,023.93 and the NASDAQ at 3,994.55 with the markets still open. Yesterday's USA Today reported that "The Nasdaq composite index, prone to big drops lately, tumbled 129.79 points, or 3.1%, to 4,054.11. It was the worst point drop since Aug. 18, 2011, when the index dropped 131.05 points." On reuters, the head news story is "A fresh face on Obamacare" with secondary stories "Detroit closer to exiting bankruptcy after swaps deal approval" and the possibly alarmist "U.S. says Hackers trying to use Heartbleed bug."

Version: GnuPG v2.0.21 (FreeBSD)



CloudFlare recently claimed that although serious the Heartbleed bug could not be used to successfully hoover up the site’s private key. They have put up an intentionally vulnerable site, challenging the security community to prove that key theft via this bug is possible.

UPDATE: within a few hours two people had independently stolen the private key. So much for their contention that the threat posed by Heartbleed was overrated.

Developer Responsible For Heartbleed Speaks


German OpenSSL developer Robin Seggelmann spoke openly and was quoted by several newspapers about his commit which ultimately introduced the bug responsible for Heartbleed, essentially accepting responsibility and offering a mea culpa of sorts – no doubt in an attempt to quell the growing concern that this bug was perhaps planted by the NSA.

At the risk of sounding like a conspiracy theorist (and I will remind readers that prior to the Snowden disclosures most would have accused those speaking of the reach of the NSA’s intercept program as being a nut despite evidence of the existence of such a program being widely accepted as early as the Room 512A documents) I will admit that when news of Heartbleed broke I was immediately suspicious. The simplicity of the error and the ease of which it could be dismissed as an innocent mistake are the alleged hallmarks of the work of the agency and this essentially mirrors the style of the 2003 attempt to backdoor the Linux kernel, the only difference being the latter was caught – minimum modification yet maximum damage to the integrity of the software.

When one considers the number of websites using OpenSSL (not to mention embedded devices and appliances – which will likely remain affected while their vendors slowly push out patches) and the duration that a large portion of the internet was vulnerable it is unsurprising that some are asking questions. I would suspect that even if the NSA were not directly responsible that knowledge of the 0day would have been a very valuable thing and given their resources independent discovery is a possibility.

I wish to add a disclaimer that I am not seriously suggesting that Heartbleed was deliberate and the aforementioned developer responsible, but it is interesting to consider that it is likely now an unfortunate reality that in a post Snowden world any future vulnerabilities discovered in any software will be scrutinized and suspicions cast toward shadowy government spooks. I don’t necessarily think this is a bad thing, especially if it results in more eyes auditing the code that so many came to blindly rely on.