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

[Steven M Christey]

If a license has a clause that requires insecure behavior, then the behavior 
itself can still be classified using an existing CWE.

Informally, from a CWE perspective, it doesn’t matter  forced the 
insecure behavior to enter the product, or what phase of the SDLC 
(requirements, design, implementation error, configuration error, etc.) – 
ideally, CWE characterizes the insecure behavior itself. This notion does get 
extended to certain properties of code that can contribute to security issues 
(CWE-1121: Excessive McCabe Cyclomatic Complexity), so to me, a broader 
question is whether “having a risky license” fits as an “undesired property of 
behavior” or if it’s something else.

One other note – we are tracking several proposals about expanding CWE scope 
that need to be discussed by the entire CWE community sometime in the future, 
and this active debate about licenses is another scope discussion, which might 
fit under “human processes that exist outside of the product itself.”

- Steve


From: Kurt Seifried 
Sent: Thursday, November 9, 2023 3:30 PM
To: Roguski, Przemyslaw 
Cc: jonathan.w.hood6@army.mil; Hatfield, Arthur 
; CWE Research Discussion 

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

What if a license has a clause that requires an insecure or problematic 
setting/configuration/behavior? Someone did a parody licence called the " 
Insecure License" but I wouldn't put it past sometime to have done this for 
real. 

What if a license has a clause that requires an insecure or problematic 
setting/configuration/behavior? Someone did a parody licence called the " 
Insecure License" but I wouldn't put it past sometime to have done this for 
real. What about audit clauses (e.g. can I audit the NSA usage of my product) 
and other forms of information disclosure?

On Thu, Nov 9, 2023 at 11:46 AM Przemyslaw Roguski 
mailto:progu...@redhat.com>> wrote:
Hi Jon, Thank you for accepting different opinions and I'm really happy that we 
have this discussion here. To be honest I never consider licensing issues as a 
potential problem that could be considered as a software weakness. But it seems

Hi Jon,

Thank you for accepting different opinions and I'm really happy that we have 
this discussion here.
To be honest I never consider licensing issues as a potential problem that 
could be considered as a software weakness.
But it seems that such a clarification is required.
Let me repeat what I said before, regardless of the declared licence (valid or 
not) still you can be impacted if you run a malicious software/code.
Like in Arthur's example.
Thank you Arthur for your great examples!

Jon, let me try to provide one more clarification. If your license management 
software will accept invalid licence and recognize it as a valid one, then yes, 
it's a licence related weakness, but it's a weakness in your software, not a 
problem with the wrong license itself that was provided. Depending on the root 
cause in such a case it could be "CWE-184: Incomplete List of Disallowed 
Inputs" weakness related to the license management software. You can blame the 
invalid license, but in fact the root cause and the weakness is in the license 
management software.

Like it was said a few times, licence by itself, regardless if valid or not, 
cannot lead to vulnerability, hence cannot be classified as a weakness as well.
Invalid licence can lead to legal problems, but this is a different story.

I hope it helps.

Best regards,
Przemek


Przemyslaw Roguski

Security Architect, Product Security

Red Hat Poland<https://www.redhat.com/>

progu...@redhat.com<mailto:progu...@redhat.com>IM: rogue
<https://red.ht/sig>
 <https://red.ht/sig>
On Thu, Nov 9, 2023 at 6:49 PM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
 wrote:<https://red.ht/sig>
I understand the position better with this analogy; thank 
you.<https://red.ht/sig>
 <https://red.ht/sig>
I do believe that it is not a comparable analogy. Raising energy prices are not 
a property of the software. A software license is a property of the software, 
so the argument you make here is based off of an initial assertion that seems 
incorrect. Just because the fix for the weakness is voluntary doesn’t mean it’s 
not a weakness (IE: voluntarily stop using untrusted components, CWE-1357), 
though license enforcement may not be voluntary in all 
cases.<https://red.ht/sig>
 <https://red.ht/sig>
“It doesn’t do anything to stop the execution of that software on any system 
not under your direct control where it’s already running” – I’m arguing that it 
does. When you incorporate software in violation of the license, you expose 
your product to injunction or restraint which absolutely can apply to the 
executing software directly under your control. For example, if the Home Depot 
website used software without licensing it, the software 

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

[Kurt Seifried]

se adherence with license management software or request that your
>> users adhere to it voluntarily, it’s still an availability vulnerability
>> that should also have a CWE to categorize it.
>>
>>
>>
>> Thank you for helping me understand the position better. I do not think I
>> agree with it, but do understand the position better than I did before.
>>
>>
>>
>> Jon
>>
>>
>>
>> *From:* Hatfield, Arthur 
>> *Sent:* Thursday, November 9, 2023 9:54 AM
>> *To:* Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) <
>> jonathan.w.hood6@army.mil>; Przemyslaw Roguski ;
>> Steven M Christey 
>> *Cc:* CWE Research Discussion 
>> *Subject:* Re: [Non-DoD Source] Re: Request for CWE: Improper Licensing
>> (UNCLASSIFIED)
>>
>>
>>
>> You don't often get email from arthur_hatfi...@homedepot.com. Learn why
>> this is important <https://aka.ms/LearnAboutSenderIdentification>
>>
>> Look at it this way:
>>
>>
>>
>> Licensing issues are not a property of software, but of the society and
>> economy around the software.
>>
>>
>>
>> A buffer overflow in a driver will crash your computer and make it
>> unavailable any time data passes through it in a particular way, no matter
>> who is causing that data to go through that buffer or why. A GPL-violation
>> lawsuit will only stop you from distributing software if you voluntarily
>> settle or you lose the lawsuit, and even then that’s basically going to
>> require voluntary action on your part to stop using and/or distributing the
>> software. It doesn’t do anything to stop the execution of that software on
>> any system not under your direct control where it’s already running.
>> Availability of the software in this case is not affected by a “coding
>> weakness,” but by your organizational response to social, legal, and
>> economic pressure.
>>
>>
>>
>> If we put license issues in CWE, then we might as well put rising energy
>> costs in CWE. A surprise jump in your power bill could affect the
>> availability of your application if you respond to the bill by voluntarily
>> turning off your computer.
>>
>>
>>
>>
>>
>> *RT Hatfield* *|* *Staff Cybersecurity Analyst **|* *BS CS, CCITP, CISSP*
>>
>> *The Home Depot | **Cyber Threat Intelligence*
>>
>> * arthur_hatfi...@homedepot.com
>>
>> * c...@homedepot.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> INTERNAL USE
>>
>> *From: *Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) <
>> jonathan.w.hood6@army.mil>
>> *Date: *Thursday, November 9, 2023 at 10:26 AM
>> *To: *Przemyslaw Roguski , Steven M Christey <
>> co...@mitre.org>
>> *Cc: *CWE Research Discussion 
>> *Subject: *[EXTERNAL] [EXT] RE: [Non-DoD Source] Re: Request for CWE:
>> Improper Licensing (UNCLASSIFIED)
>>
>> I respectfully disagree with this. Using a license incorrectly causes an
>> availability issue directly, and availability is one of the cybersecurity
>> principles that represent weaknesses and vulnerabilities by the definitions
>> I am aware of.
>>
>>
>>
>> Can you please help me understand what definition CWE is using for each?
>> The nearest definitions I can find are: “A ‘weakness’ is a condition in a
>> software, firmware, hardware, or service component that, under certain
>> circumstances, could contribute to the introduction of vulnerabilities” (
>> https://cwe.mitre.org/about/new_to_cwe.html). Following the
>> vulnerability theory (
>> https://cwe.mitre.org/documents/vulnerability_theory/intro.html)
>> suggests that we need to have a PRODUCT implementing FEATURE by performing
>> certain BEHAVIORS that operate on RESOURCES. I will assume these
>> definitions in my disagreement below, and acknowledge that my basic
>> definitions of some of these terms may be off.
>>
>>
>>
>> The core question is therefore: is a license violation a vulnerability by
>> the vulnerability theory used by the CWEs? I argue in the affirmative. You
>> state, “No doubt that invalid licenses are a serious problem from the
>> security perspective, but it's more a supply chain issue and legal
>> problem.” Then a PRODUCT implementing software with a “supply chain issue”
>> or “legal problem” to achieve its behavior on its resources produces an
>> availability security impact against PRODUCT. If you want to identify it
>> more generally as “supply chain issue” or “legal insuffici

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

[Hatfield, Arthur]

I think the main distinction that I want to be observed is that the CWEs are 
about vulnerabilities that are intrinsic to a piece of software (firmware, 
hardware) due to defects in its design or implementation, leading to unwanted 
behavior of the software (firmware, hardware) itself. Licensing issues involve 
a business process vulnerability due to defects in organizational practices 
around the software (e.g. not paying bills, or not respecting copyright law) 
leading to sticky business situations that can make continuing to rely on a 
given software component odious to the organization’s decision-makers.

RT Hatfield | Staff Cybersecurity Analyst | BS CS, CCITP, CISSP
The Home Depot | Cyber Threat Intelligence
• arthur_hatfi...@homedepot.com<mailto:arthur_hatfi...@homedepot.com>
• c...@homedepot.com<mailto:c...@homedepot.com>





INTERNAL USE
From: Przemyslaw Roguski 
Date: Thursday, November 9, 2023 at 1:45 PM
To: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 

Cc: Hatfield, Arthur , CWE Research Discussion 

Subject: [EXTERNAL] Re: [EXT] RE: [Non-DoD Source] Re: Request for CWE: 
Improper Licensing (UNCLASSIFIED)
Hi Jon, Thank you for accepting different opinions and I'm really happy that we 
have this discussion here. To be honest I never consider licensing issues as a 
potential problem that could be considered as a software weakness. But it seems

Hi Jon,

Thank you for accepting different opinions and I'm really happy that we have 
this discussion here.
To be honest I never consider licensing issues as a potential problem that 
could be considered as a software weakness.
But it seems that such a clarification is required.
Let me repeat what I said before, regardless of the declared licence (valid or 
not) still you can be impacted if you run a malicious software/code.
Like in Arthur's example.
Thank you Arthur for your great examples!

Jon, let me try to provide one more clarification. If your license management 
software will accept invalid licence and recognize it as a valid one, then yes, 
it's a licence related weakness, but it's a weakness in your software, not a 
problem with the wrong license itself that was provided. Depending on the root 
cause in such a case it could be "CWE-184: Incomplete List of Disallowed 
Inputs" weakness related to the license management software. You can blame the 
invalid license, but in fact the root cause and the weakness is in the license 
management software.

Like it was said a few times, licence by itself, regardless if valid or not, 
cannot lead to vulnerability, hence cannot be classified as a weakness as well.
Invalid licence can lead to legal problems, but this is a different story.

I hope it helps.

Best regards,
Przemek


Przemyslaw Roguski

Security Architect, Product Security

Red Hat Poland 
[redhat.com]<https://urldefense.com/v3/__https:/www.redhat.com/__;!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g6DOl5e6w$>

progu...@redhat.com<mailto:progu...@redhat.com>IM: rogue
[Image removed by 
sender.][red.ht]<https://urldefense.com/v3/__https:/red.ht/sig__;!!M-nmYVHPHQ!IT_WQ6o4kOATVHOVzPwf7E_vHmtTOGWTno9gvKZW9p-B4E3liOnptTlKyzWvlRvkXiqu5T8sRizeClxJ9g5eCEVQgQ$>

On Thu, Nov 9, 2023 at 6:49 PM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
mailto:jonathan.w.hood6@army.mil>> wrote:
I understand the position better with this analogy; thank you.

I do believe that it is not a comparable analogy. Raising energy prices are not 
a property of the software. A software license is a property of the software, 
so the argument you make here is based off of an initial assertion that seems 
incorrect. Just because the fix for the weakness is voluntary doesn’t mean it’s 
not a weakness (IE: voluntarily stop using untrusted components, CWE-1357), 
though license enforcement may not be voluntary in all cases.

“It doesn’t do anything to stop the execution of that software on any system 
not under your direct control where it’s already running” – I’m arguing that it 
does. When you incorporate software in violation of the license, you expose 
your product to injunction or restraint which absolutely can apply to the 
executing software directly under your control. For example, if the Home Depot 
website used software without licensing it, the software may have a license 
enforcement mechanism (and would have the legal authority to) shut off the 
software once the license becomes unverified, or Home Depot may receive an 
injunction to stop using the unlicensed software. Either of these scenarios 
would directly affect the availability of the Home Depot website and are 
reflected by an underlying coding weakness of relying on or incorporating 
improperly licensed components. Home Depot would not have a choice or voluntary 
decision in such a case, and even if it did, it's still a quantifiable threat 
to the software.

“If we put license issues in CWE, then we might as 

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

[Przemyslaw Roguski]

Hi Jon,

Thank you for accepting different opinions and I'm really happy that we
have this discussion here.
To be honest I never consider licensing issues as a potential problem that
could be considered as a software weakness.
But it seems that such a clarification is required.
Let me repeat what I said before, regardless of the declared licence (valid
or not) still you can be impacted if you run a malicious software/code.
Like in Arthur's example.

Thank you Arthur for your great examples!

Jon, let me try to provide one more clarification. If your license
management software will accept invalid licence and recognize it as a
valid one, then yes, it's a licence related weakness, but it's a weakness
in your software, not a problem with the wrong license itself that was
provided. Depending on the root cause in such a case it could be "CWE-184:
Incomplete List of Disallowed Inputs" weakness related to the license
management software. You can blame the invalid license, but in fact the
root cause and the weakness is in the license management software.

Like it was said a few times, licence by itself, regardless if valid or
not, cannot lead to vulnerability, hence cannot be classified as a weakness
as well.
Invalid licence can lead to legal problems, but this is a different story.

I hope it helps.

Best regards,
Przemek

Przemyslaw Roguski

Security Architect, Product Security

Red Hat Poland <https://www.redhat.com/>

progu...@redhat.comIM: rogue

<https://red.ht/sig>

On Thu, Nov 9, 2023 at 6:49 PM Hood, Jonathan W CTR USARMY DEVCOM AVMC
(USA)  wrote:

> I understand the position better with this analogy; thank you.
>
>
>
> I do believe that it is not a comparable analogy. Raising energy prices
> are not a property of the software. A software license is a property of the
> software, so the argument you make here is based off of an initial
> assertion that seems incorrect. Just because the fix for the weakness is
> voluntary doesn’t mean it’s not a weakness (IE: voluntarily stop using
> untrusted components, CWE-1357), though license enforcement may not be
> voluntary in all cases.
>
>
>
> “It doesn’t do anything to stop the execution of that software on any
> system not under your direct control where it’s already running” – I’m
> arguing that it does. When you incorporate software in violation of the
> license, you expose your product to injunction or restraint which
> absolutely can apply to the executing software directly under your control.
> For example, if the Home Depot website used software without licensing it,
> the software may have a license enforcement mechanism (and would have the
> legal authority to) shut off the software once the license becomes
> unverified, or Home Depot may receive an injunction to stop using the
> unlicensed software. Either of these scenarios would directly affect the
> availability of the Home Depot website and are reflected by an underlying
> coding weakness of relying on or incorporating improperly licensed
> components. Home Depot would not have a choice or voluntary decision in
> such a case, and even if it did, it's still a quantifiable threat to the
> software.
>
>
>
> “If we put license issues in CWE, then we might as well put rising energy
> costs in CWE.” Whether the energy is cut off through physical means
> (battery overload) or you can find a repeatable way to intentionally get a
> reliable power source shut off because the user can’t pay the power bill,
> it’s still a valid CWE-920 in my opinion. Likewise, whether you force
> license adherence with license management software or request that your
> users adhere to it voluntarily, it’s still an availability vulnerability
> that should also have a CWE to categorize it.
>
>
>
> Thank you for helping me understand the position better. I do not think I
> agree with it, but do understand the position better than I did before.
>
>
>
> Jon
>
>
>
> *From:* Hatfield, Arthur 
> *Sent:* Thursday, November 9, 2023 9:54 AM
> *To:* Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) <
> jonathan.w.hood6@army.mil>; Przemyslaw Roguski ;
> Steven M Christey 
> *Cc:* CWE Research Discussion 
> *Subject:* Re: [Non-DoD Source] Re: Request for CWE: Improper Licensing
> (UNCLASSIFIED)
>
>
>
> You don't often get email from arthur_hatfi...@homedepot.com. Learn why
> this is important <https://aka.ms/LearnAboutSenderIdentification>
>
> Look at it this way:
>
>
>
> Licensing issues are not a property of software, but of the society and
> economy around the software.
>
>
>
> A buffer overflow in a driver will crash your computer and make it
> unavailable any time data passes through it in a particular way, no matter
> who is causing that data to go through that 

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

[Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA)]

I understand the position better with this analogy; thank you.

 

I do believe that it is not a comparable analogy. Raising energy prices are not 
a property of the software. A software license is a property of the software, 
so the argument you make here is based off of an initial assertion that seems 
incorrect. Just because the fix for the weakness is voluntary doesn’t mean it’s 
not a weakness (IE: voluntarily stop using untrusted components, CWE-1357), 
though license enforcement may not be voluntary in all cases.

 

“It doesn’t do anything to stop the execution of that software on any system 
not under your direct control where it’s already running” – I’m arguing that it 
does. When you incorporate software in violation of the license, you expose 
your product to injunction or restraint which absolutely can apply to the 
executing software directly under your control. For example, if the Home Depot 
website used software without licensing it, the software may have a license 
enforcement mechanism (and would have the legal authority to) shut off the 
software once the license becomes unverified, or Home Depot may receive an 
injunction to stop using the unlicensed software. Either of these scenarios 
would directly affect the availability of the Home Depot website and are 
reflected by an underlying coding weakness of relying on or incorporating 
improperly licensed components. Home Depot would not have a choice or voluntary 
decision in such a case, and even if it did, it's still a quantifiable threat 
to the software.

 

“If we put license issues in CWE, then we might as well put rising energy costs 
in CWE.” Whether the energy is cut off through physical means (battery 
overload) or you can find a repeatable way to intentionally get a reliable 
power source shut off because the user can’t pay the power bill, it’s still a 
valid CWE-920 in my opinion. Likewise, whether you force license adherence with 
license management software or request that your users adhere to it 
voluntarily, it’s still an availability vulnerability that should also have a 
CWE to categorize it.

 

Thank you for helping me understand the position better. I do not think I agree 
with it, but do understand the position better than I did before.

 

Jon

 

From: Hatfield, Arthur  
Sent: Thursday, November 9, 2023 9:54 AM
To: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
; Przemyslaw Roguski ; 
Steven M Christey 
Cc: CWE Research Discussion 
Subject: Re: [Non-DoD Source] Re: Request for CWE: Improper Licensing 
(UNCLASSIFIED)

 


You don't often get email from arthur_hatfi...@homedepot.com 
<mailto:arthur_hatfi...@homedepot.com> . Learn why this is important 
<https://aka.ms/LearnAboutSenderIdentification> 



Look at it this way:

 

Licensing issues are not a property of software, but of the society and economy 
around the software. 

 

A buffer overflow in a driver will crash your computer and make it unavailable 
any time data passes through it in a particular way, no matter who is causing 
that data to go through that buffer or why. A GPL-violation lawsuit will only 
stop you from distributing software if you voluntarily settle or you lose the 
lawsuit, and even then that’s basically going to require voluntary action on 
your part to stop using and/or distributing the software. It doesn’t do 
anything to stop the execution of that software on any system not under your 
direct control where it’s already running. Availability of the software in this 
case is not affected by a “coding weakness,” but by your organizational 
response to social, legal, and economic pressure.

 

If we put license issues in CWE, then we might as well put rising energy costs 
in CWE. A surprise jump in your power bill could affect the availability of 
your application if you respond to the bill by voluntarily turning off your 
computer.

 

 

RT Hatfield | Staff Cybersecurity Analyst | BS CS, CCITP, CISSP

The Home Depot | Cyber Threat Intelligence

*  <mailto:arthur_hatfi...@homedepot.com> arthur_hatfi...@homedepot.com

*  <mailto:c...@homedepot.com> c...@homedepot.com

 

 

 

 

 

INTERNAL USE

From: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
mailto:jonathan.w.hood6@army.mil> >
Date: Thursday, November 9, 2023 at 10:26 AM
To: Przemyslaw Roguski mailto:progu...@redhat.com> >, 
Steven M Christey mailto:co...@mitre.org> >
Cc: CWE Research Discussion mailto:cwe-research-list@mitre.org> >
Subject: [EXTERNAL] [EXT] RE: [Non-DoD Source] Re: Request for CWE: Improper 
Licensing (UNCLASSIFIED)

I respectfully disagree with this. Using a license incorrectly causes an 
availability issue directly, and availability is one of the cybersecurity 
principles that represent weaknesses and vulnerabilities by the definitions I 
am aware of.

 

Can you please help me understand what definition CWE is using for each? The 
nearest definitions I can find are: “A ‘weakness’ i

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

[Hatfield, Arthur]

Look at it this way:

Licensing issues are not a property of software, but of the society and economy 
around the software.

A buffer overflow in a driver will crash your computer and make it unavailable 
any time data passes through it in a particular way, no matter who is causing 
that data to go through that buffer or why. A GPL-violation lawsuit will only 
stop you from distributing software if you voluntarily settle or you lose the 
lawsuit, and even then that’s basically going to require voluntary action on 
your part to stop using and/or distributing the software. It doesn’t do 
anything to stop the execution of that software on any system not under your 
direct control where it’s already running. Availability of the software in this 
case is not affected by a “coding weakness,” but by your organizational 
response to social, legal, and economic pressure.

If we put license issues in CWE, then we might as well put rising energy costs 
in CWE. A surprise jump in your power bill could affect the availability of 
your application if you respond to the bill by voluntarily turning off your 
computer.


RT Hatfield | Staff Cybersecurity Analyst | BS CS, CCITP, CISSP
The Home Depot | Cyber Threat Intelligence
• arthur_hatfi...@homedepot.com<mailto:arthur_hatfi...@homedepot.com>
• c...@homedepot.com<mailto:c...@homedepot.com>






INTERNAL USE
From: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 

Date: Thursday, November 9, 2023 at 10:26 AM
To: Przemyslaw Roguski , Steven M Christey 

Cc: CWE Research Discussion 
Subject: [EXTERNAL] [EXT] RE: [Non-DoD Source] Re: Request for CWE: Improper 
Licensing (UNCLASSIFIED)
I respectfully disagree with this. Using a license incorrectly causes an 
availability issue directly, and availability is one of the cybersecurity 
principles that represent weaknesses and vulnerabilities by the definitions I 
am aware of.

Can you please help me understand what definition CWE is using for each? The 
nearest definitions I can find are: “A ‘weakness’ is a condition in a software, 
firmware, hardware, or service component that, under certain circumstances, 
could contribute to the introduction of vulnerabilities” 
(https://cwe.mitre.org/about/new_to_cwe.html). Following the vulnerability 
theory (https://cwe.mitre.org/documents/vulnerability_theory/intro.html) 
suggests that we need to have a PRODUCT implementing FEATURE by performing 
certain BEHAVIORS that operate on RESOURCES. I will assume these definitions in 
my disagreement below, and acknowledge that my basic definitions of some of 
these terms may be off.

The core question is therefore: is a license violation a vulnerability by the 
vulnerability theory used by the CWEs? I argue in the affirmative. You state, 
“No doubt that invalid licenses are a serious problem from the security 
perspective, but it's more a supply chain issue and legal problem.” Then a 
PRODUCT implementing software with a “supply chain issue” or “legal problem” to 
achieve its behavior on its resources produces an availability security impact 
against PRODUCT. If you want to identify it more generally as “supply chain 
issue” or “legal insufficiency,” it’s still a vulnerability that directly 
affects availability, incurs technical debt, and inflicts reputation/brand 
damage (https://cwe.mitre.org/cwraf/creatingyourownvignettes.html). I believe 
that more specific supply chain or legal issues are appropriate as well (and 
license violations would be a specific example), but these two general classes 
of vulnerabilities you’ve identified also meet the criteria for becoming a CWE. 
CWE-1357 almost meets some of this definition as well. Instead of a 
license-violating component being “not sufficiently trusted to meet 
expectations for security” (with availability being part of the security 
definition), it would be nice to have a CWE that can refer to a component 
(trusted or not) that in fact does not meet security expectations because of 
“supply chain” or “legal” vulnerabilities.

Can you please further explain why a “supply chain issue and legal problem” is 
an abuse of the weakness definition? I feel like you acknowledge it’s a 
weakness while also saying it’s an abuse of the definition of a weakness, which 
indicates that I’m not understanding some of your argument. You lose me at 
“Invalid license itself cannot lead to a vulnerability just like that.” How is 
a coding weakness that affects availability not a distinct, individual 
vulnerability, regardless of what other vulnerabilities may also be in the 
software?

Sincere thanks for your response and interaction,
Jon

From: Przemyslaw Roguski 
Sent: Sunday, November 5, 2023 1:21 PM
To: Steven M Christey 
Cc: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
; CWE Research Discussion 

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

You don't often get email from progu...@redhat.com. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentif

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

[Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA)]

I respectfully disagree with this. Using a license incorrectly causes an 
availability issue directly, and availability is one of the cybersecurity 
principles that represent weaknesses and vulnerabilities by the definitions I 
am aware of.

 

Can you please help me understand what definition CWE is using for each? The 
nearest definitions I can find are: “A ‘weakness’ is a condition in a software, 
firmware, hardware, or service component that, under certain circumstances, 
could contribute to the introduction of vulnerabilities” 
(https://cwe.mitre.org/about/new_to_cwe.html). Following the vulnerability 
theory (https://cwe.mitre.org/documents/vulnerability_theory/intro.html) 
suggests that we need to have a PRODUCT implementing FEATURE by performing 
certain BEHAVIORS that operate on RESOURCES. I will assume these definitions in 
my disagreement below, and acknowledge that my basic definitions of some of 
these terms may be off.

 

The core question is therefore: is a license violation a vulnerability by the 
vulnerability theory used by the CWEs? I argue in the affirmative. You state, 
“No doubt that invalid licenses are a serious problem from the security 
perspective, but it's more a supply chain issue and legal problem.” Then a 
PRODUCT implementing software with a “supply chain issue” or “legal problem” to 
achieve its behavior on its resources produces an availability security impact 
against PRODUCT. If you want to identify it more generally as “supply chain 
issue” or “legal insufficiency,” it’s still a vulnerability that directly 
affects availability, incurs technical debt, and inflicts reputation/brand 
damage (https://cwe.mitre.org/cwraf/creatingyourownvignettes.html). I believe 
that more specific supply chain or legal issues are appropriate as well (and 
license violations would be a specific example), but these two general classes 
of vulnerabilities you’ve identified also meet the criteria for becoming a CWE. 
CWE-1357 almost meets some of this definition as well. Instead of a 
license-violating component being “not sufficiently trusted to meet 
expectations for security” (with availability being part of the security 
definition), it would be nice to have a CWE that can refer to a component 
(trusted or not) that in fact does not meet security expectations because of 
“supply chain” or “legal” vulnerabilities.

 

Can you please further explain why a “supply chain issue and legal problem” is 
an abuse of the weakness definition? I feel like you acknowledge it’s a 
weakness while also saying it’s an abuse of the definition of a weakness, which 
indicates that I’m not understanding some of your argument. You lose me at 
“Invalid license itself cannot lead to a vulnerability just like that.” How is 
a coding weakness that affects availability not a distinct, individual 
vulnerability, regardless of what other vulnerabilities may also be in the 
software?

 

Sincere thanks for your response and interaction,

Jon

 

From: Przemyslaw Roguski  
Sent: Sunday, November 5, 2023 1:21 PM
To: Steven M Christey 
Cc: Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
; CWE Research Discussion 

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

 


You don't often get email from progu...@redhat.com.  
<https://aka.ms/LearnAboutSenderIdentification> Learn why this is important



Hi All, 

 

In my personal opinion, adding new weakness or renaming existing one to 
something more "licensing" related is abuse of the weakness definition.

We defined the weakness and vulnerability definitions a long time ago and any 
licensing problems do not fit the weakness use case.

 

The real-world examples provided in this thread indicate that there were 
license problems, but it's only a side effect of the problem.

Let me explain it in a different way. If you use a component or 3rd party 
software where it is a good, correct licence, but that component is not 
maintained correctly or has some vulnerabilities that some day lead to an 
exploit and successful attack, then it doesn't matter that there was a correct 
licence. 
No doubt that invalid licenses are a serious problem from the security 
perspective, but it's more a supply chain issue and legal problem.

Invalid licence itself cannot lead to a vulnerability just like that. There 
must be another weakness that can lead to a vulnerability.

Licences should be registered and monitored similarly to the components 
(artifacts) provenance, which is in scope of SBOMs.

Hence adding a new weakness licensing related is not a good idea in my opinion.

 

Best regards,

Przemek

 

Przemyslaw Roguski

Security Architect, Product Security

 
<https://usg01.safelinks.protection.office365.us/?url=https%3A%2F%2Fwww.redhat.com%2F=05%7C01%7Cjonathan.w.hood6.ctr%40army.mil%7C1a2d92e6c02046c05f8b08dbde347182%7Cfae6d70f954b481192b60530d6f84c43%7C0%7C0%7C638348089

RE: [Non-DoD Source] Is there a CWE for this?

[Steven M Christey]

Rob,

I believe it makes sense to update CWE-436 based on your suggestion. An 
immediate question is whether the clarification belongs in the extended 
description or the modes of introduction, although “Specification” is not 
currently treated as a distinct SDLC phase within the XML schema 
(pre-implementation, we mostly have just Requirements and Design/Architecture, 
and it seems to me that “specifications” can be developed in many different 
phases). Currently, CWE-436’s modes of introduction list both Implementation 
and Architecture/Design without further explanation, so that could be further 
expanded upon.

- Steve


From: Rob Wissmann 
Sent: Tuesday, July 5, 2022 12:19 PM
To: Steven M Christey ; Seifried, Kurt ; 
jonathan.w.hood6@army.mil
Cc: CWE Research Discussion 
Subject: RE: [Non-DoD Source] Is there a CWE for this?

Steven,

Is there any room to update the description or extended description of CWE-436: 
Interpretation Conflict to suggest specs or requirements may be at fault for 
leaving certain behaviors up the implementation that should not be, leaving 
room for interpretation conflicts to occur and become vulnerabilities?

For example, the JSON spec is underspecified for certain error conditions, 
which leads to interoperability errors. 
https://bishopfox.com/blog/json-interoperability-vulnerabilities

Not sure if Kurt’s issue is an RFC issue but if the RFC doesn’t specify what a 
client should do when receiving a bad header field, it could be.

-Rob

From: Steven M Christey mailto:co...@mitre.org>>
Sent: Monday, July 4, 2022 7:50 PM
To: Seifried, Kurt mailto:k...@seifried.org>>; 
jonathan.w.hood6@army.mil<mailto:jonathan.w.hood6@army.mil>
Cc: CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: RE: [Non-DoD Source] Is there a CWE for this?

This is an interesting and simultaneously complicated question.

While the names and descriptions for CWE-140 through CWE-146 are not clear 
about the distinction, the mitigations are all about input, and their 
Class-level ancestor CWE-138: Improper Neutralization of Special Elements is 
input-focused: “The software receives input from an upstream component…” So, 
the intention of these CWEs was for input only.

As a side note, the names and descriptions for CWE-140 through CWE-146 should 
be modernized because of the possibility of misinterpretation, and the lack of 
emphasis on the intended behavior (also, was it really necessary to make 
variants for each type of “delimiter”? That PLOVER guy from 2006 has some 
explaining to do (for those who don’t get the joke, it was me)). These are 
early-day CWEs that reflected the focus on skilled vuln researchers, not 
developers.

In this case with the extra semicolon for includeSubdomains, deeper analysis is 
required. Kurt says that the semicolon is “not needed.” But is it technically 
allowed according to the spec (… and if so,  spec? HSTS? HTTP?) If a 
semicolon is technically allowed, then maybe there’s some kind of parsing error 
on the part of the client because it isn’t following the spec (CWE-684: 
Incorrect Provision of Specified Functionality )? But if both sides of this 
exchange are following some spec (with allowances for “undefined” behavior), 
then this could be regarded as CWE-436: Interpretation Conflict.

Parsing input and translating it to incorrect values is a gap in CWE that we’re 
aware of, but even if the issue is CWE-684 or some descendant of CWE-138, 
hopefully this will show that there are community-wide limitations in our 
language for classifying weaknesses that aren’t the “usual” basic issues like 
overflows and injection.

- Steve


From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Sunday, July 3, 2022 3:47 PM
To: jonathan.w.hood6@army.mil<mailto:jonathan.w.hood6@army.mil>
Cc: CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: Re: [Non-DoD Source] Is there a CWE for this?

I would prefer to split them because you have two possibilities:

1) fix the output
2) be more tolerant of input and maybe (safely?) try to suss out what happens, 
e.g. is there an attack scenario for an attacker injecting headers with an 
extra ; that are then parses in an HSTS scenario? I can't think of one, so it 
should be safe, but I could be wrong.



On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
mailto:jonathan.w.hood6@army.mil>> wrote:
I see what you’re saying about the CWE-14[0-6] family being pretty limited to 
input processing when the issue could exist because of input or malformed 
output. Perhaps changing these to input/output would be more inclusive of this 
type of issue. Good catch.

From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Friday, July 1, 2022 8:37 PM
To: CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION 
mailto:CWE-RESEARCH-LIST@mitre.org>>
Subject: [Non-DoD Source] Is there a CWE for this?

I ran across this today while auditin

Re: [Non-DoD Source] Is there a CWE for this?

[Kurt Seifried]

I would say it's a sliding scale with room for several CWE's:

at the "definite": end, someone implements the RFC incorrectly. I mean.
Yeah. the output should look like X, it doesn't, therefore it's wrong.

at the maybe middle: there are common behaviors/consensus, like Rob's JSON
example, which... well. "it depends". There are definitely more safe
behaviors than not (e.g. throw an error, refuse it, etc.), so in my mind,
as there is a solution, something actionable, then there is value in having
a CWE.

at the "we're not sure" end: there are things that are not
security/exploitable per se (at least not yet)... but they are concerning.
And again being aware of them is a lot safer than not being aware of them
at all. But I've seen all too many things go from "that's weird but never a
problem" to "that's a CWE top 25 now." So I would say the sooner it gets a
CWE, the better.



On Tue, Jul 5, 2022 at 10:19 AM Rob Wissmann 
wrote:

> Steven,
>
>
>
> Is there any room to update the description or extended description of
> CWE-436: Interpretation Conflict to suggest specs or requirements may be at
> fault for leaving certain behaviors up the implementation that should not
> be, leaving room for interpretation conflicts to occur and become
> vulnerabilities?
>
>
>
> For example, the JSON spec is underspecified for certain error conditions,
> which leads to interoperability errors.
> https://bishopfox.com/blog/json-interoperability-vulnerabilities
>
>
>
> Not sure if Kurt’s issue is an RFC issue but if the RFC doesn’t specify
> what a client should do when receiving a bad header field, it could be.
>
>
>
> -Rob
>
>
>
> *From:* Steven M Christey 
> *Sent:* Monday, July 4, 2022 7:50 PM
> *To:* Seifried, Kurt ; jonathan.w.hood6@army.mil
> *Cc:* CWE Research Discussion 
> *Subject:* RE: [Non-DoD Source] Is there a CWE for this?
>
>
>
> This is an interesting and simultaneously complicated question.
>
>
>
> While the names and descriptions for CWE-140 through CWE-146 are not clear
> about the distinction, the mitigations are all about input, and their
> Class-level ancestor CWE-138: Improper Neutralization of Special Elements
> is input-focused: “The software receives input from an upstream component…”
> So, the intention of these CWEs was for input only.
>
>
>
> As a side note, the names and descriptions for CWE-140 through CWE-146
> should be modernized because of the possibility of misinterpretation, and
> the lack of emphasis on the intended behavior (also, was it really
> necessary to make variants for each type of “delimiter”? That PLOVER guy
> from 2006 has some explaining to do (for those who don’t get the joke, it
> was me)). These are early-day CWEs that reflected the focus on skilled vuln
> researchers, not developers.
>
>
>
> In this case with the extra semicolon for includeSubdomains, deeper
> analysis is required. Kurt says that the semicolon is “not needed.” But is
> it technically allowed according to the spec (… and if so,  spec?
> HSTS? HTTP?) If a semicolon is technically allowed, then maybe there’s some
> kind of parsing error on the part of the client because it isn’t following
> the spec (CWE-684: Incorrect Provision of Specified Functionality )? But if
> both sides of this exchange are following some spec (with allowances for
> “undefined” behavior), then this could be regarded as CWE-436:
> Interpretation Conflict.
>
>
>
> Parsing input and translating it to incorrect values is a gap in CWE that
> we’re aware of, but even if the issue is CWE-684 or some descendant of
> CWE-138, hopefully this will show that there are community-wide limitations
> in our language for classifying weaknesses that aren’t the “usual” basic
> issues like overflows and injection.
>
>
>
> - Steve
>
>
>
>
>
> *From:* Kurt Seifried 
> *Sent:* Sunday, July 3, 2022 3:47 PM
> *To:* jonathan.w.hood6@army.mil
> *Cc:* CWE Research Discussion 
> *Subject:* Re: [Non-DoD Source] Is there a CWE for this?
>
>
>
> I would prefer to split them because you have two possibilities:
>
>
>
> 1) fix the output
>
> 2) be more tolerant of input and maybe (safely?) try to suss out what
> happens, e.g. is there an attack scenario for an attacker injecting headers
> with an extra ; that are then parses in an HSTS scenario? I can't think of
> one, so it should be safe, but I could be wrong.
>
>
>
>
>
>
>
> On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC
> (USA)  wrote:
>
> I see what you’re saying about the CWE-14[0-6] family being pretty limited
> to input processing when the issue could exist because of input or
> mal

RE: [Non-DoD Source] Is there a CWE for this?

[Rob Wissmann]

Steven,

Is there any room to update the description or extended description of CWE-436: 
Interpretation Conflict to suggest specs or requirements may be at fault for 
leaving certain behaviors up the implementation that should not be, leaving 
room for interpretation conflicts to occur and become vulnerabilities?

For example, the JSON spec is underspecified for certain error conditions, 
which leads to interoperability errors. 
https://bishopfox.com/blog/json-interoperability-vulnerabilities

Not sure if Kurt’s issue is an RFC issue but if the RFC doesn’t specify what a 
client should do when receiving a bad header field, it could be.

-Rob

From: Steven M Christey 
Sent: Monday, July 4, 2022 7:50 PM
To: Seifried, Kurt ; jonathan.w.hood6@army.mil
Cc: CWE Research Discussion 
Subject: RE: [Non-DoD Source] Is there a CWE for this?

This is an interesting and simultaneously complicated question.

While the names and descriptions for CWE-140 through CWE-146 are not clear 
about the distinction, the mitigations are all about input, and their 
Class-level ancestor CWE-138: Improper Neutralization of Special Elements is 
input-focused: “The software receives input from an upstream component…” So, 
the intention of these CWEs was for input only.

As a side note, the names and descriptions for CWE-140 through CWE-146 should 
be modernized because of the possibility of misinterpretation, and the lack of 
emphasis on the intended behavior (also, was it really necessary to make 
variants for each type of “delimiter”? That PLOVER guy from 2006 has some 
explaining to do (for those who don’t get the joke, it was me)). These are 
early-day CWEs that reflected the focus on skilled vuln researchers, not 
developers.

In this case with the extra semicolon for includeSubdomains, deeper analysis is 
required. Kurt says that the semicolon is “not needed.” But is it technically 
allowed according to the spec (… and if so,  spec? HSTS? HTTP?) If a 
semicolon is technically allowed, then maybe there’s some kind of parsing error 
on the part of the client because it isn’t following the spec (CWE-684: 
Incorrect Provision of Specified Functionality )? But if both sides of this 
exchange are following some spec (with allowances for “undefined” behavior), 
then this could be regarded as CWE-436: Interpretation Conflict.

Parsing input and translating it to incorrect values is a gap in CWE that we’re 
aware of, but even if the issue is CWE-684 or some descendant of CWE-138, 
hopefully this will show that there are community-wide limitations in our 
language for classifying weaknesses that aren’t the “usual” basic issues like 
overflows and injection.

- Steve


From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Sunday, July 3, 2022 3:47 PM
To: jonathan.w.hood6@army.mil<mailto:jonathan.w.hood6@army.mil>
Cc: CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: Re: [Non-DoD Source] Is there a CWE for this?

I would prefer to split them because you have two possibilities:

1) fix the output
2) be more tolerant of input and maybe (safely?) try to suss out what happens, 
e.g. is there an attack scenario for an attacker injecting headers with an 
extra ; that are then parses in an HSTS scenario? I can't think of one, so it 
should be safe, but I could be wrong.



On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
mailto:jonathan.w.hood6@army.mil>> wrote:
I see what you’re saying about the CWE-14[0-6] family being pretty limited to 
input processing when the issue could exist because of input or malformed 
output. Perhaps changing these to input/output would be more inclusive of this 
type of issue. Good catch.

From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Friday, July 1, 2022 8:37 PM
To: CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION 
mailto:CWE-RESEARCH-LIST@mitre.org>>
Subject: [Non-DoD Source] Is there a CWE for this?

I ran across this today while auditing CSA services quarterly:

In bl.ink URL redirection service, as of 2022-07-01 an improperly formatted 
security header exists in the HSTS support, specifically, the header served is 
\"strict-transport-security: max-age=63072000; includeSubdomains;\" which 
contains an extra semicolon (the final one is not needed), this may result in 
some client ignoring the HSTS header and thus rendering this security 
protection ineffective.

there's some stuff for inbound/input/malformed/configuration/directive/etc, but 
I'm not seeing anything for malformed outbound configuration/output.

--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>


--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>

Re: [Non-DoD Source] Is there a CWE for this?

[Kurt Seifried]

On Mon, Jul 4, 2022 at 5:49 PM Steven M Christey  wrote:

> This is an interesting and simultaneously complicated question.
>
>
>
> While the names and descriptions for CWE-140 through CWE-146 are not clear
> about the distinction, the mitigations are all about input, and their
> Class-level ancestor CWE-138: Improper Neutralization of Special Elements
> is input-focused: “The software receives input from an upstream component…”
> So, the intention of these CWEs was for input only.
>
>
>
> As a side note, the names and descriptions for CWE-140 through CWE-146
> should be modernized because of the possibility of misinterpretation, and
> the lack of emphasis on the intended behavior (also, was it really
> necessary to make variants for each type of “delimiter”? That PLOVER guy
> from 2006 has some explaining to do (for those who don’t get the joke, it
> was me)). These are early-day CWEs that reflected the focus on skilled vuln
> researchers, not developers.
>
>
>
> In this case with the extra semicolon for includeSubdomains, deeper
> analysis is required. Kurt says that the semicolon is “not needed.” But is
> it technically allowed according to the spec (… and if so,  spec?
> HSTS? HTTP?) If a semicolon is technically allowed, then maybe there’s some
> kind of parsing error on the part of the client because it isn’t following
> the spec (CWE-684: Incorrect Provision of Specified Functionality )? But if
> both sides of this exchange are following some spec (with allowances for
> “undefined” behavior), then this could be regarded as CWE-436:
> Interpretation Conflict.
>
>
Nope, there's no ambiguity, those extra semicolons are out of spec:

https://datatracker.ietf.org/doc/html/rfc6797

6.1.  Strict-Transport-Security HTTP Response Header Field

   The Strict-Transport-Security HTTP response header field (STS header
   field) indicates to a UA that it MUST enforce the HSTS Policy in
   regards to the host emitting the response message containing this
   header field.

   The ABNF (Augmented Backus-Naur Form) syntax for the STS header field
   is given below.  It is based on the Generic Grammar defined in
   Section 2 of [RFC2616] (which includes a notion of "implied linear
   whitespace", also known as "implied *LWS").

 Strict-Transport-Security = "Strict-Transport-Security" ":"
 [ directive ]  *( ";" [ directive ] )

 directive = directive-name [ "=" directive-value ]
 directive-name= token
 directive-value   = token | quoted-string


==

6.2.  Examples

   The HSTS header field below stipulates that the HSTS Policy is to
   remain in effect for one year (there are approximately 31536000
   seconds in a year), and the policy applies only to the domain of the
   HSTS Host issuing it:

 Strict-Transport-Security: max-age=31536000

   The HSTS header field below stipulates that the HSTS Policy is to
   remain in effect for approximately six months and that the policy
   applies to the domain of the issuing HSTS Host and all of its
   subdomains:

 Strict-Transport-Security: max-age=15768000 ; includeSubDomains




> Parsing input and translating it to incorrect values is a gap in CWE that
> we’re aware of, but even if the issue is CWE-684 or some descendant of
> CWE-138, hopefully this will show that there are community-wide limitations
> in our language for classifying weaknesses that aren’t the “usual” basic
> issues like overflows and injection.
>
>
>
> - Steve
>
>
>
>
>
> *From:* Kurt Seifried 
> *Sent:* Sunday, July 3, 2022 3:47 PM
> *To:* jonathan.w.hood6@army.mil
> *Cc:* CWE Research Discussion 
> *Subject:* Re: [Non-DoD Source] Is there a CWE for this?
>
>
>
> I would prefer to split them because you have two possibilities:
>
>
>
> 1) fix the output
>
> 2) be more tolerant of input and maybe (safely?) try to suss out what
> happens, e.g. is there an attack scenario for an attacker injecting headers
> with an extra ; that are then parses in an HSTS scenario? I can't think of
> one, so it should be safe, but I could be wrong.
>
>
>
>
>
>
>
> On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC
> (USA)  wrote:
>
> I see what you’re saying about the CWE-14[0-6] family being pretty limited
> to input processing when the issue could exist because of input or
> malformed output. Perhaps changing these to input/output would be more
> inclusive of this type of issue. Good catch.
>
>
>
> *From:* Kurt Seifried 
> *Sent:* Friday, July 1, 2022 8:37 PM
> *To:* CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION <
> CWE-RESEARCH-LIST@mitre.org>
> *Subject:* [Non-DoD Source] Is there a 

RE: [Non-DoD Source] Is there a CWE for this?

[Steven M Christey]

This is an interesting and simultaneously complicated question.

While the names and descriptions for CWE-140 through CWE-146 are not clear 
about the distinction, the mitigations are all about input, and their 
Class-level ancestor CWE-138: Improper Neutralization of Special Elements is 
input-focused: “The software receives input from an upstream component…” So, 
the intention of these CWEs was for input only.

As a side note, the names and descriptions for CWE-140 through CWE-146 should 
be modernized because of the possibility of misinterpretation, and the lack of 
emphasis on the intended behavior (also, was it really necessary to make 
variants for each type of “delimiter”? That PLOVER guy from 2006 has some 
explaining to do (for those who don’t get the joke, it was me)). These are 
early-day CWEs that reflected the focus on skilled vuln researchers, not 
developers.

In this case with the extra semicolon for includeSubdomains, deeper analysis is 
required. Kurt says that the semicolon is “not needed.” But is it technically 
allowed according to the spec (… and if so,  spec? HSTS? HTTP?) If a 
semicolon is technically allowed, then maybe there’s some kind of parsing error 
on the part of the client because it isn’t following the spec (CWE-684: 
Incorrect Provision of Specified Functionality )? But if both sides of this 
exchange are following some spec (with allowances for “undefined” behavior), 
then this could be regarded as CWE-436: Interpretation Conflict.

Parsing input and translating it to incorrect values is a gap in CWE that we’re 
aware of, but even if the issue is CWE-684 or some descendant of CWE-138, 
hopefully this will show that there are community-wide limitations in our 
language for classifying weaknesses that aren’t the “usual” basic issues like 
overflows and injection.

- Steve


From: Kurt Seifried 
Sent: Sunday, July 3, 2022 3:47 PM
To: jonathan.w.hood6@army.mil
Cc: CWE Research Discussion 
Subject: Re: [Non-DoD Source] Is there a CWE for this?

I would prefer to split them because you have two possibilities:

1) fix the output
2) be more tolerant of input and maybe (safely?) try to suss out what happens, 
e.g. is there an attack scenario for an attacker injecting headers with an 
extra ; that are then parses in an HSTS scenario? I can't think of one, so it 
should be safe, but I could be wrong.



On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
mailto:jonathan.w.hood6@army.mil>> wrote:
I see what you’re saying about the CWE-14[0-6] family being pretty limited to 
input processing when the issue could exist because of input or malformed 
output. Perhaps changing these to input/output would be more inclusive of this 
type of issue. Good catch.

From: Kurt Seifried mailto:k...@seifried.org>>
Sent: Friday, July 1, 2022 8:37 PM
To: CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION 
mailto:CWE-RESEARCH-LIST@mitre.org>>
Subject: [Non-DoD Source] Is there a CWE for this?

I ran across this today while auditing CSA services quarterly:

In bl.ink URL redirection service, as of 2022-07-01 an improperly formatted 
security header exists in the HSTS support, specifically, the header served is 
\"strict-transport-security: max-age=63072000; includeSubdomains;\" which 
contains an extra semicolon (the final one is not needed), this may result in 
some client ignoring the HSTS header and thus rendering this security 
protection ineffective.

there's some stuff for inbound/input/malformed/configuration/directive/etc, but 
I'm not seeing anything for malformed outbound configuration/output.

--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>


--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>

Re: [Non-DoD Source] Is there a CWE for this?

[Kurt Seifried]

I would prefer to split them because you have two possibilities:

1) fix the output
2) be more tolerant of input and maybe (safely?) try to suss out what
happens, e.g. is there an attack scenario for an attacker injecting headers
with an extra ; that are then parses in an HSTS scenario? I can't think of
one, so it should be safe, but I could be wrong.



On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC
(USA)  wrote:

> I see what you’re saying about the CWE-14[0-6] family being pretty limited
> to input processing when the issue could exist because of input or
> malformed output. Perhaps changing these to input/output would be more
> inclusive of this type of issue. Good catch.
>
>
>
> *From:* Kurt Seifried 
> *Sent:* Friday, July 1, 2022 8:37 PM
> *To:* CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION <
> CWE-RESEARCH-LIST@mitre.org>
> *Subject:* [Non-DoD Source] Is there a CWE for this?
>
>
>
> I ran across this today while auditing CSA services quarterly:
>
>
>
> In bl.ink URL redirection service, as of 2022-07-01 an improperly
> formatted security header exists in the HSTS support, specifically, the
> header served is \"strict-transport-security: max-age=63072000;
> includeSubdomains;\" which contains an extra semicolon (the final one is
> not needed), this may result in some client ignoring the HSTS header and
> thus rendering this security protection ineffective.
>
>
>
> there's some stuff for
> inbound/input/malformed/configuration/directive/etc, but I'm not seeing
> anything for malformed outbound configuration/output.
>
>
>
> --
>
> Kurt Seifried (He/Him)
> k...@seifried.org
>


-- 
Kurt Seifried (He/Him)
k...@seifried.org

RE: [Non-DoD Source] Is there a CWE for this?

[Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA)]

I see what you’re saying about the CWE-14[0-6] family being pretty limited to 
input processing when the issue could exist because of input or malformed 
output. Perhaps changing these to input/output would be more inclusive of this 
type of issue. Good catch.

 

From: Kurt Seifried  
Sent: Friday, July 1, 2022 8:37 PM
To: CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION 
Subject: [Non-DoD Source] Is there a CWE for this?

 

I ran across this today while auditing CSA services quarterly:

 

In bl.ink URL redirection service, as of 2022-07-01 an improperly formatted 
security header exists in the HSTS support, specifically, the header served is 
\"strict-transport-security: max-age=63072000; includeSubdomains;\" which 
contains an extra semicolon (the final one is not needed), this may result in 
some client ignoring the HSTS header and thus rendering this security 
protection ineffective.

 

there's some stuff for inbound/input/malformed/configuration/directive/etc, but 
I'm not seeing anything for malformed outbound configuration/output. 


 

-- 

Kurt Seifried (He/Him)
k...@seifried.org  



smime.p7s
Description: S/MIME cryptographic signature