Created cryptlib tracking bugs for this issue:

Affects: epel-all [bug 2256520]
Affects: fedora-all [bug 2256519]

This "vulnerability" doesn't exist if you compile cryptlib from unmodified source code.  Specifically, in order to create it you need to read through the source code, find the undocumented option to enable a known-insecure mechanism (it's used for fuzz-testing to enable otherwise unreachable code paths), and then modify the code (or build script) to create a custom build that has the vulnerability in there.

It's difficult to know how to respond to such a CVE because it's for a "vulnerability" that doesn't exist unless you go out of your way to add it yourself.  If someone's going to do that then they may as well just enable the code to print the TLS master secret for debugging purposes (see https://www.ietf.org/archive/id/draft-thomson-tls-keylogfile-00.html) and call that a vulnerability.

This also makes the "fixed in version 3.4.7" nonsensical, since it's not present in the first place.  So count this CVE as disputed, or at least we need to invent some new sort of logic language to describe a vulnerability that doesn't exist, and how to not fix it in versions that it's not present in.

it's not about editing source code, compilation flags can be specified as environment variable and as options to `make`

the vulnerability already clearly states *When* it's compiled like this, the vulnerable code is reachable.
If the code is not compiled because the option is not set, then the particular compile is not vulnerable, and the CVE doesn't apply to that particular compile.

But because the code to perform those cryptographic operations is there, and can be easily enabled, and the documentation doesn't state that this code is vulnerable, this makes it a vulnerability.
See point 4.1.3 in https://www.cve.org/ResourcesSupport/AllResources/CNARules 

1. `USE_RSA_SUITES` is not documented
2. use of RSA ciphersuites in TLS is commonly understood to _not_ be inherently vulnerable (if the specification is followed correctly, the implementation will not be vulnerable)

therefore a user can expect that the resulting code will be safe, it's not, therefore it's a vulnerability

>it's not about editing source code, compilation flags can be specified as
>environment variable and as options to `make`

It doesn't matter how you do it, it requires deliberately changing the code or makefile or build process to create the vulnerability.

There are only two situations where it's enabled, one is for fuzz-testing to exercise code paths that wouldn't otherwise be available, the other is for static source code analysis with tools like Coverity and Prefast, again to open up code paths that otherwise wouldn't be available.  It can also be enabled manually in two specific test builds just to make sure the code still compiles OK, to avoid bit rot and verify that the fuzz-testing build will compile without errors.

>But because the code to perform those cryptographic operations is there, and
>can be easily enabled, and the documentation doesn't state that this code is
>vulnerable,

  undocumented - adjective
  un-doc-u-ment-ed an-dä-ky-men-td
  not documented: such as
  not supported by documentary evidence

It's an undocumented option used for internal testing.  How should the documentation, which doesn't exist because it's, you know, undocumented, state that this code is vulnerable?  And given that there are a large number of other debug/testing options like the fuzz-testing one, which disables most of the crypto, and the fault-injection one, which injects faults into crypto ops, shouldn't you also report those as CVEs given that anyone who reads through the code and figures out what they are can enable them and make themselves vulnerable?

What you've done is found that some code that's enabled only for custom test builds because it tends to have vulnerabilities, has vulnerabilities.  Great, and that's why it's only enabled for testing, specifically for the fuzzing build and the static analysis build, in order to make the code paths reachable by the testing tools that exercise them.

1. if you want to contest the assignment of the CVE this is the wrong place to do it, I'm not sure what's the correct procedure, but it likely involves contacting MITRE
2. while I used the TLS as the API endpoint to test it, the results show that the PKCS#1 v1.5 decryption in isolation is leaky too
3. given the above, I'd be really surprised if the RSA implementation itself wasn't leaky too, which would mean that both the OAEP decryption and signing are also vulnerable.
   I would have tested that code too, but you've refused to provide the test harness I've asked for and I don't have any more time to spend on your library (to create the harness myself)

>if you want to contest the assignment of the CVE this is the wrong place to
>do it, I'm not sure what's the correct procedure, but it likely involves
>contacting MITRE

According to MITRE the place to resolve it is the CNA, which is why I'm going through this discussion here.  So this is the correct place to handle it.  

In which case: Could someone from RH please withdraw this CVE?  There's no vulnerability present, which means there's nothing to fix, which means there's no reason for a CVE.

Oh, and also change the nonsensical "Fixed In Version" entry, since there's nothing to fix there's also no version that it's fixed in.  I've had people ask me what the fix was in 3.4.7 and had to explain to them that there is no fix in 3.4.7 since there's no vulnerability to fix.

>given the above, I'd be really surprised if the RSA implementation itself
>wasn't leaky too, which would mean that both the OAEP decryption and signing
>are also vulnerable.

Yup, there'll always be some new side-channel being discovered, which is why cryptlib goes to great lengths to never make the PKC ops accessible to an external attacker.  AFAIK the closest you can get is with SCEP, where an authorised SCEP client (not any random device on the internet, you need to submit a signed request) can perform a single query which shouldn't produce any useful results because of several other countermeasures and because it's buried under a pile of high-latency and variability ops like database accesses, but even then you only get a single query because it's a one-time operation.  So rather than playing a neverending game of cat and mouse with whatever this weeks' side-channel attack is, cryptlib tries to make it impossible, or at least near-impossible, for an attacker to be in a position to exploit it.

(In reply to pgut001 from comment #8)
> Yup, there'll always be some new side-channel being discovered, which is why
> cryptlib goes to great lengths to never make the PKC ops accessible to an
> external attacker.  AFAIK the closest you can get is with SCEP, where an
> authorised SCEP client (not any random device on the internet, you need to
> submit a signed request) can perform a single query which shouldn't produce
> any useful results because of several other countermeasures and because it's
> buried under a pile of high-latency and variability ops like database
> accesses, but even then you only get a single query because it's a one-time
> operation.  So rather than playing a neverending game of cat and mouse with
> whatever this weeks' side-channel attack is, cryptlib tries to make it
> impossible, or at least near-impossible, for an attacker to be in a position
> to exploit it.

Then put on the cryptlib page and user manual that you don't consider
side-channel attacks in scope for the module and we'll be done with it.

That has nothing to do with the CVE, if you don't like the manual then you're welcome to write your own one that says whatever you want it to.  At the moment all I need is a yes/no answer for whether Red Hat will withdraw this CVE for a nonexistent issue so I can escalate it to MITRE if Red hat won't do anything.