The OpenSSL project has published a security advisory for a vulnerability resolved in the OpenSSL library on February 28, 2019.
Affected releases are Juniper Networks Junos OS:
- 12.3X48 versions prior to 12.3X48-D80;
- 14.1X53 versions prior to 14.1X53-D51;
- 15.1 versions prior to 15.1F6-S13, 15.1R7-S4;
- 15.1X49 versions prior to 15.1X49-D171, 15.1X49-D180;
- 15.1X53 versions prior to 15.1X53-D238, 15.1X53-D591, 15.1X53-D69;
- 16.1 versions prior to 16.1R7-S5;
- 16.2 versions prior to 16.2R2-S9;
- 17.1 versions prior to 17.1R3;
- 17.2 versions prior to 17.2R1-S8, 17.2R2-S7, 17.2R3-S1;
- 17.3 versions prior to 17.3R3-S4;
- 17.4 versions prior to 17.4R1-S7, 17.4R2-S4, 17.4R3;
- 18.1 versions prior to 18.1R2-S4, 18.1R3-S5;
- 18.2 versions prior to 18.2R1-S5, 18.2R2-S3, 18.2R3;
- 18.2X75 versions prior to 18.2X75-D50;
- 18.3 versions prior to 18.3R1-S3, 18.3R1-S4, 18.3R2;
- 18.4 versions prior to 18.4R1-S2, 18.4R2;
- 19.1 versions prior to 19.1R1-S1, 19.1R2.
Juniper SIRT is not aware of any malicious exploitation of these vulnerabilities.
These issues were discovered during external security research.
The important security issue resolved is described below:
CVE |
CVSS |
Summary |
CVE-2019-1559 |
5.9 (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) |
If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). Fixed in OpenSSL 1.0.2r (Affected 1.0.2-1.0.2q). |
The following software releases have been updated to resolve this specific issue: 12.3X48-D80, 14.1X53-D51, 15.1F6-S13, 15.1R7-S4, 15.1X49-D171, 15.1X49-D180, 15.1X53-D238, 15.1X53-D591, 15.1X53-D69, 16.1R7-S5, 16.2R2-S9, 17.1R3, 17.2R1-S8, 17.2R2-S7, 17.2R3-S1, 17.3R3-S4, 17.4R1-S7, 17.4R2-S4, 17.4R3, 18.1R2-S4, 18.1R3-S5, 18.2R1-S5, 18.2R2-S3, 18.2R3, 18.2X75-D50, 18.3R1-S3, 18.3R1-S4, 18.3R2, 18.4R1-S2, 18.4R2, 19.1R1-S1, 19.1R2, 19.2R1, and all subsequent releases.
This issue is being tracked as PR 1419533 which is visible on the Customer Support website.
Since SSL is used for remote network configuration and management applications such as J-Web and SSL Service for JUNOScript (XNM-SSL), viable workarounds for this issue in Junos may include:
- Disabling J-Web
- Disable SSL service for JUNOScript and only use Netconf, which makes use of SSH, to make configuration changes
- Limit access to J-Web and XNM-SSL from only trusted networks
- Avoid connecting to untrusted servers for file copy operations
Software Releases, patches and updates are available at
https://www.juniper.net/support/downloads/.
Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories."