Rob, I believe it makes sense to update CWE-436 based on your suggestion. An immediate question is whether the clarification belongs in the extended description or the modes of introduction, although “Specification” is not currently treated as a distinct SDLC phase within the XML schema (pre-implementation, we mostly have just Requirements and Design/Architecture, and it seems to me that “specifications” can be developed in many different phases). Currently, CWE-436’s modes of introduction list both Implementation and Architecture/Design without further explanation, so that could be further expanded upon.
- Steve From: Rob Wissmann <rob.wissm...@nteligen.com> Sent: Tuesday, July 5, 2022 12:19 PM To: Steven M Christey <co...@mitre.org>; 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? 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<mailto:co...@mitre.org>> Sent: Monday, July 4, 2022 7:50 PM To: Seifried, Kurt <k...@seifried.org<mailto:k...@seifried.org>>; 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? 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>
