I would seem, in my opinion and take on this matter, that it really boils down 
to human assumptions on functionality and ability.  This could be incorporated 
in CWE-1053 (Missing Documentation for Design) since the fault seems to come 
from an assumption of behavior (e.g. challenge/response).

Now this could be too much of a simplification of the problem, but it would 
seem the question is more about what is at the heart of this problem (i.e. the 
specific weakness being identified) than if the CWE contains appropriate 
coverage.  Since the purpose of the weaknesses are the general context of the 
potential issue and not the specifics of how they are exactly instantiated in 
the real world (more of a CVE entry) then it appears that there might be a few 
CWEs that could represent the issue.  It all just depends where we would like 
to draw the line in the case of this publication.

   - Paul

From: John Thomas <john.tho...@ldra-usa.com>
Sent: Friday, September 24, 2021 8:22 AM
To: Kurt Seifried <k...@seifried.org>; noloa...@gmail.com
Cc: cwe-research-l...@lists.mitre.org
Subject: RE: Cross-configuration attacks

I think the issue here is the ambiguity in the behavior. If App A knows App B’s 
behavior fully and with no ambiguity and App B knows how App A will respond 
fully and with no ambiguity, then it’s unlikely to be a problem.

The issue is that with the ambiguity, App A cannot fully know/anticipate App 
B’s behavior and/or vice versa. These ambiguities might be harmless within App 
A and within App B, but when they are exchanging information it becomes 
harmful. Indeed, this sort of vulnerability is more dangerous when happening 
between independent components than if it was just an internal issue (although 
this could also cause problems with internal communication when multiple 
engineers have different interpretations and later maintainers might not know 
the implicit choices), since it is highly likely that the designers of 
independent components will have different implicit assumptions. This line from 
the original paper I think supports my interpretation:
“The disagreements on the interpretation of the OpenPGP standard may raise 
doubts on the interoperability between the libraries… While in a basic scenario 
these three libraries can, to the best of our knowledge, in fact interoperate 
securely, we shall now see that some choices made by Crypto++ and gcrypt prove 
to be fatal in a broader context.” (pg. 5)

So at least part of the issue here is a failure of requirements/documentation, 
as much as it is a matter of handling potentially dangerous input (although 
that is also relevant for defense-in-depth).

Is there a CWE for ambiguity in security protocols between multiple parties?

With regards,
John Thomas

From: Kurt Seifried <k...@seifried.org<mailto:k...@seifried.org>>
Sent: Thursday, September 23, 2021 11:20 PM
To: noloa...@gmail.com<mailto:noloa...@gmail.com>
Cc: cwe-research-l...@lists.mitre.org<mailto:cwe-research-l...@lists.mitre.org>
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 
<noloa...@gmail.com<mailto:noloa...@gmail.com>> wrote:
Hi Everyone,

This made my radar recently: 
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