I think the main distinction that I want to be observed is that the CWEs are about vulnerabilities that are intrinsic to a piece of software (firmware, hardware) due to defects in its design or implementation, leading to unwanted behavior of the software (firmware, hardware) itself. Licensing issues involve a business process vulnerability due to defects in organizational practices around the software (e.g. not paying bills, or not respecting copyright law) leading to sticky business situations that can make continuing to rely on a given software component odious to the organization’s decision-makers.
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: Przemyslaw Roguski <progu...@redhat.com> Date: Thursday, November 9, 2023 at 1:45 PM To: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) <jonathan.w.hood6....@army.mil> Cc: Hatfield, Arthur <arthur_hatfi...@homedepot.com>, CWE Research Discussion <cwe-research-list@mitre.org> Subject: [EXTERNAL] Re: [EXT] RE: [Non-DoD Source] Re: Request for CWE: Improper Licensing (UNCLASSIFIED) Hi Jon, Thank you for accepting different opinions and I'm really happy that we have this discussion here. To be honest I never consider licensing issues as a potential problem that could be considered as a software weakness. But it seems Hi Jon, Thank you for accepting different opinions and I'm really happy that we have this discussion here. To be honest I never consider licensing issues as a potential problem that could be considered as a software weakness. But it seems that such a clarification is required. Let me repeat what I said before, regardless of the declared licence (valid or not) still you can be impacted if you run a malicious software/code. Like in Arthur's example. Thank you Arthur for your great examples! Jon, let me try to provide one more clarification. If your license management software will accept invalid licence and recognize it as a valid one, then yes, it's a licence related weakness, but it's a weakness in your software, not a problem with the wrong license itself that was provided. Depending on the root cause in such a case it could be "CWE-184: Incomplete List of Disallowed Inputs" weakness related to the license management software. You can blame the invalid license, but in fact the root cause and the weakness is in the license management software. Like it was said a few times, licence by itself, regardless if valid or not, cannot lead to vulnerability, hence cannot be classified as a weakness as well. Invalid licence can lead to legal problems, but this is a different story. I hope it helps. Best regards, Przemek Przemyslaw Roguski Security Architect, Product Security Red Hat Poland [redhat.com]<https://urldefense.com/v3/__https:/www.redhat.com/__;!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g6DOl5e6w$> progu...@redhat.com<mailto:progu...@redhat.com> IM: rogue [Image removed by sender.][red.ht]<https://urldefense.com/v3/__https:/red.ht/sig__;!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g5eCEVQgQ$> On Thu, Nov 9, 2023 at 6:49 PM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) <jonathan.w.hood6....@army.mil<mailto:jonathan.w.hood6....@army.mil>> wrote: I understand the position better with this analogy; thank you. I do believe that it is not a comparable analogy. Raising energy prices are not a property of the software. A software license is a property of the software, so the argument you make here is based off of an initial assertion that seems incorrect. Just because the fix for the weakness is voluntary doesn’t mean it’s not a weakness (IE: voluntarily stop using untrusted components, CWE-1357), though license enforcement may not be voluntary in all cases. “It doesn’t do anything to stop the execution of that software on any system not under your direct control where it’s already running” – I’m arguing that it does. When you incorporate software in violation of the license, you expose your product to injunction or restraint which absolutely can apply to the executing software directly under your control. For example, if the Home Depot website used software without licensing it, the software may have a license enforcement mechanism (and would have the legal authority to) shut off the software once the license becomes unverified, or Home Depot may receive an injunction to stop using the unlicensed software. Either of these scenarios would directly affect the availability of the Home Depot website and are reflected by an underlying coding weakness of relying on or incorporating improperly licensed components. Home Depot would not have a choice or voluntary decision in such a case, and even if it did, it's still a quantifiable threat to the software. “If we put license issues in CWE, then we might as well put rising energy costs in CWE.” Whether the energy is cut off through physical means (battery overload) or you can find a repeatable way to intentionally get a reliable power source shut off because the user can’t pay the power bill, it’s still a valid CWE-920 in my opinion. Likewise, whether you force license adherence with license management software or request that your users adhere to it voluntarily, it’s still an availability vulnerability that should also have a CWE to categorize it. Thank you for helping me understand the position better. I do not think I agree with it, but do understand the position better than I did before. Jon From: Hatfield, Arthur <arthur_hatfi...@homedepot.com<mailto:arthur_hatfi...@homedepot.com>> Sent: Thursday, November 9, 2023 9:54 AM To: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) <jonathan.w.hood6....@army.mil<mailto:jonathan.w.hood6....@army.mil>>; Przemyslaw Roguski <progu...@redhat.com<mailto:progu...@redhat.com>>; Steven M Christey <co...@mitre.org<mailto:co...@mitre.org>> Cc: CWE Research Discussion <cwe-research-list@mitre.org<mailto:cwe-research-list@mitre.org>> Subject: Re: [Non-DoD Source] Re: Request for CWE: Improper Licensing (UNCLASSIFIED) You don't often get email from arthur_hatfi...@homedepot.com<mailto:arthur_hatfi...@homedepot.com>. Learn why this is important [aka.ms]<https://urldefense.com/v3/__https:/aka.ms/LearnAboutSenderIdentification__;!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g6pc_OuHQ$> Look at it this way: Licensing issues are not a property of software, but of the society and economy around the software. A buffer overflow in a driver will crash your computer and make it unavailable any time data passes through it in a particular way, no matter who is causing that data to go through that buffer or why. A GPL-violation lawsuit will only stop you from distributing software if you voluntarily settle or you lose the lawsuit, and even then that’s basically going to require voluntary action on your part to stop using and/or distributing the software. It doesn’t do anything to stop the execution of that software on any system not under your direct control where it’s already running. Availability of the software in this case is not affected by a “coding weakness,” but by your organizational response to social, legal, and economic pressure. If we put license issues in CWE, then we might as well put rising energy costs in CWE. A surprise jump in your power bill could affect the availability of your application if you respond to the bill by voluntarily turning off your computer. 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: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) <jonathan.w.hood6....@army.mil<mailto:jonathan.w.hood6....@army.mil>> Date: Thursday, November 9, 2023 at 10:26 AM To: Przemyslaw Roguski <progu...@redhat.com<mailto:progu...@redhat.com>>, Steven M Christey <co...@mitre.org<mailto:co...@mitre.org>> Cc: CWE Research Discussion <cwe-research-list@mitre.org<mailto:cwe-research-list@mitre.org>> Subject: [EXTERNAL] [EXT] RE: [Non-DoD Source] Re: Request for CWE: Improper Licensing (UNCLASSIFIED) I respectfully disagree with this. Using a license incorrectly causes an availability issue directly, and availability is one of the cybersecurity principles that represent weaknesses and vulnerabilities by the definitions I am aware of. Can you please help me understand what definition CWE is using for each? The nearest definitions I can find are: “A ‘weakness’ is a condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities” (https://cwe.mitre.org/about/new_to_cwe.html [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fcwe.mitre.org*2Fabout*2Fnew_to_cwe.html&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797306823*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=ekQkjLz9cIVGY74qd89CJG*2Bj2aXTnQAUgY8CjZCE9Lc*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g5KdP4kTA$>). Following the vulnerability theory (https://cwe.mitre.org/documents/vulnerability_theory/intro.html [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fcwe.mitre.org*2Fdocuments*2Fvulnerability_theory*2Fintro.html&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797306823*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=fNs2PJegzxvQD737UdL*2FxOgnyy4hg57o7ehwjtfBzF0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g7J2qELiA$>) suggests that we need to have a PRODUCT implementing FEATURE by performing certain BEHAVIORS that operate on RESOURCES. I will assume these definitions in my disagreement below, and acknowledge that my basic definitions of some of these terms may be off. The core question is therefore: is a license violation a vulnerability by the vulnerability theory used by the CWEs? I argue in the affirmative. You state, “No doubt that invalid licenses are a serious problem from the security perspective, but it's more a supply chain issue and legal problem.” Then a PRODUCT implementing software with a “supply chain issue” or “legal problem” to achieve its behavior on its resources produces an availability security impact against PRODUCT. If you want to identify it more generally as “supply chain issue” or “legal insufficiency,” it’s still a vulnerability that directly affects availability, incurs technical debt, and inflicts reputation/brand damage (https://cwe.mitre.org/cwraf/creatingyourownvignettes.html [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fcwe.mitre.org*2Fcwraf*2Fcreatingyourownvignettes.html&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797306823*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=*2FJJlBMw6PkmQvgJV1kEw*2FopAQ0Zz9QWhRCAH8NSVg*2Fk*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g4hAhmxfw$>). I believe that more specific supply chain or legal issues are appropriate as well (and license violations would be a specific example), but these two general classes of vulnerabilities you’ve identified also meet the criteria for becoming a CWE. CWE-1357 almost meets some of this definition as well. Instead of a license-violating component being “not sufficiently trusted to meet expectations for security” (with availability being part of the security definition), it would be nice to have a CWE that can refer to a component (trusted or not) that in fact does not meet security expectations because of “supply chain” or “legal” vulnerabilities. Can you please further explain why a “supply chain issue and legal problem” is an abuse of the weakness definition? I feel like you acknowledge it’s a weakness while also saying it’s an abuse of the definition of a weakness, which indicates that I’m not understanding some of your argument. You lose me at “Invalid license itself cannot lead to a vulnerability just like that.” How is a coding weakness that affects availability not a distinct, individual vulnerability, regardless of what other vulnerabilities may also be in the software? Sincere thanks for your response and interaction, Jon From: Przemyslaw Roguski <progu...@redhat.com<mailto:progu...@redhat.com>> Sent: Sunday, November 5, 2023 1:21 PM To: Steven M Christey <co...@mitre.org<mailto:co...@mitre.org>> Cc: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) <jonathan.w.hood6....@army.mil<mailto:jonathan.w.hood6....@army.mil>>; CWE Research Discussion <cwe-research-list@mitre.org<mailto:cwe-research-list@mitre.org>> Subject: [Non-DoD Source] Re: Request for CWE: Improper Licensing (UNCLASSIFIED) You don't often get email from progu...@redhat.com<mailto:progu...@redhat.com>. Learn why this is important [aka.ms]<https://urldefense.com/v3/__https:/aka.ms/LearnAboutSenderIdentification__;!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g6pc_OuHQ$> Hi All, In my personal opinion, adding new weakness or renaming existing one to something more "licensing" related is abuse of the weakness definition. We defined the weakness and vulnerability definitions a long time ago and any licensing problems do not fit the weakness use case. The real-world examples provided in this thread indicate that there were license problems, but it's only a side effect of the problem. Let me explain it in a different way. If you use a component or 3rd party software where it is a good, correct licence, but that component is not maintained correctly or has some vulnerabilities that some day lead to an exploit and successful attack, then it doesn't matter that there was a correct licence. No doubt that invalid licenses are a serious problem from the security perspective, but it's more a supply chain issue and legal problem. Invalid licence itself cannot lead to a vulnerability just like that. There must be another weakness that can lead to a vulnerability. Licences should be registered and monitored similarly to the components (artifacts) provenance, which is in scope of SBOMs. Hence adding a new weakness licensing related is not a good idea in my opinion. Best regards, Przemek Przemyslaw Roguski Security Architect, Product Security Red Hat Poland [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fwww.redhat.com*2F&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797306823*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=OuTHysdcxJUynvCzSfaLnm3T*2B9fXSp52daXWFKrK2jg*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g4gRXtgiw$> progu...@redhat.com<mailto:progu...@redhat.com> IM: rogue [Image removed by sender.][usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fred.ht*2Fsig&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797306823*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=65I4eUMFCVaaK2995CcaV*2F3ZevoUI*2Bn*2FsDIMiEPuJDA*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g7hvbyXlQ$> On Fri, Nov 3, 2023 at 4:30 PM Steven M Christey <co...@mitre.org<mailto:co...@mitre.org>> wrote: All, While “licensing problems” per se does not have any direct coverage in CWE, there are indirect implications for security, e.g., it affects maintainability and might affect ability to apply security patches. Since 2018, we’ve added several newer CWE entries related to system components that might already be applicable; we could possibly modify one of them to name licensing as a consideration. The most applicable would be CWE-1357: Reliance on Insufficiently Trustworthy Component. “The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.” Other CWEs in the same general area: 1. CWE-1104: Use of Unmaintained Third Party Components (child of CWE-1357) 2. CWE-1329: Reliance on Component That is Not Updateable (child of CWE-1357) 3. CWE-1395: Dependency on Vulnerable Third-Party Component I’d argue that there is already some overlap between these CWE entries, which we want to avoid as much as possible in CWE. So I would want to be very careful about creating a brand-new CWE just for licensing. Adapting the phrasing of the original proposal, it seems possible that a new "Use of Unauthorized Software" CWE could be created that is a parent of CWE-1357. However, there would need to be a strong case made that it isn’t an exact duplicate, i.e., are there weaknesses in this area that can NOT be described as “insufficiently trustworthy” in this sense? Any other input is welcome. - Steve From: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) <jonathan.w.hood6....@army.mil<mailto:jonathan.w.hood6....@army.mil>> Sent: Wednesday, November 1, 2023 10:49 AM To: CWE Research Discussion <cwe-research-list@mitre.org<mailto:cwe-research-list@mitre.org>> Subject: [EXT] RE: Request for CWE: Improper Licensing (UNCLASSIFIED) I did want to renew this discussion. In light of the increased focus on supply chain risk management and composition analysis, the licensing issues and weaknesses in aggregated software are becoming more of a problem. Being able to categorize these weaknesses meaningfully would be helpful. Jon -----Original Message----- From: Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) Sent: Monday, October 15, 2018 5:01 PM To: Kurt Seifried <k...@seifried.org<mailto:k...@seifried.org>>; Christey, Steven M. <co...@mitre.org<mailto:co...@mitre.org>> Cc: Wheeler, David A CTR (US) <dwhee...@ida.org<mailto:dwhee...@ida.org>>; Buttner, Drew <abutt...@mitre.org<mailto:abutt...@mitre.org>>; CWE Research Discussion <cwe-research-list@mitre.org<mailto:cwe-research-list@mitre.org>> Subject: Re: Request for CWE: Improper Licensing (UNCLASSIFIED) CLASSIFICATION: UNCLASSIFIED I wanted to add another data point to this: suppose that there's a project that falls under DFARS Regulation 252.227-7014 (https://www.acq.osd.mil/dpap/dars/dfars/html/current/252227.htm#252.227-7014 [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fwww.acq.osd.mil*2Fdpap*2Fdars*2Fdfars*2Fhtml*2Fcurrent*2F252227.htm*23252.227-7014&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797306823*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=2Ly87yXs2rlinnBNqchubWYt340b5lgqX6m*2BxAWdmxk*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g5j4g47Gw$>), but the new contractor tries to use the software commercially. This could have been "exploited by an attacker" by suing the program, legal confiscation, or a fielding stay injunction. Real-world examples: • ReactOS: https://en.wikipedia.org/wiki/ReactOS#Internal_audit [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fen.wikipedia.org*2Fwiki*2FReactOS*23Internal_audit&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797306823*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=xjWSY8AnOFcljWhLpW9Qmmg*2F6MIBxWPUJLMLoiLR1ew*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g5DSF8P4w$> • MySQL AB: https://www.theregister.co.uk/2002/11/21/mysql_nusphere_settle_gpl_contract/ [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fwww.theregister.co.uk*2F2002*2F11*2F21*2Fmysql_nusphere_settle_gpl_contract*2F&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797306823*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=ofc8WDP9lUDKYjxMBliCL*2FUNnhPpCvW6vXC0L6WiGYw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g699SyTVg$> In both of these cases, the integrity of the software was allegedly tainted, and availability of the software (ReactOS through their website, and MySQL through NuSphere) was demonstrably compromised. • Artifex v. Hancom — Hancom stopped distributing that portion of their software, again exploiting the availability. That being said, it's difficult to articulate the specific technical exploitation path without also including other intangible weaknesses such as "Susceptible to DMCA takedown notices" or "Written by a lawsuit-happy contractor." Perhaps an "Unauthorized use of software" CWE would cover the multitude of issues behind the licensing. It has a tangible behavior (using unauthorized software), a specified resource (the software, involved patents, licensing, and/or policies), a violation of desired properties (written permission to use the software), and several exploitation paths: • lawsuit • confiscation • DMCA takedown Jon -----Original Message----- From: Kurt Seifried [mailto:k...@seifried.org] Sent: Thursday, August 23, 2018 3:11 PM To: Christey, Steven M. <co...@mitre.org<mailto:co...@mitre.org>> Cc: Wheeler, David A CTR (US) <dwhee...@ida.org<mailto:dwhee...@ida.org>>; Buttner, Drew <abutt...@mitre.org<mailto:abutt...@mitre.org>>; CWE Research Discussion <cwe-research-list@mitre.org<mailto:cwe-research-list@mitre.org>> Subject: [Non-DoD Source] Re: Request for CWE: Improper Licensing (UNCLASSIFIED) All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ________________________________ I would class it more as an exposure type of issue, in that while not directly exploitable it does open you up to new problems that didn't exist before. Like a freeze attack on an update server, I can't diretly exploit that to hack a box, but if I prevent you getting updates for a while, eventually you'll be vulnerable to something I can exploit. On Thu, Aug 23, 2018 at 1:49 PM, Christey, Steven M. <co...@mitre.org < Caution-mailto:co...@mitre.org <mailto:co...@mitre.org%20%3c%20Caution-mailto:co...@mitre.org%20> > > wrote: Using a general phrase of "Licensing Issue" is not particularly appropriate for CWE in that, typically, we try to write CWE descriptions that describe <behaviors> that operate on <resources> in ways that violate desired <properties> that, under the right circumstances, can be exploited by <attackers> to cross a security boundary. There's a similar approach for names, specifically so that generic terms like "issue" don't mislead CWE users into thinking they understand a CWE when doing mapping. I still find it difficult to figure out where or how attackers play a role in terms of licensing, although the role of licensing changes in delaying or preventing security patches does resonate with me - the system can be put into a state that attackers can exploit. However, there are many other programmer practices like "not having a complete test set" or "setting bug report to wrong fix priority" or any of dozens of other practices that I'm not sure we're quite ready to include in CWE yet. Note - I'm not stating any kind of official position on how/whether CWE should include licensing, just some thoughts. - Steve -- Kurt Seifried k...@seifried.org<mailto:k...@seifried.org> < Caution-mailto:k...@seifried.org<mailto:k...@seifried.org> > CLASSIFICATION: UNCLASSIFIED From: Wheeler, David A dwhee...@ida.org<mailto:dwhee...@ida.org> Sent: Wednesday, August 22, 2018 11:36 AM To: Kurt Seifried k...@seifried.org<mailto:k...@seifried.org>; Buttner, Drew abutt...@mitre.org<mailto:abutt...@mitre.org> Cc: CWE Research Discussion cwe-research-list@mitre.org<mailto:cwe-research-list@mitre.org> Subject: [Non-DoD Source] RE: Request for CWE: Improper Licensing (UNCLASSIFIED) All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ________________________________ I agree that improper licensing (overall) is a problem, but I think there needs to be at least one more specific CWE as well: “License change forbids previously allowed activity”. Presumably this would be a sub-category. In *both* of the cases you cite, it *was* okay to do something in one version, but the newer version changed to a license that forbid previously-allowed activities. It is this *change* of license that is especially likely to cause problems, since people often don’t re-review licenses when they simply upgrade a component. In particular, lawyers often get involved reviewing licenses when components are *first* brought in, but often no one knows to even *check* that there’s been a significant change in conditions. --- David A. Wheeler From: Kurt Seifried [Caution-mailto:k...@seifried.org<mailto:k...@seifried.org>] Sent: Wednesday, August 22, 2018 12:03 PM To: Buttner, Drew Cc: CWE Research Discussion Subject: Re: Request for CWE: Improper Licensing (UNCLASSIFIED) So some new stuff has come to light recently: 1) Caution-https://redislabs.com/community/commons-clause/ [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fredislabs.com*2Fcommunity*2Fcommons-clause*2F&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797306823*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=VixJ*2BYClQ4hjKOnSSpuLrV0AvXg8LHG6sm55bb0o3EQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g78VlEoJA$> < Caution-https://redislabs.com/community/commons-clause/ [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fredislabs.com*2Fcommunity*2Fcommons-clause*2F&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797306823*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=VixJ*2BYClQ4hjKOnSSpuLrV0AvXg8LHG6sm55bb0o3EQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g78VlEoJA$> > 2) Caution-https://www.theregister.co.uk/AMP/2018/08/21/intel_cpu_patch_licence/ [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fwww.theregister.co.uk*2FAMP*2F2018*2F08*2F21*2Fintel_cpu_patch_licence*2F&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797463069*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=VyruKo2D3fvbs5r0GLi5TeGloCZGluIeAxa5vAM0U7c*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g7v2u00RQ$> < Caution-https://www.theregister.co.uk/AMP/2018/08/21/intel_cpu_patch_licence/ [usg01.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg01.safelinks.protection.office365.us/?url=https*3A*2F*2Fwww.theregister.co.uk*2FAMP*2F2018*2F08*2F21*2Fintel_cpu_patch_licence*2F&data=05*7C01*7Cjonathan.w.hood6.ctr*40army.mil*7C0ea691b357a8445ee17808dbe13cdb3f*7Cfae6d70f954b481192b60530d6f84c43*7C0*7C0*7C638351423797463069*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=VyruKo2D3fvbs5r0GLi5TeGloCZGluIeAxa5vAM0U7c*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g7v2u00RQ$> > so in case #1 we now have a situation where cloud providers and other places cannot update redis components if they sell it as a service due to the license changes. In case #2 we have Debian users left with a VERY a painful set of steps to take to manually update the microcode (rather than linux just magically doing it at boot time). I think in light of the above we should revisit this CWE and consider it for inclusion as it clearly has real world consequences and is becoming a problem. On Mon, May 21, 2018 at 8:46 AM, Buttner, Drew <abutt...@mitre.org < Caution-mailto:abutt...@mitre.org <mailto:abutt...@mitre.org%C2%A0%3c%C2%A0Caution-mailto:abutt...@mitre.org> > > wrote: CWE Community, Thank you to all that weighed in on this topic and added to the discussion earlier this month. The CWE team found the discussion very enlightening, and it really helped us understand this issue that we didn't know much about. However, our feeling is that improper licensing is outside of CWE's current scope. Although it is a way to impact software and its usage, we feel that this is not through the technical exploitation of a software security weakness in architecture, design, or code. Rather, it is though policy/programmatic exploitation. Looking at the hypothetical example provided, software that includes some improper licenses may be forced offline and become unavailable, but technically the software still works as intended. This is very different from a weakness in how resources are managed that causes an application to allocate all its handles and then become unavailable. The availability issue with licensing surrounds a policy that the software shall no longer be used. In many ways, there is similarity here with supply chain issues where one disrupts a supplier to stop/limit a product from being delivered, and hence make it not available. We feel that these types of issues, although legitimate, are not within the current scope of CWE which focuses on architecture, design, and coding weaknesses. Going forward, we will be looking to expand the scope of CWE to include certain quality related issue. As this happens, the scope may broaden to include some issues similar to improper licensing and within areas beyond the three mentioned above. If that is the case, then this discussion we be brought back to the forefront. We are still open for discussion on either the specific issue, or with our defined scope. We very much value feedback so please don't hesitate to share opinions if you have them. Thanks Drew -----Original Message----- From: owner-cwe-research-l...@lists.mitre.org<mailto:owner-cwe-research-l...@lists.mitre.org> < Caution-mailto:owner-cwe-research-l...@lists.mitre.org<mailto:owner-cwe-research-l...@lists.mitre.org> > [Caution-mailto:owner-cwe-research-l...@lists.mitre.org<mailto:owner-cwe-research-l...@lists.mitre.org> < Caution-mailto:owner-cwe-research-l...@lists.mitre.org<mailto:owner-cwe-research-l...@lists.mitre.org> > ] On Behalf Of Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) Sent: Monday, April 30, 2018 10:52 AM To: cwe-research-list CWE Research Discussion <cwe-research-l...@lists.mitre.org < Caution-mailto:cwe-research-l...@lists.mitre.org <mailto:cwe-research-l...@lists.mitre.org%C2%A0%3c%C2%A0Caution-mailto:cwe-research-l...@lists.mitre.org> > > Subject: Request for CWE: Improper Licensing (UNCLASSIFIED) CLASSIFICATION: UNCLASSIFIED CWE Team, We've run into cases where a software license is being violated. A few generalized scenarios we've run into lately: • Someone violates the GPL in one of the many ways that the GPL can be violated (I'm not going to elaborate on this much; I like the GPL and am only using it as an example of a very-easy-to-violate license) • Someone partners with a school on an STTR from the government ⁃ The school assigns the task to a poor grad student ⁃ The grad student implements the academic license of a library they want to use ⁃ The grad student turns in a working solution with the academic license unknowingly embedded ⁃ The PI on the STTR turns in the working solution ⁃ The working solution is incorporated into a commercial project without switching to the commercial version of the dependency • Someone copyrights and licenses their software in an overly-restrictive or illegal way (re: Bayh-Dole Act IP with "royalty-free use by or on behalf of the government") Usually, the software team is ignorant of the issue they've introduced with the licenses. Nevertheless, inherent legal issues become cybersecurity concerns, especially when they can affect the availability and rights to use the software. Proposed CWE Title: Improper Licensing Impacts: Availability Description: Licensing issues indicate poor adherence to copyrights and other legal requirements. License violations can take many forms, and each can be costly to an organization. Several include: • Reliance, in a commercial solution, on software licensed for non-commercial use only. • Use of expired licenses • Including unlicensed components into a solution • Violating a license's terms • Placing software under an illegal or overly-restrictive license Each issue introduces legal risks that can affect the availability of the solution. Modes of Introduction: Implementation Applicable Platforms: All Likelihood of Exploit: Low I'm in favor of having a catch-all licensing issue CWE. Alternatively, higher fidelity may be achieved by creating a category and CWE hierarchy: • Category: Licensing Issues ⁃ CWE: Reliance on Incorrect License ⁃ CWE: Use of Expired License ⁃ CWE: Reliance on Unlicensed Component ⁃ CWE: Improper Adherence to License Terms ⁃ CWE: Institution of an Overly-Restrictive or Illegal License This may need to be moved under the CQEs once they are merged with CWEs. Jon ________________________________ 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. ________________________________ 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.
