On Thu, Sep 23, 2021 at 11:02 PM 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. > > I'd forgotten this one. One comment: the multiple entities don't always behave correctly, e.g. they might be slightly out of spec, not enough to be a security issue on their own, but like a slightly misthreaded bolt plus a slightly misthreaded hole... (and the bolt vibrates out and stuff falls off your car). > > > 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. > Also in the system, the number of docker containers that run everything as root now... sigh. > > > - 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 > -- Kurt Seifried (He/Him) k...@seifried.org
