Request for CWE: Improper Licensing (UNCLASSIFIED)

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Request for CWE: Improper Licensing (UNCLASSIFIED)

Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
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

Dr. Jonathan Hood
Software Assurance | S3I Cyber Solutions Division
☎ (256) 876-0326

CLASSIFICATION: UNCLASSIFIED
Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Kurt Seifried-2
+1. This is well written/thought out and something I've also seen happen in other ways in the Open Source world.

On Mon, Apr 30, 2018 at 8:51 AM, Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) <[hidden email]> wrote:
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

Dr. Jonathan Hood
Software Assurance | S3I Cyber Solutions Division
☎ (256) 876-0326

CLASSIFICATION: UNCLASSIFIED



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Altaz Valani
CWE team,

Thank you, Jonathan and Kurt, for initiating this discussion.

This issue is an important one. When I approach teams with this issue it is, unfortunately, seen as more of a compliance and legal issue rather than a security concern.

Is there a way we might explicitly tie this into security assurance for executives?

Thank you kindly,
Altaz

Director of Research
Security Compass

Sent: April 30, 2018 11:10 AM
Subject: Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

+1. This is well written/thought out and something I've also seen happen in other ways in the Open Source world.

On Mon, Apr 30, 2018 at 8:51 AM, Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) <[hidden email]> wrote:
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

Dr. Jonathan Hood
Software Assurance | S3I Cyber Solutions Division
☎ <a href="tel:(256)8760326">(256) 876-0326

CLASSIFICATION: UNCLASSIFIED



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Kurt Seifried
So one aspect of the AIC triad is availability. Licensing issues can result in software you relied upon not being available. I don't care of this is due to the attacker sending wonky packets, or a cease and desist letter, the end result is the same, a denial of service. 

Worse yet it could be actively exploited, e.g. a black hat gets a piece of copyrighted code, or even a piece of information that is deemed "illegal" (e.g. https://en.wikipedia.org/wiki/Illegal_prime) into the software and then later uses that fact to trigger license compliance/legal action that results in the software being unavailable suddenly. 

On Mon, Apr 30, 2018 at 10:44 AM, Altaz Valani <[hidden email]> wrote:
CWE team,

Thank you, Jonathan and Kurt, for initiating this discussion.

This issue is an important one. When I approach teams with this issue it is, unfortunately, seen as more of a compliance and legal issue rather than a security concern.

Is there a way we might explicitly tie this into security assurance for executives?

Thank you kindly,
Altaz

Director of Research
Security Compass

Sent: April 30, 2018 11:10 AM
Subject: Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

+1. This is well written/thought out and something I've also seen happen in other ways in the Open Source world.

On Mon, Apr 30, 2018 at 8:51 AM, Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) <[hidden email]> wrote:
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

Dr. Jonathan Hood
Software Assurance | S3I Cyber Solutions Division
☎ <a href="tel:(256)8760326" target="_blank">(256) 876-0326

CLASSIFICATION: UNCLASSIFIED



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].



--
Kurt Seifried
[hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Non-DoD Source] Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
In reply to this post by Altaz Valani
CLASSIFICATION: UNCLASSIFIED

I've found that tying it to "Availability" seems to get the best response from our clients. As availability is an overriding concern for most of our clients, it immediately gets put under the cybersecurity umbrella. Unfortunately, this type of issue generally gets escalated to a lawyer whose job it is to protect the financial interests of their employer rather than actually going in and fixing the mistake. Instead of, "Oh, we didn't pay you $200k/year for the past 10 years of using this software like we're supposed to? Here's the $2M you're owed." it usually ends up, "What's the best way to keep the IP holder from finding out about this?"

This also hits on the realm of supply-chain security; if you're not using software in a permitted and legal way, you're going to likely be having other issues in your supply chain that can have much more dangerous effects on a program. Injecting illegal software into the supply chain is often just as easy as injecting malicious and other pernicious software into the supply chain. Furthermore, having a dismissive attitude towards legal compliance in general is often a tell for how they treat even more dire software weaknesses.

Jon

Dr. Jonathan Hood
Software Assurance | S3I Cyber Solutions Division
☎ (256) 876-0326


-----Original Message-----
From: Altaz Valani [mailto:[hidden email]]
Sent: Monday, April 30, 2018 11:45 AM
To: Kurt Seifried <[hidden email]>; Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) <[hidden email]>
Cc: cwe-research-list CWE Research Discussion <[hidden email]>
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.


________________________________



CWE team,

Thank you, Jonathan and Kurt, for initiating this discussion.

This issue is an important one. When I approach teams with this issue it is, unfortunately, seen as more of a compliance and legal issue rather than a security concern.

Is there a way we might explicitly tie this into security assurance for executives?

Thank you kindly,
Altaz

Director of Research
Security Compass

From: [hidden email]
Sent: April 30, 2018 11:10 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

+1. This is well written/thought out and something I've also seen happen in other ways in the Open Source world.

On Mon, Apr 30, 2018 at 8:51 AM, Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) <[hidden email] < Caution-mailto:[hidden email] > > wrote:


        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
       
        Dr. Jonathan Hood
        Software Assurance | S3I Cyber Solutions Division
        ☎ (256) 876-0326 < tel:(256)8760326 >
       
        CLASSIFICATION: UNCLASSIFIED
       




--


Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact: [hidden email] < Caution-mailto:[hidden email] >

To unsubscribe, send an email message to [hidden email] < Caution-mailto:[hidden email] >  with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email] < Caution-mailto:[hidden email] > .
CLASSIFICATION: UNCLASSIFIED

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Jeffrey Walton
In reply to this post by Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
On Mon, Apr 30, 2018 at 10:51 AM, Hood, Jonathan W CTR USARMY RDECOM
AMRDEC (US) <[hidden email]> wrote:
> ...
>
> We've run into cases where a software license is being violated. ...

Related, the US Federal courts have upheld GPL as a valid legal
instrument. Also see
https://www.theregister.co.uk/2017/05/13/gnu_gpl_enforceable_contract/
.

Jeff

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

White, Gary L CIV SPAWARSYSCEN-ATLANTIC, 59330
I think of CWE as being used to enumerate weaknesses in software. Improper licensing is a weakness in policies and procedures, not the software ,unless the built-in licensing process is flawed or broken - and in that case it is the part of the software that is supposed to complete the licensing that would be a CWE candidate, not the improper licensing.



v/r

Gary L. White
MISSION ASSURANCE (5.9)
Cyber Forensics, Code 59330
Space and Naval Warfare Center, Atlantic
Phone: 843-218-5972; DSN: 588-5972
Cyber Forensics Data Recovery Lab: (843)218-4107
Cyber Forensics Lab: (843)218-3432
FAX 843-218-5461 (please notify before sending any FAX)
NIPRNET: [hidden email]<mailto:[hidden email]>
SIPRNET: [hidden email]<mailto:[hidden email]>
This e-mail, including any accompanying documents or attachments is intended only for the named recipient(s) and may contain information that is privacy sensitive. Any misuse or unauthorized disclosure of privacy sensitive information may result in civil and/or criminal penalties. The Privacy Act of 1974 (as amended) (5 U.S.C. 552a) and SECNAVINST 5211.5E apply. If you have received this message in error or are not the named recipient(s), please immediately notify the sender at (843) 218-5972 and delete this message from your computer.

STATEMENT of LIMITATION of AUTHORITY
I DO NOT have the authority to direct you in any way to alter your contractual obligation.  Further, if the Government, as a result of the information obtained in this email, DOES desire to alter your contract it will issue written changes signed by the contracting officer. Take no change actions without a signed contract modification.
________________________________
From: [hidden email] [[hidden email]] on behalf of Shawn Hernan [[hidden email]]
Sent: Monday, April 30, 2018 4:31 PM
To: [hidden email]; Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
Cc: cwe-research-list CWE Research Discussion
Subject: [Non-DoD Source] RE: Request for CWE: Improper Licensing (UNCLASSIFIED)

Software licensing definitely presents a risk, but I don't think CWE is intended to be a catch-all for all types of risk related to software.

M&A activities, government regulatory issues, changes triggered by GDPR, export/import control issues, etc., al present similar "availability" concerns. From the frontpage of the CWE website, "CWE™ is a community-developed list of common software security weaknesses." It's hard for me to see this as a security issue, despite the non-trivial and quite legitimate risk.

Thanks,
Shawn

Shawn Hernan, Principal Software Security Engineering Manager
Microsoft Azure Security Assurance
[hidden email]; @shawnhernan


> -----Original Message-----
> From: [hidden email] <owner-cwe-research-
> [hidden email]> On Behalf Of Jeffrey Walton
> Sent: Monday, April 30, 2018 10:57 AM
> To: Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
> <[hidden email]>
> Cc: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>
> Subject: Re: Request for CWE: Improper Licensing (UNCLASSIFIED)
>
> On Mon, Apr 30, 2018 at 10:51 AM, Hood, Jonathan W CTR USARMY RDECOM
> AMRDEC (US) <[hidden email]> wrote:
> > ...
> >
> > We've run into cases where a software license is being violated. ...
>
> Related, the US Federal courts have upheld GPL as a valid legal instrument. Also
> see
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.the
> register.co.uk%2F2017%2F05%2F13%2Fgnu_gpl_enforceable_contract%2F&da
> ta=02%7C01%7Cshernan%40MICROSOFT.COM%7Ce1cae86435de41b699a808
> d5aec3fab2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366070
> 79111237073&sdata=KXN8Jc5LEDh1INOxSU%2FOzDZMAT07Hf%2Bcy1cClp4ra
> Mo%3D&reserved=0
> .
>
> Jeff
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Joe Jarzombek
In reply to this post by Jeffrey Walton
This discussion is exemplary of why CQE should be part of CWE.  There are many instances in which a quality issue becomes a security issue.  Software that is not reliable is not secure, and software that is not secure is not reliable in today's environment of cyber exploitation.  At what point does a separation of quality from security matter other than whose job is it to fix it.  It seems some people would rather spend time arguing the nuances when in both instances the issue represents a technical debt that should be addressed.  Software quality and security issues are technical risks for which CWE can address the full scope.

As the sponsor for CWE we first focused on security because quality was supposedly being addressed (for the most part).  There is no reason CWE has to be solely about security issues.  Change the scope on the website to indicate "CWE™ is a community-developed list of common software weaknesses. It serves as a common language, a measuring stick for software security and quality tools, and as a baseline for weakness identification, mitigation, and prevention efforts."

Again, CQE should be a part of CWE to better enable the software community to address technical debt.

Regards,

   -Joe -

Joe Jarzombek, CSSLP 
Director for Government, Aerospace & Defense Programs
Email: [hidden email]  |  Mobile: 703 627-4644  |
https://www.synopsys.com/solutions/aerospace-defense.html



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Hernan
Sent: Monday, April 30, 2018 4:32 PM
To: [hidden email]; Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) <[hidden email]>
Cc: cwe-research-list CWE Research Discussion <[hidden email]>
Subject: RE: Request for CWE: Improper Licensing (UNCLASSIFIED)

Software licensing definitely presents a risk, but I don't think CWE is intended to be a catch-all for all types of risk related to software.

M&A activities, government regulatory issues, changes triggered by GDPR, export/import control issues, etc., al present similar "availability" concerns. From the frontpage of the CWE website, "CWE™ is a community-developed list of common software security weaknesses." It's hard for me to see this as a security issue, despite the non-trivial and quite legitimate risk.

Thanks,
Shawn

Shawn Hernan, Principal Software Security Engineering Manager Microsoft Azure Security Assurance [hidden email]; @shawnhernan


> -----Original Message-----
> From: [hidden email] <owner-cwe-research-
> [hidden email]> On Behalf Of Jeffrey Walton
> Sent: Monday, April 30, 2018 10:57 AM
> To: Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
> <[hidden email]>
> Cc: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>
> Subject: Re: Request for CWE: Improper Licensing (UNCLASSIFIED)
>
> On Mon, Apr 30, 2018 at 10:51 AM, Hood, Jonathan W CTR USARMY RDECOM
> AMRDEC (US) <[hidden email]> wrote:
> > ...
> >
> > We've run into cases where a software license is being violated. ...
>
> Related, the US Federal courts have upheld GPL as a valid legal
> instrument. Also see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.pr
> otection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.the&d=DwIGaQ&c=D
> PL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00&m=
> WL89CX7mWXTB0HmW_lVoe5EFvRgxNK3i8fXKcCFGTYQ&s=dOTzGWgDbmIgzQzcV7W7kvrv
> nXSyk-dSaN4fmRWB4-U&e=
> register.co.uk%2F2017%2F05%2F13%2Fgnu_gpl_enforceable_contract%2F&da
> ta=02%7C01%7Cshernan%40MICROSOFT.COM%7Ce1cae86435de41b699a808
> d5aec3fab2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366070
> 79111237073&sdata=KXN8Jc5LEDh1INOxSU%2FOzDZMAT07Hf%2Bcy1cClp4ra
> Mo%3D&reserved=0
> .
>
> Jeff
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].

Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

andrew murren
I concur with Joe’s proposal.  

There is the additional benefit that by including quality to the CWE it moves the CWE from being seen as a purely security, and hence niche, product to being broadly useful throughout the development process.  This difference is important when trying to convince the business units / management teams who are funding development to support the inclusion of quality and security in projects.  Generally quality isn’t always high on the list of activities to be funded and supported, and security is given even less support.  Including the CQE in the CWE will more accurately reflect reality and increase the possibility of it being more widely adopted as a standard part of development.  This can include adoption by software quality testing tools and as part of software development education.

Andy Murren, CISSP, CSSLP
Open Source Software Institute 


On Tue, May 1, 2018 at 08:12 Joe Jarzombek <[hidden email]> wrote:
This discussion is exemplary of why CQE should be part of CWE.  There are many instances in which a quality issue becomes a security issue.  Software that is not reliable is not secure, and software that is not secure is not reliable in today's environment of cyber exploitation.  At what point does a separation of quality from security matter other than whose job is it to fix it.  It seems some people would rather spend time arguing the nuances when in both instances the issue represents a technical debt that should be addressed.  Software quality and security issues are technical risks for which CWE can address the full scope.

As the sponsor for CWE we first focused on security because quality was supposedly being addressed (for the most part).  There is no reason CWE has to be solely about security issues.  Change the scope on the website to indicate "CWE™ is a community-developed list of common software weaknesses. It serves as a common language, a measuring stick for software security and quality tools, and as a baseline for weakness identification, mitigation, and prevention efforts."

Again, CQE should be a part of CWE to better enable the software community to address technical debt.

Regards,

   -Joe -

Joe Jarzombek, CSSLP 
Director for Government, Aerospace & Defense Programs
Email: [hidden email]  |  Mobile: 703 627-4644  |
https://www.synopsys.com/solutions/aerospace-defense.html



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Shawn Hernan
Sent: Monday, April 30, 2018 4:32 PM
To: [hidden email]; Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) <[hidden email]>
Cc: cwe-research-list CWE Research Discussion <[hidden email]>
Subject: RE: Request for CWE: Improper Licensing (UNCLASSIFIED)

Software licensing definitely presents a risk, but I don't think CWE is intended to be a catch-all for all types of risk related to software.

M&A activities, government regulatory issues, changes triggered by GDPR, export/import control issues, etc., al present similar "availability" concerns. From the frontpage of the CWE website, "CWE™ is a community-developed list of common software security weaknesses." It's hard for me to see this as a security issue, despite the non-trivial and quite legitimate risk.

Thanks,
Shawn

Shawn Hernan, Principal Software Security Engineering Manager Microsoft Azure Security Assurance [hidden email]; @shawnhernan


> -----Original Message-----
> From: [hidden email] <owner-cwe-research-
> [hidden email]> On Behalf Of Jeffrey Walton
> Sent: Monday, April 30, 2018 10:57 AM
> To: Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
> <[hidden email]>
> Cc: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>
> Subject: Re: Request for CWE: Improper Licensing (UNCLASSIFIED)
>
> On Mon, Apr 30, 2018 at 10:51 AM, Hood, Jonathan W CTR USARMY RDECOM
> AMRDEC (US) <[hidden email]> wrote:
> > ...
> >
> > We've run into cases where a software license is being violated. ...
>
> Related, the US Federal courts have upheld GPL as a valid legal
> instrument. Also see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.pr
> otection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.the&d=DwIGaQ&c=D
> PL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00&m=
> WL89CX7mWXTB0HmW_lVoe5EFvRgxNK3i8fXKcCFGTYQ&s=dOTzGWgDbmIgzQzcV7W7kvrv
> nXSyk-dSaN4fmRWB4-U&e=
> register.co.uk%2F2017%2F05%2F13%2Fgnu_gpl_enforceable_contract%2F&da
> ta=02%7C01%7Cshernan%40MICROSOFT.COM%7Ce1cae86435de41b699a808
> d5aec3fab2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366070
> 79111237073&sdata=KXN8Jc5LEDh1INOxSU%2FOzDZMAT07Hf%2Bcy1cClp4ra
> Mo%3D&reserved=0
> .
>
> Jeff
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Non-DoD Source] Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

White, Gary L CIV SPAWARSYSCEN-ATLANTIC, 59330
I agree that CQE and CWE are both important and that ultimately security cannot be achieved without addressing weaknesses embedded/inherent in software as well as weaknesses in hardware, policies, and procedures. I guess my initial objection was just one of semantics. I don't see licensing issues as being "software weakness", but it certainly is an important weakness. If you examine the NIST SP 800-53 controls, both software weaknesses and issues like licensing are addressed and software weaknesses are not given primacy over other types of weaknesses - you have to be concerned about all of them. I would support generalizing the lists to include all the issues addressed in NIST 800-53 (and any others that maybe SHOULD have been included in that NIST document).



v/r

Gary L. White
MISSION ASSURANCE (5.9)
Cyber Forensics, Code 59330
Space and Naval Warfare Center, Atlantic
Phone: 843-218-5972; DSN: 588-5972
Cyber Forensics Data Recovery Lab: (843)218-4107
Cyber Forensics Lab: (843)218-3432
FAX 843-218-5461 (please notify before sending any FAX)
NIPRNET: [hidden email]<mailto:[hidden email]>
SIPRNET: [hidden email]<mailto:[hidden email]>
This e-mail, including any accompanying documents or attachments is intended only for the named recipient(s) and may contain information that is privacy sensitive. Any misuse or unauthorized disclosure of privacy sensitive information may result in civil and/or criminal penalties. The Privacy Act of 1974 (as amended) (5 U.S.C. 552a) and SECNAVINST 5211.5E apply. If you have received this message in error or are not the named recipient(s), please immediately notify the sender at (843) 218-5972 and delete this message from your computer.

STATEMENT of LIMITATION of AUTHORITY
I DO NOT have the authority to direct you in any way to alter your contractual obligation.  Further, if the Government, as a result of the information obtained in this email, DOES desire to alter your contract it will issue written changes signed by the contracting officer. Take no change actions without a signed contract modification.
________________________________
From: [hidden email] [[hidden email]] on behalf of andrew murren [[hidden email]]
Sent: Tuesday, May 01, 2018 8:47 AM
To: Joe Jarzombek
Cc: Buttner, Drew; Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US); Shawn Hernan; cwe-research-list CWE Research Discussion; [hidden email]
Subject: [Non-DoD Source] Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

I concur with Joe’s proposal.

There is the additional benefit that by including quality to the CWE it moves the CWE from being seen as a purely security, and hence niche, product to being broadly useful throughout the development process.  This difference is important when trying to convince the business units / management teams who are funding development to support the inclusion of quality and security in projects.  Generally quality isn’t always high on the list of activities to be funded and supported, and security is given even less support.  Including the CQE in the CWE will more accurately reflect reality and increase the possibility of it being more widely adopted as a standard part of development.  This can include adoption by software quality testing tools and as part of software development education.

Andy Murren, CISSP, CSSLP
Open Source Software Institute
[hidden email]<mailto:[hidden email]>


On Tue, May 1, 2018 at 08:12 Joe Jarzombek <[hidden email]<mailto:[hidden email]>> wrote:
This discussion is exemplary of why CQE should be part of CWE.  There are many instances in which a quality issue becomes a security issue.  Software that is not reliable is not secure, and software that is not secure is not reliable in today's environment of cyber exploitation.  At what point does a separation of quality from security matter other than whose job is it to fix it.  It seems some people would rather spend time arguing the nuances when in both instances the issue represents a technical debt that should be addressed.  Software quality and security issues are technical risks for which CWE can address the full scope.

As the sponsor for CWE we first focused on security because quality was supposedly being addressed (for the most part).  There is no reason CWE has to be solely about security issues.  Change the scope on the website to indicate "CWE™ is a community-developed list of common software weaknesses. It serves as a common language, a measuring stick for software security and quality tools, and as a baseline for weakness identification, mitigation, and prevention efforts."

Again, CQE should be a part of CWE to better enable the software community to address technical debt.

Regards,

   -Joe -

Joe Jarzombek, CSSLP
Director for Government, Aerospace & Defense Programs
Email: [hidden email]<mailto:[hidden email]>  |  Mobile: 703 627-4644  |
https://www.synopsys.com/solutions/aerospace-defense.html



-----Original Message-----
From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]<mailto:[hidden email]>] On Behalf Of Shawn Hernan
Sent: Monday, April 30, 2018 4:32 PM
To: [hidden email]<mailto:[hidden email]>; Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US) <[hidden email]<mailto:[hidden email]>>
Cc: cwe-research-list CWE Research Discussion <[hidden email]<mailto:[hidden email]>>
Subject: RE: Request for CWE: Improper Licensing (UNCLASSIFIED)

Software licensing definitely presents a risk, but I don't think CWE is intended to be a catch-all for all types of risk related to software.

M&A activities, government regulatory issues, changes triggered by GDPR, export/import control issues, etc., al present similar "availability" concerns. From the frontpage of the CWE website, "CWE™ is a community-developed list of common software security weaknesses." It's hard for me to see this as a security issue, despite the non-trivial and quite legitimate risk.

Thanks,
Shawn

Shawn Hernan, Principal Software Security Engineering Manager Microsoft Azure Security Assurance [hidden email]<mailto:[hidden email]>; @shawnhernan


> -----Original Message-----
> From: [hidden email]<mailto:[hidden email]> <owner-cwe-research-
> [hidden email]<mailto:[hidden email]>> On Behalf Of Jeffrey Walton
> Sent: Monday, April 30, 2018 10:57 AM
> To: Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
> <[hidden email]<mailto:[hidden email]>>
> Cc: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]<mailto:[hidden email]>>
> Subject: Re: Request for CWE: Improper Licensing (UNCLASSIFIED)
>
> On Mon, Apr 30, 2018 at 10:51 AM, Hood, Jonathan W CTR USARMY RDECOM
> AMRDEC (US) <[hidden email]<mailto:[hidden email]>> wrote:
> > ...
> >
> > We've run into cases where a software license is being violated. ...
>
> Related, the US Federal courts have upheld GPL as a valid legal
> instrument. Also see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.pr
> otection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.the&d=DwIGaQ&c=D
> PL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00&m=
> WL89CX7mWXTB0HmW_lVoe5EFvRgxNK3i8fXKcCFGTYQ&s=dOTzGWgDbmIgzQzcV7W7kvrv
> nXSyk-dSaN4fmRWB4-U&e=
> register.co.uk<http://register.co.uk/>%2F2017%2F05%2F13%2Fgnu_gpl_enforceable_contract%2F&da
> ta=02%7C01%7Cshernan%40MICROSOFT.COM<http://40microsoft.com/>%7Ce1cae86435de41b699a808
> d5aec3fab2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366070
> 79111237073&sdata=KXN8Jc5LEDh1INOxSU%2FOzDZMAT07Hf%2Bcy1cClp4ra
> Mo%3D&reserved=0
> .
>
> Jeff
>
> To unsubscribe, send an email message to [hidden email]<mailto:[hidden email]> with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email]<mailto:[hidden email]>.

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

RE: Request for CWE: Improper Licensing (UNCLASSIFIED)

Andrew Buttner
Administrator
In reply to this post by Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]>
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

Dr. Jonathan Hood
Software Assurance | S3I Cyber Solutions Division ☎ (256) 876-0326

CLASSIFICATION: UNCLASSIFIED

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Kurt Seifried
So some new stuff has come to light recently:



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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]>
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

Dr. Jonathan Hood
Software Assurance | S3I Cyber Solutions Division ☎ (256) 876-0326

CLASSIFICATION: UNCLASSIFIED



--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Request for CWE: Improper Licensing (UNCLASSIFIED)

Wheeler, David A

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 [mailto:[hidden email]]
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:

 

 

 

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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]>
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

Dr. Jonathan Hood
Software Assurance | S3I Cyber Solutions Division (256) 876-0326

CLASSIFICATION: UNCLASSIFIED



 

--

Kurt Seifried
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Kurt Seifried
Could we agree on a generic top level "License issue or change causes problem" with a specific child right now of "License change to existing license prevents future updates and thus security updates of product"?

On Wed, Aug 22, 2018 at 10:35 AM, Wheeler, David A <[hidden email]> wrote:

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 [mailto:[hidden email]]
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:

 

 

 

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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]>
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

Dr. Jonathan Hood
Software Assurance | S3I Cyber Solutions Division (256) 876-0326

CLASSIFICATION: UNCLASSIFIED



 

--

Kurt Seifried
[hidden email]




--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Request for CWE: Improper Licensing (UNCLASSIFIED)

Wheeler, David A
> Could we agree on a generic top level "License issue or change causes problem" with a specific child right now of "License change to existing license prevents future updates and thus security updates of product"?

I think the top level could be just called "Licensing issue"; simple is good.

--- David A. Wheeler

Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Pascal Meunier
In reply to this post by Kurt Seifried
Isn't the root weakness that a (unilateral) change for the worse is possible, not that
it happened?  It seems to me that the cases cited are incidents made possible by a
pre-existing weakness.

On Wed, 2018-08-22 at 11:08 -0600, Kurt Seifried wrote:

> Could we agree on a generic top level "License issue or change causes
> problem" with a specific child right now of "License change to existing
> license prevents future updates and thus security updates of product"?
>
> On Wed, Aug 22, 2018 at 10:35 AM, Wheeler, David A <[hidden email]> wrote:
>
> > 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 [mailto:[hidden email]]
> > *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) https://redislabs.com/community/commons-clause/
> >
> >
> >
> > 2) 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 <[hidden email]> 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: [hidden email] [mailto:owner-cwe-research-
> > [hidden email]] 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-list@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
> >
> > Dr. Jonathan Hood
> > Software Assurance | S3I Cyber Solutions Division ☎ (256) 876-0326
> >
> > CLASSIFICATION: UNCLASSIFIED
> >
> >
> >
> >
> >
> > --
> >
> > Kurt Seifried
> > [hidden email]
> >
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Kurt Seifried
In the case of Redis it means not only an impact on whether or not you can upgrade, it means that moving forwards you have to pay for a license, or take on the additional cost and risk of maintaining a fork yourself, so a new risk has been created by the license change (either pay money to Redis, or pay money to your devs, or do neither and hope there's no new bad flaws).

On Wed, Aug 22, 2018 at 1:08 PM, Pascal Meunier <[hidden email]> wrote:
Isn't the root weakness that a (unilateral) change for the worse is possible, not that
it happened?  It seems to me that the cases cited are incidents made possible by a
pre-existing weakness.

On Wed, 2018-08-22 at 11:08 -0600, Kurt Seifried wrote:
> Could we agree on a generic top level "License issue or change causes
> problem" with a specific child right now of "License change to existing
> license prevents future updates and thus security updates of product"?
>
> On Wed, Aug 22, 2018 at 10:35 AM, Wheeler, David A <[hidden email]> wrote:
>
> > 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 [mailto:[hidden email]]
> > *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) https://redislabs.com/community/commons-clause/
> >
> >
> >
> > 2) 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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]
> > [hidden email]] 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-list@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
> >
> > Dr. Jonathan Hood
> > Software Assurance | S3I Cyber Solutions Division ☎ (256) 876-0326
> >
> > CLASSIFICATION: UNCLASSIFIED
> >
> >
> >
> >
> >
> > --
> >
> > Kurt Seifried
> > [hidden email]
> >
>
>
>



--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Pascal Meunier
So it is a licensing weakness that allows the replacement of licenses with binding
arbitrary licenses, with accompanying arbitrary risks and consequences.  In a way it
is similar to running arbitrary code...


On Wed, 2018-08-22 at 13:32 -0600, Kurt Seifried wrote:

> In the case of Redis it means not only an impact on whether or not you can
> upgrade, it means that moving forwards you have to pay for a license, or
> take on the additional cost and risk of maintaining a fork yourself, so a
> new risk has been created by the license change (either pay money to Redis,
> or pay money to your devs, or do neither and hope there's no new bad flaws).
>
> On Wed, Aug 22, 2018 at 1:08 PM, Pascal Meunier <[hidden email]>
> wrote:
>
> > Isn't the root weakness that a (unilateral) change for the worse is
> > possible, not that
> > it happened?  It seems to me that the cases cited are incidents made
> > possible by a
> > pre-existing weakness.
> >
> > On Wed, 2018-08-22 at 11:08 -0600, Kurt Seifried wrote:
> > > Could we agree on a generic top level "License issue or change causes
> > > problem" with a specific child right now of "License change to existing
> > > license prevents future updates and thus security updates of product"?
> > >
> > > On Wed, Aug 22, 2018 at 10:35 AM, Wheeler, David A <[hidden email]>
> >
> > wrote:
> > >
> > > > 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 [mailto:[hidden email]]
> > > > *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) https://redislabs.com/community/commons-clause/
> > > >
> > > >
> > > >
> > > > 2) 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 <[hidden email]>
> >
> > 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: [hidden email] [mailto:
> >
> > owner-cwe-research-
> > > > [hidden email]] 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-list@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
> > > >
> > > > Dr. Jonathan Hood
> > > > Software Assurance | S3I Cyber Solutions Division ☎ (256) 876-0326
> > > >
> > > > CLASSIFICATION: UNCLASSIFIED
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Kurt Seifried
> > > > [hidden email]
> > > >
> > >
> > >
> > >
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Request for CWE: Improper Licensing (UNCLASSIFIED)

Wheeler, David A
In reply to this post by Pascal Meunier
Pascal Meunier [mailto:[hidden email]]:
> Isn't the root weakness that a (unilateral) change for the worse is possible,
> not that it happened?  It seems to me that the cases cited are incidents made
> possible by a pre-existing weakness....
> So it is a licensing weakness that allows the replacement of licenses with binding arbitrary licenses,
> with accompanying arbitrary risks and consequences.  In a way it is similar to running arbitrary code...

Unilateral license changes in new versions of software are possible because of international copyright law. Under current law, when a single organization (such as a company) or a small number of people hold the copyright, OR when a permissive license is used (such as the MIT, BSD, or Apache license), it's possible to easily release a later version of the software that provides fewer rights to its users.

International law is NOT going to be changed to prevent this.  The only workable countermeasure I know of is to require that code be released using a copyleft license (like the GPL) and that it have a very large number of shared copyright owners (so that it's very difficult to remove license permissions).  The Linux kernel and git do this.  A riskier solution is to release copylefted code via a foundation that owns the copyrights and is expressly established to NOT significantly increase licensing requirements, e.g., the Free Software Foundation.  Those countermeasures do work, but I think it's clear that many organizations who develop software will NOT do this.

I do NOT think that the CWE team is willing to claim that all software is a security risk if it (1) comes from a single company (including practically all proprietary software) OR (2) is licensed with a permissive OSS license.  They certainly shouldn't be willing to that!  Assigning the CWE to international copyright law as a whole is intellectually accurate, and also 100% useless... it is NOT going to change.

So I think the CWE for "improper licensing" should be limited to cases where the *specific* situation is *actually* improper, not "if someone changed a license someday it could become improper".  That's consistent with the rest of the CWEs - any code could be changed to add a vulnerability of a particular class, but we don't assign CWEs just because some future event that MIGHT happen would cause a problem.  Once a software component *ACTUALLY* changes its license to reduce user permissions, then that *is* a real issue, because it's pretty common to automatically upgrade.

--- David A. Wheeler
Reply | Threaded
Open this post in threaded view
|

Re: Request for CWE: Improper Licensing (UNCLASSIFIED)

Pascal Meunier
On Wed, 2018-08-22 at 20:54 +0000, Wheeler, David A wrote:

> Pascal Meunier [mailto:[hidden email]]:
> > Isn't the root weakness that a (unilateral) change for the worse is possible,
> > not that it happened?  It seems to me that the cases cited are incidents made
> > possible by a pre-existing weakness....
> > So it is a licensing weakness that allows the replacement of licenses with binding
> > arbitrary licenses,
> > with accompanying arbitrary risks and consequences.  In a way it is similar to
> > running arbitrary code...
>
> Unilateral license changes in new versions of software are possible because of
> international copyright law. Under current law, when a single organization (such as
> a company) or a small number of people hold the copyright, OR when a permissive
> license is used (such as the MIT, BSD, or Apache license), it's possible to easily
> release a later version of the software that provides fewer rights to its users.
>
> International law is NOT going to be changed to prevent this.  The only workable
> countermeasure I know of is to require that code be released using a copyleft
> license (like the GPL) and that it have a very large number of shared copyright
> owners (so that it's very difficult to remove license permissions).  The Linux
> kernel and git do this.  A riskier solution is to release copylefted code via a
> foundation that owns the copyrights and is expressly established to NOT
> significantly increase licensing requirements, e.g., the Free Software
> Foundation.  Those countermeasures do work, but I think it's clear that many
> organizations who develop software will NOT do this.
>
> I do NOT think that the CWE team is willing to claim that all software is a security
> risk if it (1) comes from a single company (including practically all proprietary
> software) OR (2) is licensed with a permissive OSS license.  They certainly
> shouldn't be willing to that!  Assigning the CWE to international copyright law as a
> whole is intellectually accurate, and also 100% useless... it is NOT going to
> change.

Thank you, that's very helpful, sensible and logical, and I have to agree.

>
> So I think the CWE for "improper licensing" should be limited to cases where the
> *specific* situation is *actually* improper, not "if someone changed a license
> someday it could become improper".  That's consistent with the rest of the CWEs -
> any code could be changed to add a vulnerability of a particular class, but we don't
> assign CWEs just because some future event that MIGHT happen would cause a
> problem.  Once a software component *ACTUALLY* changes its license to reduce user
> permissions, then that *is* a real issue, because it's pretty common to
> automatically upgrade.

I don't see the logic in creating CWEs for change events themselves, it's dissonant.
Something is an instance of a CWE due to its current state, regardless of how it got
there, and regardless of the passage of time as long as the state doesn't change.  I
think you couldn't answer yes/no as to whether a product itself (a specific version
with its license) is an instance of a "change CWE", you'd need differences between
versions of a product, and that's where the dissonance comes from.  

I'm of the opinion that people should be free to agree *up-front* (when components are
first brought in) to pretty restrictive or unfavorable licenses.  I don't see CWEs as
appropriate for describing how licenses can be "bad", because a "bad" license can be
OK if it is agreed upon knowingly up-front.  As you said earlier, the unexpected
change putting people in a bind is the problem.  However, using CWEs to describe
change events makes no sense to me.  Given all this, I'm now leaning towards licensing
issues being out of scope or a bad fit for the CWE.

Regards,
Pascal


12