I do believe that applications, passwords, and protocols count as “resources,” and that the default configuration that ships with an application, or is engineered into a system, would count as the “initialization” of that “resource.” That said, could CWE-1188 get some better demonstrative examples? Absolutely. To wit, one of the observed examples (CVE-2022-42467) of CWE-1188 isn’t about a vulnerability at all, but about a UI not requiring a password by default.
RT Hatfield | Staff Cybersecurity Analyst | BS CS, CCITP, CISSP The Home Depot | Cyber Threat Intelligence • arthur_hatfi...@homedepot.com<mailto:arthur_hatfi...@homedepot.com> • c...@homedepot.com<mailto:c...@homedepot.com> INTERNAL USE From: David A. Wheeler <dwhee...@linuxfoundation.org> Date: Tuesday, January 9, 2024 at 3:12 PM To: Przemyslaw Roguski <progu...@redhat.com> Cc: Alec J Summers <asumm...@mitre.org>, Murren, Andy <amur...@ieee.org>, CWE Research Discussion <cwe-research-list@mitre.org>, Michael Scovetta <michael.scove...@microsoft.com>, Michael Winser <micha...@xwind.io> Subject: [EXTERNAL] Re: [EXT] Proposal: Add "Insecure default" as a general CWE category (per "Secure-by-design" paper) > On Jan 8, 2024, at 6: 43 AM, Przemyslaw Roguski <proguski@ redhat. com> > wrote: > > Hello Everyone and Happy New Year to all of you! > > David, in my > opinion the CWE-1188: Initialization of a Resource > On Jan 8, 2024, at 6: 43 AM, Przemyslaw Roguski <proguski@ redhat. com> > wrote: > > Hello Everyone and Happy New Year to all of you! > > David, in my > opinion the CWE-1188: Initialization of a Resource with an Insecure Default > On Jan 8, 2024, at 6:43 AM, Przemyslaw Roguski <progu...@redhat.com> wrote: > > Hello Everyone and Happy New Year to all of you! > > David, in my opinion the CWE-1188: Initialization of a Resource with an > Insecure Default describes your "insecure default" general use case pretty > well. > See the extended description: > "Developers often choose default values that leave the product as open and > easy to use as possible out-of-the-box, under the assumption that the > administrator can (or should) change the default value. However, this > ease-of-use comes at a cost when the default is insecure and the > administrator does not change it." > > We could update this weakness with a more descriptive description and we > could update examples. I agree that CWE-1188 could be *rewritten* to become a general "insecure default". However, as written CWE-1188 is *not* clearly the same thing at all, and I think it'd be better to clearly identify a new CWE for this new (broader) category. When I want to know what a CWE really is, I look at its demonstrative example for clarification. The example describes a straight-up vulnerability in some PHP code when register_globals is enabled. An attacker can send a POST request with an unexpected third value 'authorized' set to 'true' and gain authorized status without supplying valid credentials. The problem, in this case, is that *attackers* can control the default value. You could disable register_globals, but you could *ALSO* rewrite the code as recommended so that attackers don't control the default value. The text of the CWE implies that the problem is that attackers can control the default value. (Using register_globals is still a terrible idea, but that's not relevant to this example.) Another clue that CWE-1188 isn't the general case is the extreme narrowness of its title. It says "Initialization of a Resource...". But resources are NOT relevant. I think what's needed is a CWE that says "Insecure Default" and NO OTHER TEXT IN THE TITLE. If there's additional text in its title, such as "initialization" or "resource", then that's different. This new CWE should cover ANY case where the default is insecure, including bad default passwords, bad default crypto algorithms/protocols, default passwords, insecure network protocols, and anything else where the default isn't the secure option. I don't think CWE-1188's scope should be changed so much as to be unrecognizable. There are many integers available for assignment :-). I think there needs to be a new CWE "Insecure Default". Once that's created, then CWE-1188 (& others) could be clarified as being specific examples of the more general case. It would be possible to generalize this existing CWE, but I fear that such a large change in meaning would be a problem. Again, the underlying issue is that modern systems are too complex to assume that people will configure it. Systems will, in almost all cases, do whatever the default is. If the default for "normal use" is insecure, then the software is insecure. --- David A. Wheeler ________________________________ The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
