CWE discussion/request for DNS related issue

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

CWE discussion/request for DNS related issue

Kurt Seifried
So leaving DNS records "dangling", e.g. you had a record for www.example.org that pointed to a service provider that you no longer use, allowing someone else to use that service provider, register with the same name and start serving content as www.example.org, an example for this would be CloudFront:


To be clear the problem is not cloudfront (unless we never allow name reuse which would be painful), most services that use subdomain.theirtld.com allow reuse once an account lapses or is closed. The problem is in the person providing DNS records that point to services they no longer control. 

but I feel this example/case is different enough (and common enough) that it should warrant its own CWE especially now with the popularity of cloud services. 

--
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: CWE discussion/request for DNS related issue

Kurt Seifried-2


On Wed, Oct 11, 2017 at 10:39 AM, Scott Christiansen <[hidden email]> wrote:

That is an interesting topic because it possibly changes the scope of CWE.  Is CWE all about software and operational vulnerabilities or is it about abuse case vulnerabilities?   To piggy back on this, CWE has no record, that I’m familiar with for DoS, specifically DDoS.  I’m am all for CWE including all vulnerabilities types and not just “tooling detectable” issues.

 


DoS is semi covered by things like https://cwe.mitre.org/data/definitions/400.html https://cwe.mitre.org/data/definitions/405.html https://cwe.mitre.org/data/definitions/770.html nand https://cwe.mitre.org/data/definitions/920.html cover these, but only in general terms, e.g. there is nothing for regex pattern globbing abuse (a bunch use CWE-119 for this for example). 

As for DDoS that's a tougher one, I would say a lot of it boils down to reasonable expectations (e.g. a single server handling 1gigabit per second vs 500gigabits/second...) and any specific claims (e.g. this firewall handles X thousand connections, if it doesn't then there might be a problem somewhere). 

--

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: CWE discussion/request for DNS related issue

Kurt Seifried
For me it's primarily a combination of:

1) identifying root causes that commonly result in security vulnerabilities worth CVEs (e.g. buffer overflows, underflows, integer overflows, etc.), essentially "if you find X, it's probably going to result in a vulnerability so please tell the security people"
2) creating an ontology of flaws/mistakes/vulnerabilities so when we do talk about things we have some clearly defined terms, e.g. I still see many people referring to information disclosure issues as "memory leaks" (as opposed to memory consumption problems, two very different issues)

So in my vision there is the complete (yeah, I know...) ontology, some/many of which often result in security vulnerabilities (but not always). This ontology can be leveraged for security work, and also non security work, both by humans and tools. Which is basically what cwe.mitre.org says at the top =)



On Wed, Oct 11, 2017 at 11:30 AM, Scott Christiansen <[hidden email]> wrote:

I would say that CWE-400 and CWE-405 are all about system resource consumption and over utilization.  I agree, that in spirit they fit a network style DoS vuln, but not really without having to stretch their meaning.  Also, is CWE-920 a legitimate ‘Security’ issue.  To me that is more of another ‘functional’ vulnerability and shouldn’t even be a CWE.  It isn’t much more valuable than stating that someone could unplug the laptop charging cable causing the battery to drain.

 

My biggest beef with the current CWE list is that it is stale.  There is a lot of content focused on boxed products, not much in the way of issues that pertain to web services and operational security (issues that arise after the software is installed and running), and includes things like CWE-920 but doesn’t have something just as general for DDoS (overconsumption of network resources causing nodes to not be able to establish complete communication with connected hosts; or something along those lines).  As a result, I can’t say mitigation x protects your against CWE y.

 

That gets me back to the wondering what the intentions are of CWE moving forward?  Are they to provide specific vulns that can be tooled and detected, are they for high level issues that can be audited or it is a random lump of stuff that is semi valuable given specific context?

 

Scott Christiansen

Sr. Security Program Manager

Trustworthy Computing – Security Engineering

Microsoft

 

 

From: Kurt Seifried [mailto:[hidden email]]
Sent: Wednesday, October 11, 2017 9:58 AM
To: Scott Christiansen <[hidden email]>
Cc: Kurt Seifried <[hidden email]>; cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: CWE discussion/request for DNS related issue

 

 

 

On Wed, Oct 11, 2017 at 10:39 AM, Scott Christiansen <[hidden email]> wrote:

That is an interesting topic because it possibly changes the scope of CWE.  Is CWE all about software and operational vulnerabilities or is it about abuse case vulnerabilities?   To piggy back on this, CWE has no record, that I’m familiar with for DoS, specifically DDoS.  I’m am all for CWE including all vulnerabilities types and not just “tooling detectable” issues.

 

 

DoS is semi covered by things like https://cwe.mitre.org/data/definitions/400.html https://cwe.mitre.org/data/definitions/405.html https://cwe.mitre.org/data/definitions/770.html nand https://cwe.mitre.org/data/definitions/920.html cover these, but only in general terms, e.g. there is nothing for regex pattern globbing abuse (a bunch use CWE-119 for this for example). 

 

As for DDoS that's a tougher one, I would say a lot of it boils down to reasonable expectations (e.g. a single server handling 1gigabit per second vs 500gigabits/second...) and any specific claims (e.g. this firewall handles X thousand connections, if it doesn't then there might be a problem somewhere). 

 

--


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]




--
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: CWE discussion/request for DNS related issue

Wheeler, David A

> Also, is CWE-920 a legitimate ‘Security’ issue..

 

Yes, it is an important *security* issue for a number of people.  This is so important that people have even studied which colors use the most power.  If you’re near an electrical plug this is no problem, but in some circumstances, attackers will specifically focus on draining power specifically to create life-threatening circumstances.  This is specifically called out in some places, e.g., the Software SOAR (Wheeler and Henninger 2016).

 

> My biggest beef with the current CWE list is that it is stale.. what [are the intentions] of CWE moving forward? 

I agree with its staleness.  CWE is missing a number of weaknesses (as noted), and its structure isn’t really its strength.  At the least, adding important & not-currently-covered CWEs is important, and updating other text is useful too.

 

Here are some other examples…

 

Cleartext and reversible passwords have CWEs, but as far as I can tell there’s no CWEs for “failure to securely store passwords to allow authentication of requesters”.  I think today the *bare* minimum for storing a password in a system, to allow others to authenticate to that system, is iterated per-user salted cryptographic hashes.  The salts need to be at least 128 bits of cryptographically random data (per NIST), and the cryptographic hash algorithm needs to be something unbroken.  Anything less than this is *unacceptable* today.  Bcrypt is fine; PBKDF2 is probably okay though it’s weakner against GPUs.  If someone stores a SHA-1 of a password (unsalted and without iteration), there’s no obvious CWE to point to, even though that is embarrassingly inadequate today.

 

Similarly, the password text discusses the need to use upper/lower case  & to force resetting, but this has not stood up well in the real world.  NIST 800-63 is weakening the recommendations & abandoning these approaches respectively:

* “composition rules… require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought…”

* “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).”

 

I think CWEs are very useful, I refer to them often.  But they need additions and updates.

 

Thanks!

 

--- David A. Wheeler

Reply | Threaded
Open this post in threaded view
|

Re: CWE discussion/request for DNS related issue

Kurt Seifried-2


On Wed, Oct 11, 2017 at 3:10 PM, Wheeler, David A <[hidden email]> wrote:

> Also, is CWE-920 a legitimate ‘Security’ issue..

 

Yes, it is an important *security* issue for a number of people.  This is so important that people have even studied which colors use the most power.  If you’re near an electrical plug this is no problem, but in some circumstances, attackers will specifically focus on draining power specifically to create life-threatening circumstances.  This is specifically called out in some places, e.g., the Software SOAR (Wheeler and Henninger 2016).

 

> My biggest beef with the current CWE list is that it is stale.. what [are the intentions] of CWE moving forward? 

I agree with its staleness.  CWE is missing a number of weaknesses (as noted), and its structure isn’t really its strength.  At the least, adding important & not-currently-covered CWEs is important, and updating other text is useful too.

 

Here are some other examples…

 

Cleartext and reversible passwords have CWEs, but as far as I can tell there’s no CWEs for “failure to securely store passwords to allow authentication of requesters”.  I think today the *bare* minimum for storing a password in a system, to allow others to authenticate to that system, is iterated per-user salted cryptographic hashes.  The salts need to be at least 128 bits of cryptographically random data (per NIST), and the cryptographic hash algorithm needs to be something unbroken.  Anything less than this is *unacceptable* today.  Bcrypt is fine; PBKDF2 is probably okay though it’s weakner against GPUs.  If someone stores a SHA-1 of a password (unsalted and without iteration), there’s no obvious CWE to point to, even though that is embarrassingly inadequate today.

 

Similarly, the password text discusses the need to use upper/lower case  & to force resetting, but this has not stood up well in the real world.  NIST 800-63 is weakening the recommendations & abandoning these approaches respectively:

* “composition rules… require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought…”

* “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).”


I would suggest we coordinate this with the CVE board, simply put the line in the sand is moving, and it's probably time to make some moves on passwords, especially storage as you point out. It's also a very complicated problem: 

1) password salt required yes/no, and if so, how strong
2) hashing algorithms allowed / how many rounds (e.g. do we allow SHA512? what about 10 billion rounds of SHA512?)
3) maybe some CWE/CVE "guidance" for the future (e.g. quantum attack resistant hashing algorithms: "CWE-foo, failure to use quantum attack resistant hashing algorithm for password storage" ?). 
4) Do we want to look at password strength? What about things like "CWE-bar, failure to check password against known dictionary of passwords" how do we define which password dictionaries to use? Entropy requirements/testing?

The problem is with the above you can compensate, e.g. using a less good password storage mechanism but require passwords with 512 bits of entropy, so the CWE's would ideally be inter-related or maybe some meta thing (and we're in to business logic rules, yipee!)

To say nothing of:

5a) Password reset issues
5b) Password recovery issues

Who cares if you have awesome password storage/etc if I can recover your account based on your username and date of birth?

6) account lockout/slow down stuff (which can in and of itself result in DoS)

Same for this, stop brute force attacks against IoT devices, but then lock the owner out?


 

 

I think CWEs are very useful, I refer to them often.  But they need additions and updates.

 

Thanks!

 

--- David A. Wheeler




--

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: CWE discussion/request for DNS related issue

Delfi Ramirez
In reply to this post by Kurt Seifried-2

Hi all:

+1

Agreed with Scott's concerns. on web services and browser boxed issues

cheers

---
Delfi Ramirez -- At Work

Mobile: 00 34 633 589231
Email: <a href="mail:%20delfin@segonquart.net">delfin@...




My digital signature
twitter: @delfinramirez

IRC: segonquart
Skype: <a href="skype:segonquart">segonquart
http://segonquart.net
 

 

On 2017-10-11 13:30, Scott Christiansen wrote:

I would say that CWE-400 and CWE-405 are all about system resource consumption and over utilization.  I agree, that in spirit they fit a network style DoS vuln, but not really without having to stretch their meaning.  Also, is CWE-920 a legitimate 'Security' issue.  To me that is more of another 'functional' vulnerability and shouldn't even be a CWE.  It isn't much more valuable than stating that someone could unplug the laptop charging cable causing the battery to drain.

 

My biggest beef with the current CWE list is that it is stale.  There is a lot of content focused on boxed products, not much in the way of issues that pertain to web services and operational security (issues that arise after the software is installed and running), and includes things like CWE-920 but doesn't have something just as general for DDoS (overconsumption of network resources causing nodes to not be able to establish complete communication with connected hosts; or something along those lines).  As a result, I can't say mitigation x protects your against CWE y.

 

That gets me back to the wondering what the intentions are of CWE moving forward?  Are they to provide specific vulns that can be tooled and detected, are they for high level issues that can be audited or it is a random lump of stuff that is semi valuable given specific context?

 

Scott Christiansen

Sr. Security Program Manager

Trustworthy Computing – Security Engineering

Microsoft

 

 

From: Kurt Seifried [mailto:[hidden email]]
Sent: Wednesday, October 11, 2017 9:58 AM
To: Scott Christiansen <[hidden email]>
Cc: Kurt Seifried <[hidden email]>; cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: CWE discussion/request for DNS related issue

 

 

 

On Wed, Oct 11, 2017 at 10:39 AM, Scott Christiansen <[hidden email]> wrote:

That is an interesting topic because it possibly changes the scope of CWE.  Is CWE all about software and operational vulnerabilities or is it about abuse case vulnerabilities?   To piggy back on this, CWE has no record, that I'm familiar with for DoS, specifically DDoS.  I'm am all for CWE including all vulnerabilities types and not just "tooling detectable" issues.

 

 

DoS is semi covered by things like https://cwe.mitre.org/data/definitions/400.html https://cwe.mitre.org/data/definitions/405.html https://cwe.mitre.org/data/definitions/770.html nand https://cwe.mitre.org/data/definitions/920.html cover these, but only in general terms, e.g. there is nothing for regex pattern globbing abuse (a bunch use CWE-119 for this for example). 

 

As for DDoS that's a tougher one, I would say a lot of it boils down to reasonable expectations (e.g. a single server handling 1gigabit per second vs 500gigabits/second...) and any specific claims (e.g. this firewall handles X thousand connections, if it doesn't then there might be a problem somewhere). 

 

--


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: CWE discussion/request for DNS related issue

Christey, Steven M.
In reply to this post by Kurt Seifried-2
All,

I believe that the hashing issues are already covered by CWE-916 Use of Password Hash With Insufficient Computational Effort.  The Mitigations entry covers things like bcrypt and PBKDF2.  This entry has been in CWE since 2013 and is the parent of two other hash-related CWEs (759 and 760) which explicitly mentioned salts.  One can use the front page of cwe.mitre.org and enter "hash" into the Google search box to find similar entries.

Regarding password complexity, entries such as CWE-521 "Weak Password Requirements" could be updated.

A trick in some of these discussions is how CWE can adequately describe the underlying weakness and provide sufficient mitigation guidance in cases where there is not universal agreement about which mitigations are appropriate.  CWE-916, mentioned above, is an example of this attempt to balance multiple opinions.

- Steve


Reply | Threaded
Open this post in threaded view
|

Re: CWE discussion/request for DNS related issue

Christey, Steven M.
In reply to this post by Kurt Seifried
Scott,

CWE's scope has traditionally been about software weaknesses - whether implementation faults or design flaws - with some operational coverage such as permissions.  Three use cases are (1) allow different automated tools to report what weaknesses they find, (2) allow developers to classify their own issues, and (3) educate developers.  But CWE is not limited to "tooling detectable" issues to use your phrasing; there are a lot of CWEs that aren't detectable by tools.

The focus of CWE has been on what software developers and designers introduce into the software to create vulnerabilities.  To bring in, say, commonly-encountered insecure DevOps/sysadmin practices might expand CWE's scope past a point of utility for many users.  It's something that we would need to consider carefully, in coordination with our sponsor.

At any rate, since CWE is focused on the underlying weaknesses, DDoS would not get direct coverage; that's an attack, which is more appropriately covered by CAPEC.  A question is, what are the underlying weaknesses or mistakes that enable DDoS to be executed?   And that's answerable by CWEs such as asymmetric resource consumption (CWE-405), insufficient control of network message volume (CWE-406), etc.  Since these kinds of design issues are not as well-studied as buffer overflows, there is a greater difficulty in classifying and describing them from a weakness perspective, which requires detailed, time-consuming original research.

- Steve

Reply | Threaded
Open this post in threaded view
|

Re: CWE discussion/request for DNS related issue

Shifflett, David M [US] (ES&CSO)
Steve,

Great point!! At this point is where the developers, designers, cyber system engineer, and information security engineers decided how the issue can be mitigated. If the developers and designers find themselves in a corner over a requirement or process it up to the cyber system engineer to help weave their web to mitigate the issue. If that does not work the information security or ISSM/ISSO needs to adjust the OS or network to provide a fix. It a team effort. The hopes are that the developer and designer are meet the customers' requirements and  not have to make major changes to a network or OS.

Great conversations.

Best regards

David M Shifflett MSIA, MSSE, Security+
Computer System Analyst/CSO
Northrop Grumman –ES&CSO
6400 SE 59th Street
Oklahoma City, OK 73135
Office Number: (405) 869 8468
Fax Number: (405) 869-8501
Cell: 405-227-0188
Pager 405 218-1150
[hidden email]





-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Christey, Steven M.
Sent: Friday, October 13, 2017 11:49 AM
To: Scott Christiansen; Kurt Seifried; cwe-research-list CWE Research Discussion
Subject: EXT :RE: CWE discussion/request for DNS related issue

Scott,

CWE's scope has traditionally been about software weaknesses - whether implementation faults or design flaws - with some operational coverage such as permissions.  Three use cases are (1) allow different automated tools to report what weaknesses they find, (2) allow developers to classify their own issues, and (3) educate developers.  But CWE is not limited to "tooling detectable" issues to use your phrasing; there are a lot of CWEs that aren't detectable by tools.

The focus of CWE has been on what software developers and designers introduce into the software to create vulnerabilities.  To bring in, say, commonly-encountered insecure DevOps/sysadmin practices might expand CWE's scope past a point of utility for many users.  It's something that we would need to consider carefully, in coordination with our sponsor.

At any rate, since CWE is focused on the underlying weaknesses, DDoS would not get direct coverage; that's an attack, which is more appropriately covered by CAPEC.  A question is, what are the underlying weaknesses or mistakes that enable DDoS to be executed?   And that's answerable by CWEs such as asymmetric resource consumption (CWE-405), insufficient control of network message volume (CWE-406), etc.  Since these kinds of design issues are not as well-studied as buffer overflows, there is a greater difficulty in classifying and describing them from a weakness perspective, which requires detailed, time-consuming original research.

- Steve