WaratekVRT Sign in
Reset
More filters (2)
Columns
Published to 2019-10-31✕Product bc-java✕
Overview 4 matches · 2 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
4matches 2protected50.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 2 50.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 2 50.0%
Critical 0 0.0% High 0 0.0% Medium 4 100.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 2 50.0% partly blocked 0 0.0% not blocked 2 50.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 4 100.0%
4 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2016-1000345 Medium 2018-06-04 Protected by Waratek No public exploit In the Bouncy Castle JCE Provider version 1.55 and earlier the DHIES/ECIES CBC mode vulnerable to padding oracle attack. For BC 1.55 and older, in an environment where timings can be easily observed, it is possible with enough observations to identify when the decryption is failing due to padding.
CVE-2016-1000341 Medium 2018-06-04 Protected by Waratek No public exploit In the Bouncy Castle JCE Provider version 1.55 and earlier DSA signature generation is vulnerable to timing attack. Where timings can be closely observed for the generation of signatures, the lack of blinding in 1.55, or earlier, may allow an attacker to gain information about the signature's k value and ultimately the private value as well.
CVE-2018-5382 Medium 2018-04-16 No exploit published No public exploit The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.
CVE-2013-1624 Medium 2013-02-08 No exploit published No public exploit The TLS implementation in the Bouncy Castle Java library before 1.48 and C# library before 1.8 does not properly consider timing side-channel attacks on a noncompliant MAC check operation during the processing of malformed CBC padding, which allows remote attackers to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data for crafted packets, a related issue to CVE-2013-0169.