[EXT] Re: Cross-configuration attacks
You are right on spec not been comprehensive enough and most of this issue arise because the industry is embracing agile while attempting to drop waterfall. Both methodologies should be adopted and given priorities at different phases of the project cycle. Planning is crucial but most industry stakeholders are of the opinion that developer should hit the ground running on day one rather than first taking a preliminary holistic view with the architects. And again to be frank this loophole is an Operating System level lapse as only the OS utility can monitor and mitigate this issue efficiently. No CWE article is specific to this issue, you can only adapter one and again adaption has it's flaws. - OS can isolate processes except the user chooses otherwise like in the case of meltdown attack on browsers. - OS can provided options to limited process interaction in the case of iOS privacy tracking. - OS can generate logs of process communication while antiMalware or third-party tools can pick it up from there for analysis locally or sent to the cloud for global analysis which will give a better result. - and so much more. Fredrick Omeniho Tel: 7033894810 On Fri, Sep 24, 2021 at 2:03 PM Kerry Crouse wrote: > Frequently, items are not "out-of-spec" but the spec is simply not > comprehensive enough - a corner case has been missed, for instance. > > Kerry > > Kerry Crouse > The MITRE Corporation > 781-271-2061 > > > > > From: Kurt Seifried > Sent: Friday, September 24, 2021 10:08 AM > To: Steven M Christey > Cc: Walton, Jeffrey; CWE Research Discussion > Subject: Re: Cross-configuration attacks > > > > On Thu, Sep 23, 2021 at 11:02 PM Steven M Christey <mailto: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 mailto:k...@seifried.org>> > Sent: Thursday, September 23, 2021 11:20 PM > To: Walton, Jeffrey mailto: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 >
Re: Cross-configuration attacks
Frequently, items are not "out-of-spec" but the spec is simply not comprehensive enough - a corner case has been missed, for instance. Kerry Kerry Crouse The MITRE Corporation 781-271-2061 From: Kurt Seifried Sent: Friday, September 24, 2021 10:08 AM To: Steven M Christey Cc: Walton, Jeffrey; CWE Research Discussion Subject: Re: Cross-configuration attacks On Thu, Sep 23, 2021 at 11:02 PM Steven M Christey mailto: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 mailto:k...@seifried.org>> Sent: Thursday, September 23, 2021 11:20 PM To: Walton, Jeffrey mailto:noloa...@gmail.com>> Cc: CWE Research Discussion mailto: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 mailto: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 t
RE: Cross-configuration attacks
CWE-1197 (Integration Issues<https://cwe.mitre.org/data/definitions/1197.html>) and CWE-1276 (Hardware Child Block Incorrectly Connected to Parent System<https://cwe.mitre.org/data/definitions/1276.html>) 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 blocks. Thanks, Arun From: Kurt Seifried Sent: Thursday, September 23, 2021 8:20 PM To: noloa...@gmail.com Cc: 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: 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 mailto: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<mailto:k...@seifried.org>
Re: Cross-configuration attacks
On Thu, Sep 23, 2021 at 11:02 PM Steven M Christey 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 > *Sent:* Thursday, September 23, 2021 11:20 PM > *To:* Walton, Jeffrey > *Cc:* CWE Research Discussion > *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 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
RE: Cross-configuration attacks
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 Sent: Friday, September 24, 2021 8:22 AM To: Kurt Seifried ; 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 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: https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=conjunction&search_type=all&isCpeNameSearch=false<https://urldefense.com/v3/__https:/nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=conjunction&search_type=all&isCpeNameSearch=false__;!!F9svGWnIaVPGSwU!7i9uqNTeBJ2QgMLQY4HE_5nZAF0ZXkUgpsaxojaWXUbfdbBEdEmspR7eemDfGpIdqWJKzA$> On Thu, Sep 23, 2021 at 8:16 PM Jeffrey Walton mailto:noloa...@gmail.com>> wrote: Hi Everyone, This made my radar recently: https://eprint.iacr.org/2021/923.pdf<https://urldefense.com/v3/__https:/eprint.iacr.org/2021/923.pdf__;!!F9svGWnIaVPGSwU!7i9uqNTeBJ2QgMLQY4HE_5nZAF0ZXkUgpsaxojaWXUbfdbBEdEmspR7eemDfGpKYv5sk4w$>. 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
RE: Cross-configuration attacks
CWE-274 is about when software “incorrectly handles when it has insufficient privileges to perform an operation” which appears to be a relatively rare phenomenon. See the CVE examples – for example, CVE-2001-1564 is about the product trying to enforce resource limits after dropping privileges, but it can no longer do that operation because it’s running at lower privileges, thus allowing a bypass of quota. I’ve had a general impression that CWE-274 gets incorrectly mapped fairly frequently, although it isn’t quite clear to me why this confusion happens. CWE-250 “Execution with Unnecessary Privileges” seems appropriate for PrintNightmare, although I haven’t studied that vuln deeply. - Steve From: Steve Battista Sent: Friday, September 24, 2021 8:16 AM To: Steven M Christey Cc: Seifried, Kurt ; Walton, Jeffrey ; CWE Research Discussion Subject: Re: Cross-configuration attacks Print nightmare allows for non admins to install a driver that runs as admin. Current patch partially fixes this. I would vote for CWE-274. Get Outlook for iOS<https://aka.ms/o0ukef> From: SebastianGanson mailto:sebastiangan...@gmail.com>> Sent: Friday, September 24, 2021 4:28:07 AM To: Steven M Christey mailto:co...@mitre.org>> Cc: Seifried, Kurt mailto:k...@seifried.org>>; Walton, Jeffrey mailto:noloa...@gmail.com>>; CWE Research Discussion mailto:cwe-research-list@mitre.org>> Subject: Re: Cross-configuration attacks 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 mailto: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 mailto:k...@seifried.org>> Sent: Thursday, September 23, 2021 11:20 PM To: Walton, Jeffrey mailto:noloa...@gmail.com>> Cc: CWE Research Discussion mailto: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 mailto: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 authentic
Re: Cross-configuration attacks
Print nightmare allows for non admins to install a driver that runs as admin. Current patch partially fixes this. I would vote for CWE-274. Get Outlook for iOS<https://aka.ms/o0ukef> From: SebastianGanson Sent: Friday, September 24, 2021 4:28:07 AM To: Steven M Christey Cc: Seifried, Kurt ; Walton, Jeffrey ; CWE Research Discussion Subject: Re: Cross-configuration attacks 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 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 Sent: Thursday, September 23, 2021 11:20 PM To: Walton, Jeffrey Cc: CWE Research Discussion 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 mailto: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<mailto:k...@seifried.org>
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 Sent: Thursday, September 23, 2021 11:20 PM To: noloa...@gmail.com Cc: 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: 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 mailto: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<mailto:k...@seifried.org>
Re: Cross-configuration attacks
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 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 > Sent: Thursday, September 23, 2021 11:20 PM > To: Walton, Jeffrey > Cc: CWE Research Discussion > 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 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
RE: Cross-configuration attacks
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 Sent: Thursday, September 23, 2021 11:20 PM To: Walton, Jeffrey Cc: CWE Research Discussion 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 mailto: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<mailto:k...@seifried.org>
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 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
