Oracle Critical Patch Update January 2018
Released January 2018 · Oracle's advisory ↗ · ← Critical Patch Update, October 2017 · Critical Patch Update, April 2018 →
197 CVEs in this release, one square each
By status
16Protected by Waratek1Mitigation candidate94No exploit published25Outside Waratek scope61Not applicable
3Exploited, marked by the ring
No exploit published. For 94 of them, Oracle's security advisory is the source of public detail.
Protected by Waratek. Waratek RASP can block exploitation of these on systems that have not applied the patch yet.
Overview 4 matches · 0 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 2 public PoC
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
Outside Waratek scope
2
50.0%
Not applicable
2
50.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
4
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
2
50.0%
Proof of concept only
0
0.0%
Forecast only
2
50.0%
No public exploit
0
0.0%
split by
peak 1 / quarter
Q1 131
Outside Waratek scope1
Medium1
not blocked1
Forecast only1
Q2 130
Q3 130
Q4 130
Q1 140
Q2 140
Q3 140
Q4 140
Q1 150
Q2 150
Q3 150
Q4 150
Q1 160
Q2 161
Not applicable1
Medium1
not blocked1
Working exploit published1
Q3 160
Q4 160
Q1 170
Q2 170
Q3 170
Q4 171
Not applicable1
Medium1
not blocked1
Forecast only1
Q1 181
Outside Waratek scope1
Medium1
not blocked1
Working exploit published1
Q1 13Q3 13Q1 14Q3 14Q1 15Q3 15Q1 16Q3 16Q1 17Q3 17Q1 18
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2017-5715 | Medium | 2018-01-04 | Outside Waratek scope | Working exploit published | Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. |
| CVE-2017-3737 | Medium | 2017-12-07 | Not applicable | Forecast only | OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected. |
| CVE-2016-2107 | Medium | 2016-05-05 | Not applicable | Working exploit published | The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a certain padding check, which allows remote attackers to obtain sensitive cleartext information via a padding-oracle attack against an AES CBC session. NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-0169. |
| CVE-2013-2566 | Medium | 2013-03-15 | Outside Waratek scope | Forecast only | The RC4 algorithm, as used in the TLS protocol and SSL protocol, has many single-byte biases, which makes it easier for remote attackers to conduct plaintext-recovery attacks via statistical analysis of ciphertext in a large number of sessions that use the same plaintext. |