Re: [EXT] Proposal: Add "Insecure default" as a general CWE category (per "Secure-by-design" paper)
> * By default it uses an external network connection that is NOT authenticated or encrypted. Network connections should be authenticated & encrypted (e. g. , TLS, SSH, etc. ). If a user specifically requests it (e. g. , non-default config
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message originates outside of MITRE. If you feel this is suspicious, please report it via "Report Suspicious Email" button in Outlook.
ZjQcmQRYFpfptBannerEnd
> * By default it uses an external network connection that is NOT authenticated or encrypted. Network connections should be authenticated & encrypted (e.g., TLS, SSH, etc.). If a user specifically requests it (e.g., non-default config or "http://") that's fine, but if it's unspecified, it must be authenticated & encrypted. Protocols like telnet (port 80) should only work if the user specially configured it.
> On Jan 10, 2024, at 1:05 AM, Kurt Seifried wrote:
> One comment: it's not always up to users, e.g. I'm just clicking links, I still occasionally run across http:// stuff, it's not like I want to use it... I would suggest it's time to draw a line in the sand on this topic, especially for http/https.
I agree, this will come up often, so this is the kind of detail it would be wise to gain agreement on (if possible).
In this case I think we have 2 users, the one using the link (e.g., by clicking on the link) and the one who specified the protocol ("http://" in this case). I'd be willing to accept that if someone *expressly* says they want the recipient to use the insecure protocol ("http://"), then it's okay to use it *because* that was what was expressed. In this case, the problem isn't that the *browser* used http (that's what it was told to do), the problem is that http was specified at all (so the "insecure default" vulnerability would charged against the website that specified http:). If we're going to claim it's a security vulnerability to use http on the public web, then the fault would be whoever stated that http was to be used.
I can see a counter-argument, that is, web browsers shouldn't support http at all, and/or should always try to use https even when http is specified, and then only back down if https fails to work when given an http link & they have no HSTS or similar information suggesting that https should be used.
It's a tricky situation, and I can see good arguments either way. I could be easily swayed one way or another right now.
> * It has a default password that's known to anyone other than that specific user. it's fine for a system to request a password on startup, or have a unique password set per instance, but a default password shared among instances is insecure.
> I would also make sure that the password that is uniquely set is not predictable, e.g. some devices use the hardware MAC address as the password:
>
> https://www.qnap.com/en-in/how-to/faq/article/default-password-of-admin-is-changed-to-first-mac-address-after-qts-4-4-2
>
> So if the attacker is on the LAN... or device makers use known ranges of MAC addresses .. which they do...
Fair enough. "Default password" was an example of a bad default, and "default password" is a special case of the more general bad default "predictable password".
> * Uses a known insecure algorithm for security purposes, e.g., MD5 or SHA-1 or DES as a security mechanism. Non-security uses are fine.
> Can you define security/non security?
Overall, "Security requirements can be broken by available computing capabilities".
DES is a symmetric encryption algorithm, its 56-bit key is so short it's vulnerable to brute force breaking.
Cryptographic hash functions must meet 3 criteria that MD5 & SHA-1 no longer meet, e.g.
https://duo.com/decipher/sha-1-fully-and-practically-broken-by-new-collision
https://shattered.io/
--- David A. Wheeler
Re: [EXT] Proposal: Add "Insecure default" as a general CWE category (per "Secure-by-design" paper)
> On Jan 9, 2024, at 3: 56 PM, Hatfield, Arthur wrote: > > I do believe that applications, passwords, and protocols count as “resources,” and that the default configuration that ships with an application, ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message originates outside of MITRE. If you feel this is suspicious, please report it via "Report Suspicious Email" button in Outlook. ZjQcmQRYFpfptBannerEnd > On Jan 9, 2024, at 3:56 PM, Hatfield, Arthur wrote: > > 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. I think few people would list a password or a protocol as a "resource". If CWE-1188 is to be the generic weakness for insecure defaults, then I think it MUST be renamed from "Initialization of a Resource with an Insecure Default" to "Insecure Default". If that's the plan, the words "initialization" and "resource" are adding no value. Put another way: if everything is a resource, then there's no need to mention the word resource, as it's not distinguishing any cases. Whatever the CWE is, I'd add examples. Here are a few ideas: * By default it uses an external network connection that is NOT authenticated or encrypted. Network connections should be authenticated & encrypted (e.g., TLS, SSH, etc.). If a user specifically requests it (e.g., non-default config or "http://") that's fine, but if it's unspecified, it must be authenticated & encrypted. Protocols like telnet (port 80) should only work if the user specially configured it. * It has a default password that's known to anyone other than that specific user. it's fine for a system to request a password on startup, or have a unique password set per instance, but a default password shared among instances is insecure. * Uses a known insecure algorithm for security purposes, e.g., MD5 or SHA-1 or DES as a security mechanism. Non-security uses are fine. --- David A. Wheeler
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 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 ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message originates outside of MITRE. If you feel this is suspicious, please report it via "Report Suspicious Email" button in Outlook. ZjQcmQRYFpfptBannerEnd > On Jan 8, 2024, at 6:43 AM, Przemyslaw Roguski 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
[EXT] Proposal: Add "Insecure default" as a general CWE category (per "Secure-by-design" paper)
I propose that CWE add "Insecure default" as a *general* category of vulnerabilities, instead of only covering a few special cases as it does now. Here's my rationale. The paper "Secure-by-Design: Shifting the Balance of Cybersecurity Risk: ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message originates outside of MITRE. If you feel this is suspicious, please report it via "Report Suspicious Email" button in Outlook. ZjQcmQRYFpfptBannerEnd I propose that CWE add "Insecure default" as a *general* category of vulnerabilities, instead of only covering a few special cases as it does now. Here's my rationale. The paper "Secure-by-Design: Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software" (revised October 25, 2023) was published by US CISA and 17 U.S. and international partners (including those in the UK, Norway, Korea, Japan, & many others). This "joint guidance urges software manufacturers to take urgent steps necessary to ship products that are secure by design and revamp their design and development programs to permit only secure by design products to be shipped to customers." Their rationale is simple: Most developers and users do *NOT* specially configure software to make software secure; most accept the defaults. Some manufacturers release "hardening guides", but they're completely ineffective. As noted in the paper, "Relying on hardening guides simply does not scale". You can see their October 2023 version here: * * I believe this paper represents a broad consensus among governments that software that is insecure by default is *NOT* secure, even if it is theoretically possible to "configure it into being secure". Today, many programs & libraries have vulnerabilities by default that are *not* fundamentally necessary for their proper operation. Unfortunately, CVE assignments are usually rejected for those cases because it's theoretically possible to use them securely. E.g., many XML parsers are vulnerable by default to external entity injection (XXE), but CVEs aren't assigned in these situations because they're safe to use as long as every developer worldwide performs heroic extra efforts to secure the thousands of components they reuse. That rarely happens, so security rarely happens. The current situation means that there is *no* incentive for developers of programs & libraries to make their software secure by default, *and* there's no mechanism for developers & users to separately learn that the default use is insecure. CWE does have a large number of specialized cases of "insecure default". However, as far as I can tell, nothing covers the general case. Examples of specific cases are: * CWE-1188: Initialization of a Resource with an Insecure Default * CWE-1394: Use of Default Cryptographic Key * CWE-1393: Use of Default Password * CWE-276: Incorrect Default Permissions * CWE-453: Insecure Default Variable Initialization * CWE-798: Use of Hard-coded Credentials * CWE-665: Improper Initialization (this is a little bit of a stretch) * CWE-1221: Incorrect Register Defaults or Module Parameters (this is hardware not software) What's needed is a *general* CWE covering "not secure by default" cases. This is somewhat related to OWASP Top 10 A05, Security Misconfiguration . Misconfiguration is less likely if the default is secure. It's also related to OpenSSF's Alpha-Omega, which is working to improve the security of open source software (OSS) projects (which is where this discussion came up). As always, the devil is in the details. For example, I'd be willing to accept the definition as one that only covered cases where it's theoretically *possible* for it to be configured to be secure-by-default (e.g., it's not possible for strcpy() to be secure by default from memory corruption, so it cannot ever be secure by default). An interface that "cannot be made safe to use" does seem different than "insecure by default but theoretically possible to configure into being secure". I'm sure there will be many discussions. That said, the first step is to acknowledge that "insecure by default" *IS* a security vulnerability & specifically label it as a category of vulnerability. People can then work to carefully define it & come to a general consensus. Anyway, I hope you find this idea helpful. Thank you! --- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation
Re: CWE/CAPEC Definitions
> On Jul 14, 2022, at 1:47 PM, SJ Jazz wrote: > > Vulnerability = weakeness + exploit > Or more specifically, > Vulnerability = weakeness(es) + known exploit I believe the first one is the right one. that is, vulnerabilities = weakness + exploit exists. If vulnerabilities are only known vulnerabilities, then you can't discover vulnerabilities. It would mean the mere act of looking creates vulnerabilities. --- David A. Wheeler
Re: CWE-653 name
> On Jun 30, 2022, at 11:49 AM, Kurt Seifried wrote: > > One thing I'm noticing when I search the CWE database: > > It's a nightmare. Really bad. Like... is the keyword I want "identical", > "shared", "reused"... > ... > > I think we should worry a LOT less about getting the perfect short/exact > wording and more about descriptive titles and text that people can actually > find and use. I agree that longer titles, to clarify the topic, are more important than shortness. More words also make it easier for search engines (like Google's) to find it. In addition, adding more text in the detailed description to explain alternative terms might also help when searching. --- David A. Wheeler
Re: [External] - RE: Bad loop construct
I think there's an easy way to distinguish "likely problem" from "likely false positive" in this case. If a shell loops over one value AND that value is the name a previously-assigned variable, that is likely a variable name missing its "$". Otherwise it's plausibly a loop over 1 value (which is a little odd, but not insane and such a construct is less likely to be an error). I doubt such a construct often leads to a vulnerability. It seems like the sort of thing likely to be detected in practically any testing, since it's deterministic & doesn't depend on attacker input at all. --- David A. Wheeler
