About configurations, I’m still scratching my head about where PrintNightmare’s “Insecure by design” would fall (fail?).
Best, Sebastian > 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
