OpenSSL CVE-2016-6304

[testkit]

OCSP Status Request extension unbounded memory growth (CVE-2016-6304)

• A malicious client can send an excessively large OCSP Status Request extension. If that client continually requests renegotiation, sending a large OCSP Status Request extension each time, then there will be unbounded memory growth on the server. This will eventually lead to a Denial Of Service attack through memory exhaustion. Servers with a default configuration are vulnerable even if they do not support OCSP. Builds using the "no-ocsp" build time option are not affected.
• Severity: HIGH
• Update 1.1.0 to 1.1.0a; 1.0.2 to 1.0.2i; 1.0.1 to 1.0.1u.
• OpenSSL blog: https://www.openssl.org/news/secadv/20160922.txt
• Issue reported by: Shi Lei (Qihoo 360 Inc.) · Multiple low severity OpenSSL vulnerabilities were reported along with above CVE and are listed in the OpenSSL blog below.
• OpenSSL blog : https://www.openssl.org/news/secadv/20160922.txt (Report for Demeter, Michael)

[pohly]

Ostro OS itself does not provide any vulnerable servers. Therefore there is no need for immediate action. Instead, we submitted a version update to OE-core and will get a fix through the regular inclusion of the updated OE-core into Ostro OS. See https://patchwork.openembedded.org/patch/132231/

[terriko]

Update: there has been another issue found, the latest versions of openssl are now 1.1.0b and 1.0.2j OpenSSL Blog: https://www.openssl.org/news/secadv/20160926.txt

[terriko]

Talked to our resident crypto expert. His advice as follows:

"If the OS supports running applications that may expose a TLS protected service – e.g. a web based control interface – then it will be affected by this notice unless the shipping library is built with the “no-ocsp” option.

If the library is built with “no-ocsp” I recommend updating to 1.0.2j, but it is not critical (MUST be filed as a high for next release). If the library is built with defaults, the library MUST be updated to 1.0.2j."

He also notes that the update includes another update that could improve device reliability by avoiding a failure case where the service thread could go unresponsive, so this is an update we will want soon regardless.

[mythi]

ostro-os #506 has this fixed.