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 <k...@seifried.org>
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
<co...@mitre.org<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 <k...@seifried.org<mailto:k...@seifried.org>>
Sent: Thursday, September 23, 2021 11:20 PM
To: Walton, Jeffrey <noloa...@gmail.com<mailto:noloa...@gmail.com>>
Cc: CWE Research Discussion
<cwe-research-list@mitre.org<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
<noloa...@gmail.com<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>
--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>
