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).
References
Configurations
Configuration 1 (hide)
|
Configuration 2 (hide)
|
Configuration 3 (hide)
|
Configuration 4 (hide)
|
Configuration 5 (hide)
|
Configuration 6 (hide)
|
Configuration 7 (hide)
|
Information
Published : 2019-02-27 23:29
Updated : 2021-01-20 15:15
NVD link : CVE-2019-1559
Mitre link : CVE-2019-1559
JSON object : View
Products Affected
opensuse
- leap
netapp
- snapcenter
- storage_automation_store
- ontap_select_deploy
- oncommand_unified_manager
- santricity_smi-s_provider
- element_software
- snapdrive
- hyper_converged_infrastructure
- steelstore_cloud_integrated_storage
- storagegrid
- oncommand_workflow_automation
- ontap_select_deploy_administration_utility
openssl
- openssl
tenable
- nessus
debian
- debian_linux
canonical
- ubuntu_linux
f5
- traffix_signaling_delivery_controller
CWE
CWE-203
Observable Discrepancy
