Google will next week begin a gradual deprecation of unsafe crypto protocol SSLv3 and cipher RC4 in Gmail IMAP/POP clients.
Tag Archives: Poodle
IETF Officially Deprecates SSLv3
The IETF, in RFC7568, declared SSLv3 “not sufficiently secure” and prohibited its use. SSLv3 fallbacks were to blame for the POODLE and BEAST attacks.
Don’t judge the risk by the logo
It’s been almost a year since the OpenSSL Heartbleed vulnerability, a flaw which started a trend of the branded vulnerability, changing the way security vulnerabilities affecting open-source software are being reported and perceived. Vulnerabilities are found and fixed all the time, and just because a vulnerability gets a name and a fancy logo doesn’t mean it is of real risk to users.
So let’s take a tour through the last year of vulnerabilities, chronologically, to see what issues got branded and which issues actually mattered for Red Hat customers.
“Heartbleed” (April 2014)CVE-2014-0160
Heartbleed was an issue that affected newer versions of OpenSSL. It was a very easy to exploit flaw, with public exploits released soon after the issue was public. The exploits could be run against vulnerable public web servers resulting in a loss of information from those servers. The type of information that could be recovered varied based on a number of factors, but in some cases could include sensitive information. This flaw was widely exploited against unpatched servers.
For Red Hat Enterprise Linux, only customers running version 6.5 were affected as prior versions shipped earlier versions of OpenSSL that did not contain the flaw.
Apache Struts 1 Class Loader RCE (April 2014) CVE-2014-0114
This flaw allowed attackers to manipulate exposed ClassLoader properties on a vulnerable server, leading to remote code execution. Exploits have been published but they rely on properties that are exposed on Tomcat 8, which is not included in any supported Red Hat products. However, some Red Hat products that ship Struts 1 did expose ClassLoader properties that could potentially be exploited.
Various Red Hat products were affected and updates were made available.
OpenSSL CCS Injection (June 2014) CVE-2014-0224
After Heartbleed, a number of other OpenSSL issues got attention. CCS Injection was a flaw that could allow an attacker to decrypt secure connections. This issue is hard to exploit as it requires a man in the middle attacker who can intercept and alter network traffic in real time, and as such we’re not aware of any active exploitation of this issue.
Most Red Hat Enterprise Linux versions were affected and updates were available.
glibc heap overflow (July 2014) CVE-2014-5119
A flaw was found inside the glibc library where an attacker who is able to make an application call a specific function with a carefully crafted argument could lead to arbitrary code execution. An exploit for 32-bit systems was published (although this exploit would not work as published against Red Hat Enterprise Linux).
Some Red Hat Enterprise Linux versions were affected, in various ways, and updates were available.
JBoss Remoting RCE (July 2014) CVE-2014-3518
A flaw was found in JBoss Remoting where a remote attacker could execute arbitrary code on a vulnerable server. A public exploit is available for this flaw.
Red Hat JBoss products were only affected by this issue if JMX remoting is enabled, which is not the default. Updates were made available.
“Poodle” (October 2014) CVE-2014-3566
Continuing with the interest in OpenSSL vulnerabilities, Poodle was a vulnerability affecting the SSLv3 protocol. Like CCS Injection, this issue is hard to exploit as it requires a man in the middle attack. We’re not aware of active exploitation of this issue.
Most Red Hat Enterprise Linux versions were affected and updates were available.
“ShellShock” (September 2014) CVE-2014-6271
The GNU Bourne Again shell (Bash) is a shell and command language interpreter used as the default shell in Red Hat Enterprise Linux. Flaws were found in Bash that could allow remote code execution in certain situations. The initial patch to correct the issue was not sufficient to block all variants of the flaw, causing distributions to produce more than one update over the course of a few days.
Exploits were written to target particular services. Later, malware circulated to exploit unpatched systems.
Most Red Hat Enterprise Linux versions were affected and updates were available.
RPM flaws (December 2014) CVE-2013-6435, CVE-2014-8118
Two flaws were found in the package manager RPM. Either could allow an attacker to modify signed RPM files in such a way that they would execute code chosen by the attacker during package installation. We know CVE-2013-6435 is exploitable, but we’re not aware of any public exploits for either issue.
Various Red Hat Enterprise Linux releases were affected and updates were available.
“Turla” malware (December 2014)
Reports surfaced of a trojan package targeting Linux, suspected as being part of an “advance persistent threat” campaign. Our analysis showed that the trojan was not sophisticated, was easy to detect, and unlikely part of such a campaign.
The trojan does not use any vulnerability to infect a system, it’s introduction onto a system would be via some other mechanism. Therefore it does not have a CVE name and no updates are applicable for this issue.
“Grinch” (December 2014)
An issue was reported which gained media attention, but was actually not a security vulnerability. No updates were applicable for this issue.
“Ghost” (January 2015) CVE-2015-0235
A bug was found affecting certain function calls in the glibc library. A remote attacker that is able to make an application call to an affected function could execute arbitrary code. While a proof of concept exploit is available, not many applications were found to be vulnerable in a way that would allow remote exploitation.
Red Hat Enterprise Linux versions were affected and updates were available.
“Freak” (March 2015) CVE-2015-0204
It was found that OpenSSL clients accepted EXPORT-grade (insecure) keys even when the client had not initially asked for them. This could be exploited using a man-in-the-middle attack, which could downgrade to a weak key, factor it, then decrypt communication between the client and the server. Like Poodle and CCS Injection, this issue is hard to exploit as it requires a man in the middle attack. We’re not aware of active exploitation of this issue.
Red Hat Enterprise Linux versions were affected and updates were available.
Other issues of customer interest
We can also get a rough guide of which issues are getting the most attention by looking at the number of page views on the Red Hat CVE pages. While the top views were for the issues above, also of increased interest was:
- A kernel flaw (May 2014) CVE-2014-0196, allowing local privilege escalation. A public exploit exists for this issue but does not work as published against Red Hat Enterprise Linux.
- “BadIRET”, a kernel flaw (December 2014) CVE-2014-9322, allowing local privilege escalation. Details on how to exploit this issue have been discussed, but we’re not aware of any public exploits for this issue.
- A flaw in BIND (December 2014), CVE-2014-8500. A remote attacker could cause a denial of service against a BIND server being used as a recursive resolver. Details that could be used to craft an exploit are available but we’re not aware of any public exploits for this issue.
- Flaws in NTP (December 2014), including CVE-2014-9295. Details that could be used to craft an exploit are available. These serious issues had a reduced impact on Red Hat Enterprise Linux.
- A flaw in Samba (February 2015) CVE-2015-0240, where a remote attacker could potentially execute arbitrary code as root. Samba servers are likely to be internal and not exposed to the internet, limiting the attack surface. No exploits that lead to code execution are known to exist, and some analyses have shown that creation of such a working exploit is unlikely.
Conclusion
We’ve shown in this post that for the last year of vulnerabilities affecting Red Hat products the issues that matter and the issues that got branded do have an overlap, but they certainly don’t closely match. Just because an issue gets given a name, logo, and press attention does not mean it’s of increased risk. We’ve also shown there were some vulnerabilities of increased risk that did not get branded.
At Red Hat, our dedicated Product Security team analyse threats and vulnerabilities against all our products every day, and provide relevant advice and updates through the customer portal. Customers can call on this expertise to ensure that they respond quickly to address the issues that matter, while avoiding being caught up in a media whirlwind for those that don’t.
OpenSSL Mystery Patch is No Heartbleed
The anticipated high severity patch in OpenSSL is for a denial-of-service vulnerability in the recently released version 1.0.2 that can crash a client or server with a malformed certificate.
OpenSSL: Patch for secret “high severity†vulnerability
And indeed, in order to avoid being again in the news, the OpenSSL Foundation is set to release later this week several patches for OpenSSL, fixing undisclosed security vulnerabilities, including one that has been rated “high” severity.
Matt Caswell of the OpenSSL Project Team announced that OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf will be released Thursday.
“These releases will be made available on 19th March,” Caswell wrote. “They will fix a number of security defects. The highest severity defect fixed by these releases is classified as “high” severity.”
OpenSSL has been hit hard and the trust in it and in open source in general has been severely shaken in the last 12 months.
Last year in April, Heartbleed (CVE-2014-0160) was discovered in older versions of OpenSSL, but still highly used, which allowed hackers to read the sensitive contents of users’ encrypted data, such as financial transactions, instant messages and even steal SSL keys from Internet servers or client software that were running the affected versions of OpenSSL.
Two month later, in June the same year, a Man-in-the-Middle (MITM) vulnerability (CVE-2014-0224) was discovered and fixed. However, the vulnerability wasn’t quite as severe as the Heartbleed flaw, but serious enough to decrypt, read or manipulate the encrypted data.
In October last year, POODLE (CVE-2014-3566) (Padding Oracle On Downgraded Legacy Encryption) was discovered in the obsolete Secure Sockets Layer (SSL) v3.0 that could allow an attacker to decrypt contents of encrypted connections to websites. When exploited, it allows an attacker to perform a man-in-the-middle attack in order to decrypt HTTP cookies. The POODLE attack can force a connection to “fallback” to SSL 3.0, where it is then possible to steal cookies, which are meant to store personal data, website preferences or even passwords.
Just weeks ago, the latest vulnerability, FREAK (CVE-2015-0204) (Factoring Attack on RSA-EXPORT Keys) was discovered in the SSL protocol that allowed an attacker to force SSL clients, including OpenSSL, to downgrade to weaken ciphers that can be easily broken. Needless to say that such a weak encryption could potentially allow them to eavesdrop on encrypted networks by conducting man-in-the-middle attacks. This time, pretty much every big software vendor was affected: Apple, with its MacOS, iPhone and iPad, Google with Android and Chrome and last but not least, Microsoft with all versions of Windows.
Due to its widespread use, OpenSSL is considered an important software project and is ranked first under the Linux Foundation’s Core Infrastructure Initiative. Because of its complexity, high usage and lack of in-depth security reviews, companies like Google, Facebook and Cisco are heavily sponsoring this project in order to avoid being again affected by long forgotten bugs.
Well, for OpenSSL seems that this is starting to pay off.
The post OpenSSL: Patch for secret “high severity” vulnerability appeared first on Avira Blog.
Oracle Patches Backdoor Vulnerability, Recommends Disabling SSL
Oracle’s January 2015 Critical Patch update includes a fix for a backdoor found in the Oracle E-Business Suite by researcher David Litchfield. The patch is among 169 released in the CPU.
Update on Red Hat Enterprise Linux 6 and FIPS 140 validations
Red Hat achieved its latest successful FIPS 140 validation back in April 2013. Since then, a lot has happened. There have been well publicized attacks on cryptographic protocols, weaknesses in implementations, and changing government requirements. With all of these issues in play, we want to explain what we are doing about it.
One of the big changes was that we enabled support of Elliptic Curve Cryptography (ECC) and Elliptic Curve Diffie Hellman (ECDH) in Red Hat Enterprise Linux to meet the National Institute of Standards and Technology’s (NIST’s) “Suite B” requirements taking effect this year. Because we added new ciphers, we knew we needed to re-certify. Re-certification brings many advantages to our government customers, who not only benefit from the re-certification, but they also maintain coverage from our last FIPS 140 validation effort. One advantage of re-certification is that we have picked up fixes for BEAST, Lucky 13, Heartbleed, Poodle, and some lesser known vulnerabilities around certificate validation. It should be noted that these attacks are against higher level protocols that are not part of any crypto primitives covered by a FIPS validation. But, knowing the fixes are in the packages under evaluation should give customers additional peace of mind.
The Red Hat Enterprise Linux 6 re-certification is now under way. It includes reworked packages to meet all the updated requirements that NIST has put forth taking effect Jan. 1, 2014, such as a new Deterministic Random Bit Generator (DRGB) as specified in SP 800-90A (PDF); an updated RSA key generation technique as specified in FIPS 186-4 (PDF); and updated key sizes and algorithms as specified in SP 800-131A (PDF).
Progress on the certification is moving along – we’ve completed review and preliminary testing and are now applying for Cryptographic Algorithm Validation System (CAVS) certificates. After that, we’ll submit validation paperwork to NIST. All modules being re-certified are currently listed on NIST’s Modules in Process page, except Volume Encryption (dm-crypt). Its re-certification is taking a different route because the change is so minor thus not needing CAVS testing. We are expecting the certifications to be completed early this year.
2014 Security Lessons: Making 2015 More Secure
A few days ago, I gave a webinar titled Make 2015 More Secure: Lessons from 2014, which was a follow-up to the 2014 Mid-Year Threat Report webinar from this summer.
The post 2014 Security Lessons: Making 2015 More Secure appeared first on We Live Security.
Two Cisco Products Vulnerable to POODLE Attack on TLS
Two of Cisco’s products are vulnerable to the POODLE attack via the TLS implementation in those products. The vulnerability affects Cisco’s Adaptive Security Appliance software and its Application Control Engine module. The POODLE attack was disclosed in October by researchers from Google, who discovered that if an attacker can force a vulnerable Web server to fall back from […]
POODLE vulnerability found to also bite TLS encryption
When it was first uncovered back in October, researchers believed that only sites using SSL 3.0 were vulnerable to the POODLE, but now it appears certain implementations of TLS could be compromised using a similar exploit, according to ZDNet.
The post POODLE vulnerability found to also bite TLS encryption appeared first on We Live Security.