About configurations, I’m still scratching my head about where PrintNightmare’s 
“Insecure by design” would fall (fail?). 


> On Sep 24, 2021, at 1:01 AM, Steven M Christey <co...@mitre.org> wrote:
> Just a couple quick comments since it’s late for me :)
> CWE-435: Improper Interaction Between Multiple Correctly-Behaving Entities 
> seems to cover the original question. CWE-435’s description says “An 
> interaction error occurs when two entities have correct behavior when running 
> independently of each other, but when they are integrated as components in a 
> larger system or process, they introduce incorrect behaviors that may cause 
> resultant weaknesses.” It’s interesting that this weakness is not so easily 
> found with keyword searches on the CWE web site, but I suspect that part of 
> the difficulty is that there is no widely-used term for this kind of issue. 
> (Similar for, say, “confused deputy” – you can only find it if you know the 
> term.) CWE-435 *is* a Pillar, however, so hierarchical-based browsing in view 
> 1000 might have allowed it to be discovered more quickly.
> Over the years, I’ve had a general unease about the desire to describe 
> weaknesses as “configuration” problems, but in the past year or two, I’ve 
> started thinking more about characterizing the mistake that’s reflected in 
> “what the configuration does” – just like what a coding error does, or a 
> design flaw. For example, “running with excessive privileges” can be done in 
> coding or in configuration (or be required by design) – the behavior/mistake 
> is still the same, regardless of the phase of the SDLC in which it occurs or 
> who introduced the mistake.
> - Steve
> From: Kurt Seifried <k...@seifried.org> 
> Sent: Thursday, September 23, 2021 11:20 PM
> To: Walton, Jeffrey <noloa...@gmail.com>
> Cc: CWE Research Discussion <cwe-research-list@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:
> https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=conjunction&search_type=all&isCpeNameSearch=false
> On Thu, Sep 23, 2021 at 8:16 PM Jeffrey Walton <noloa...@gmail.com> wrote:
> Hi Everyone,
> This made my radar recently: https://eprint.iacr.org/2021/923.pdf. 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)
> k...@seifried.org

Reply via email to