Steven,

Is there any room to update the description or extended description of CWE-436: 
Interpretation Conflict to suggest specs or requirements may be at fault for 
leaving certain behaviors up the implementation that should not be, leaving 
room for interpretation conflicts to occur and become vulnerabilities?

For example, the JSON spec is underspecified for certain error conditions, 
which leads to interoperability errors. 
https://bishopfox.com/blog/json-interoperability-vulnerabilities

Not sure if Kurt’s issue is an RFC issue but if the RFC doesn’t specify what a 
client should do when receiving a bad header field, it could be.

-Rob

From: Steven M Christey <co...@mitre.org>
Sent: Monday, July 4, 2022 7:50 PM
To: Seifried, Kurt <k...@seifried.org>; jonathan.w.hood6....@army.mil
Cc: CWE Research Discussion <cwe-research-list@mitre.org>
Subject: RE: [Non-DoD Source] Is there a CWE for this?

This is an interesting and simultaneously complicated question.

While the names and descriptions for CWE-140 through CWE-146 are not clear 
about the distinction, the mitigations are all about input, and their 
Class-level ancestor CWE-138: Improper Neutralization of Special Elements is 
input-focused: “The software receives input from an upstream component…” So, 
the intention of these CWEs was for input only.

As a side note, the names and descriptions for CWE-140 through CWE-146 should 
be modernized because of the possibility of misinterpretation, and the lack of 
emphasis on the intended behavior (also, was it really necessary to make 
variants for each type of “delimiter”? That PLOVER guy from 2006 has some 
explaining to do (for those who don’t get the joke, it was me)). These are 
early-day CWEs that reflected the focus on skilled vuln researchers, not 
developers.

In this case with the extra semicolon for includeSubdomains, deeper analysis is 
required. Kurt says that the semicolon is “not needed.” But is it technically 
allowed according to the spec (… and if so, <which> spec? HSTS? HTTP?) If a 
semicolon is technically allowed, then maybe there’s some kind of parsing error 
on the part of the client because it isn’t following the spec (CWE-684: 
Incorrect Provision of Specified Functionality )? But if both sides of this 
exchange are following some spec (with allowances for “undefined” behavior), 
then this could be regarded as CWE-436: Interpretation Conflict.

Parsing input and translating it to incorrect values is a gap in CWE that we’re 
aware of, but even if the issue is CWE-684 or some descendant of CWE-138, 
hopefully this will show that there are community-wide limitations in our 
language for classifying weaknesses that aren’t the “usual” basic issues like 
overflows and injection.

- Steve


From: Kurt Seifried <k...@seifried.org<mailto:k...@seifried.org>>
Sent: Sunday, July 3, 2022 3:47 PM
To: jonathan.w.hood6....@army.mil<mailto:jonathan.w.hood6....@army.mil>
Cc: CWE Research Discussion 
<cwe-research-list@mitre.org<mailto:cwe-research-list@mitre.org>>
Subject: Re: [Non-DoD Source] Is there a CWE for this?

I would prefer to split them because you have two possibilities:

1) fix the output
2) be more tolerant of input and maybe (safely?) try to suss out what happens, 
e.g. is there an attack scenario for an attacker injecting headers with an 
extra ; that are then parses in an HSTS scenario? I can't think of one, so it 
should be safe, but I could be wrong.



On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
<jonathan.w.hood6....@army.mil<mailto:jonathan.w.hood6....@army.mil>> wrote:
I see what you’re saying about the CWE-14[0-6] family being pretty limited to 
input processing when the issue could exist because of input or malformed 
output. Perhaps changing these to input/output would be more inclusive of this 
type of issue. Good catch.

From: Kurt Seifried <k...@seifried.org<mailto:k...@seifried.org>>
Sent: Friday, July 1, 2022 8:37 PM
To: CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION 
<CWE-RESEARCH-LIST@mitre.org<mailto:CWE-RESEARCH-LIST@mitre.org>>
Subject: [Non-DoD Source] Is there a CWE for this?

I ran across this today while auditing CSA services quarterly:

In bl.ink URL redirection service, as of 2022-07-01 an improperly formatted 
security header exists in the HSTS support, specifically, the header served is 
\"strict-transport-security: max-age=63072000; includeSubdomains;\" which 
contains an extra semicolon (the final one is not needed), this may result in 
some client ignoring the HSTS header and thus rendering this security 
protection ineffective.

there's some stuff for inbound/input/malformed/configuration/directive/etc, but 
I'm not seeing anything for malformed outbound configuration/output.

--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>


--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>

Reply via email to