{"id":1999,"date":"2014-06-06T16:13:23","date_gmt":"2014-06-06T16:13:23","guid":{"rendered":"http:\/\/kasperskydaily.com\/b2b\/?p=1999"},"modified":"2020-02-26T10:51:21","modified_gmt":"2020-02-26T15:51:21","slug":"new-openssl-bugs-are-found-in-numbers-bad-or-good","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/new-openssl-bugs-are-found-in-numbers-bad-or-good\/1999\/","title":{"rendered":"New OpenSSL bugs are found in numbers: bad or good?"},"content":{"rendered":"

OpenSSL encryption protocol is a \u201cheadlines star\u201d once again after OpenSSL Project has released a grim-looking Security Advisory<\/a> listing as many as six important security issues and patches for them.<\/p>\n

\n<\/p>

\u00a0<\/p>\n

The cyberworld is still cleaning its feathers after the\u00a0#Hearbleed<\/a>\u00a0mess in April. News about the discovered vulnerabilities, as one could expect, led to a not-so-minor storm in social networks, although media outlets are probably yet to react appropriately.<\/p>\n

But what would the appropriate reaction would be? Actually, none of the discovered vulnerabilities seem to be a match for Heartbleed: At least it won\u2019t be that widely spread (and, most likely, won\u2019t make a necessity to change all passwords this time<\/a>). This is good news.<\/p>\n

The bad news: The most serious vulnerability ChangeCipherSpec Injection Vulnerability (CVE-2014-0224) had been there since the first release of OpenSSL \u2013 i.e. since 1998.<\/p>\n

How dangerous is this? According to dry language of OpenSSL\u2019s security advisory, \u201cAn attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL\/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server.<\/em>\u201d<\/p>\n

In practice, MITM attacks are not necessarily easy to launch; this time it will take an attacker compromising some open WiFi-spot (say, a router in a local caf\u00e9) in order to strip the encryption from the information sent through it. \u201cThere are risks of tampering with the exploits on contents and authentication information over encrypted communication via web browsing, e-mail and VPN, when the software uses the affected version of OpenSSL,<\/em>\u201d says Lepidum<\/a>, a company which employee Mashashi Kikuchi is credited with the bug discovery and initial reporting.<\/p>\n

Also in practice, TOR project reports to be affected<\/a> and recommends to update packages as soon as they are \u201cavailable\u201d.\u00a0<\/p>

More scrutiny over OpenSSL will reveal \u2013 and allow to fix! \u2013 more bugs.<\/p>Tweet<\/a><\/blockquote>\n

It is necessary to mention, though, that the attack can only be performed if both a client and a server are vulnerable. OpenSSL advisory reports that while all clients are vulnerable, Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Still, users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution either.<\/p>\n

Well, for 16 years this important vulnerability hadn\u2019t been discovered by its developers or any experts reviewing the code. At least officially. How this is possible?<\/p>\n

According to Mashashi Kikuchi, a security researcher who reported the bug and provided the initial patch, \u201cThe biggest reason why the bug hasn\u2019t been found for over 16 years is that code reviews were insufficient, especially from experts who had experiences with TLS\/SSL implementation. If the reviewers had enough experiences, they should have been verified OpenSSL code in the same way they do their own code. They could have detected the problem<\/em>\u201c.<\/p>\n

There were at least two occasions<\/a> when this could have happened, but until now this bug stayed under the radars. It\u2019s only a matter of hope now, that someone with less purity of intent hasn\u2019t found it before Mashashi Kikuchi.<\/p>\n

The rest six vulnerabilities are seemingly less dangerous, and have little to do with encryption per se. DTLS invalid fragment vulnerability (CVE-2014-0195) allows for a buffer overrun attack to be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This one is potentially exploitable to run arbitrary code on a vulnerable client or server<\/a>. The only application affected are those using OpenSSL as a DTLS client or a server. And the rest of the reported bugs can only be used to launch DoS attacks, without compromising the encrypted data.<\/p>\n

\"800-4\"<\/a><\/p>\n

\u00a0<\/p>\n

Still these vulnerabilities cannot (and, hopefully, would not) be disregarded.<\/p>\n

What does this mean for business and system administration? For starters \u2013 prompt update of OpenSSL software wherever it is used. It is nice to know that non-OpenSSL clients, such as IE, Firefox, Chrome on Desktop and iOS, Safari, etc. aren\u2019t affected.<\/p>\n

Unfortunately (or not) this may well mean that in the near future more vulnerabilities will be discovered and disclosed. The Heartbleed fallout led to a more scrupulous scrutiny of the OpenSSL code with Google, Amazon and several other tech companies lending a hand<\/a> with money and expertise.<\/p>\n

The newly discovered six bugs, however dwarf-like they are in comparison to Heartbleed, may be just the beginning of the steady chain of head-ups for OpenSSL users. It is imperative that they are watched closely and all the patches are applied in a timely manner.<\/p>\n

There are naysayers already, saying that the encryption on the Web \u2013 like privacy \u2013 is essentially dead, since there\u2019s no reason to expect other encryption systems to be much more secure and nothing can make you safe.<\/p>\n

\u201cThe fact of the matter is that nothing is foolproof. If fundamental flaws in one of the world\u2019s most widely used encryption systems can go undiscovered for years, what other bugs are still lurking in the shadows in OpenSSL and other SSL systems? Who already knows about them but has chosen to keep quiet?\u201d<\/em> writes Adam Turner\u00a0in his column in Sydney Morning Herald.<\/a><\/p>\n

But on the other hand, some find this last batch of newly-discovered vulnerabilities rather encouraging: it means more responsible approach of OpenSSL developers and third-party experts to code reviews now: more scrutiny means less \u201cshadows\u201d where the bugs could be hiding.<\/p>\n","protected":false},"excerpt":{"rendered":"

OpenSSL reported six new vulnerabilities just eight weeks after Heartbleed. Does it mean that OpenSSL is heading for a disaster, or is it on its way to healing?<\/p>\n","protected":false},"author":209,"featured_media":15840,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3052],"tags":[261,588,590],"class_list":{"0":"post-1999","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-smb","9":"tag-encryption","10":"tag-heartbleed","11":"tag-openssl"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/new-openssl-bugs-are-found-in-numbers-bad-or-good\/1999\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/new-openssl-bugs-are-found-in-numbers-bad-or-good\/1999\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/new-openssl-bugs-are-found-in-numbers-bad-or-good\/1999\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/encryption\/","name":"encryption"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/1999","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/209"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=1999"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/1999\/revisions"}],"predecessor-version":[{"id":33168,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/1999\/revisions\/33168"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/15840"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=1999"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=1999"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=1999"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}