CWE-1197 (Integration Issues<>) 
and CWE-1276 (Hardware Child Block Incorrectly Connected to Parent 
System<>) can cover these kinds 
of issues – where the both the individual IPs/blocks are fine by themselves, 
but there can be weaknesses in a parent component that instantiates both the 


From: Kurt Seifried <>
Sent: Thursday, September 23, 2021 8:20 PM
Subject: Re: Cross-configuration attacks

I assume by CVE you meant CWE, and no there isn't a CWE for "intersection" or 
"mismatch" attacks. I don't like the term cross-configuration unless it's 
actually applied to issues that are created by configuration issues, my concern 
would be technically any intersection vulnerability can be classed as a config 
issue because you could disable most things somehow/somwhere.

Perhaps we need CWE to not just cover weaknesses but normal behaviours so we 
can better describe "normal behaviour A + normal behavior B = weakness 
[described if not specific term exists).

Do we have a list of CVE "intersection" vulns to look at as a data set to see 
what is causing these? E.g. configs? badly written specifications that result 
in different interpretations? One good keyword is "conjunction" but also a lot 
of false positives:

On Thu, Sep 23, 2021 at 8:16 PM Jeffrey Walton 
<<>> wrote:
Hi Everyone,

This made my radar recently: The
interesting thing about the attack is, App A is considered secure in
isolation, and App B is considered secure in isolation, but when
interacting App A and B produce an insecure result.

We've seen bad interactions among components within the same app
before, like incorrectly combining authentication and encryption. But
in this case it is not the same app. Rather, the vulnerability is a
product of two distinct apps using slightly different implementation
details sharing data.

I'm wondering if there's a CVE to cover the scenario. Looking through
existing CVEs I don't see one that jumps out at me.


Here's from the abstract of the paper:

... ElGamal encryption has been used in many
different contexts, chiefly among them by the OpenPGP standard.
Despite its simplicity, or perhaps because of it, in reality there is a
large degree of ambiguity on several key aspects of the cipher. Each
library in the OpenPGP ecosystem seems to have implemented a
slightly different “flavour” of ElGamal encryption. While –taken in
isolation– each implementation may be secure, we reveal that in the
interoperable world of OpenPGP, unforeseen cross-configuration
attacks become possible. Concretely, we propose different such
attacks and show their practical efficacy by recovering plaintexts
and even secret keys.

Kurt Seifried (He/Him)<>

Reply via email to