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 <https://www.redhat.com/> [email protected] IM: rogue <https://red.ht/sig> On Fri, Nov 3, 2023 at 4:30 PM Steven M Christey <[email protected]> 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: > > > > - CWE-1104: Use of Unmaintained Third Party Components (child of > CWE-1357) > - CWE-1329: Reliance on Component That is Not Updateable (child of > CWE-1357) > - 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) < > [email protected]> > *Sent:* Wednesday, November 1, 2023 10:49 AM > *To:* CWE Research Discussion <[email protected]> > *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 <[email protected]>; Christey, Steven M. < > [email protected]> > Cc: Wheeler, David A CTR (US) <[email protected]>; Buttner, Drew < > [email protected]>; CWE Research Discussion <[email protected]> > 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), > 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 > > • MySQL AB: > https://www.theregister.co.uk/2002/11/21/mysql_nusphere_settle_gpl_contract/ > > 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:[email protected] <[email protected]>] > > Sent: Thursday, August 23, 2018 3:11 PM > > To: Christey, Steven M. <[email protected]> > > Cc: Wheeler, David A CTR (US) <[email protected]>; Buttner, Drew < > [email protected]>; CWE Research Discussion <[email protected]> > > 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. <[email protected] < > Caution-mailto:[email protected] > <[email protected]%20%3c%20Caution-mailto:[email protected]%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 > > [email protected] < Caution-mailto:[email protected] > > > CLASSIFICATION: UNCLASSIFIED > > > > *From:* Wheeler, David A [email protected] > *Sent:* Wednesday, August 22, 2018 11:36 AM > *To:* Kurt Seifried [email protected]; Buttner, Drew [email protected] > *Cc:* CWE Research Discussion [email protected] > *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:[email protected]] > *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/ < Caution- > https://redislabs.com/community/commons-clause/ > > > > > 2) Caution- > https://www.theregister.co.uk/AMP/2018/08/21/intel_cpu_patch_licence/ > < Caution- > https://www.theregister.co.uk/AMP/2018/08/21/intel_cpu_patch_licence/ > > > > > 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 < > [email protected] < Caution-mailto:[email protected] > <[email protected]%C2%A0%3c%C2%A0Caution-mailto:[email protected]>> > > 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: [email protected] < Caution-mailto: > [email protected] > [Caution-mailto: > [email protected] < Caution-mailto: > [email protected] > ] 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 < > [email protected] < > Caution-mailto:[email protected] > <[email protected]%C2%A0%3c%C2%A0Caution-mailto:[email protected]> > > > > 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 >
