uot;
What happens when they have CVEs that aren't covered by a CWE and they want
a CWE for it? Does everyone go through the front door so to speak at
https://cwesubmission.mitre.org/?
--
Kurt Seifried (He/Him)
k...@seifried.org
two
> space-delimited values. You should be able to confirm this be resizing the
> window and looking for these two values to wrap together when possible.
>
>
>
> Let us know if you have any further questions!
>
>
>
> Thanks,
>
> David Rothenberg
>
>
>
ot;
http://cwe.mitre.org/cwe-7 http://cwe.mitre.org/data/xsd/cwe_schema_v7.1.xsd
">
should probably just be https://cwe.mitre.org/data/xsd/cwe_schema_v7.1.xsd,
not sure why http://cwe.mitre.org/cwe-7 with a line return is in there?
--
Kurt Seifried (He/Him)
k...@seifried.org
ictable, e.g. some devices use the hardware MAC address as the password:
https://www.qnap.com/en-in/how-to/faq/article/default-password-of-admin-is-changed-to-first-mac-address-after-qts-4-4-2
So if the attacker is on the LAN... or device makers use known ranges of
MAC addresses .. which they do...
> * Uses a known insecure algorithm for security purposes, e.g., MD5 or SHA-1
> or DES as a security mechanism. Non-security uses are fine.
>
> Can you define security/non security?
>
> --- David A. Wheeler
>
>
>
--
Kurt Seifried (He/Him)
k...@seifried.org
e by default).
> An interface that "cannot be made safe to use" does seem different
> than "insecure by default
> but theoretically possible to configure into being secure". I'm sure
> there will be many discussions.
>
> That said, the first step is to acknowledge that "insecure by default" *IS* a
> security vulnerability & specifically label it as a category of vulnerability.
> People can then work to carefully define it & come to a general consensus.
>
> Anyway, I hope you find this idea helpful. Thank you!
>
> --- David A. Wheeler
> Director of Open Source Supply Chain Security, The Linux Foundation
>
>
--
Kurt Seifried (He/Him)
k...@seifried.org
E entries related to system
>> components that might already be applicable; we could possibly modify one
>> of them to name licensing as a consideration.
>>
>>
>>
>> The most applicable would be CWE-1357: Reliance on Insufficiently
>> Trustworthy Component. “
> supply chain risk management and composition analysis, the licensing issues
> and weaknesses in aggregated software are becoming more of a problem. Being
> able to categorize these weaknesses meaningfully would be helpful.
>
>
>
> Jon
>
>
>
> -Original Message-
; --
>
> *Alec J. Summers*
>
> Center for Securing the Homeland (CSH)
>
> Cyber Security Engineer, Principal
>
> Group Lead, Cybersecurity Operations and Integration
>
> **
>
> *MITRE - Solving Problems for a Safer World™*
>
>
>
>
>
--
Kurt Seifried (He/Him)
k...@seifried.org
itable or potentially exploitable. It also helps
> protect from the “changes with time” issue since what is accepted to be
> exploitable or potentially so necessarily changes with time.
>
>
>
> Thanks
>
>
>
> *From:* Kurt Seifried
> *Sent:* Thursday, July 1
nth. Please provide thoughts and comments by Tuesday, July 26.
>>
>>
>>
>> Cheers,
>>
>> Alec
>>
>>
>>
>> --
>>
>> *Alec J. Summers*
>>
>> Center for Securing the Homeland (CSH)
>>
>> Cyber Security Engineer, Principal
>>
>> Group Lead, Cybersecurity Operations and Integration
>>
>> **
>>
>> *MITRE - Solving Problems for a Safer World™*
>>
>>
>>
>>
>>
>
--
Kurt Seifried (He/Him)
k...@seifried.org
fined” 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
e=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 class
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@mi
r malformed outbound configuration/output.
--
Kurt Seifried (He/Him)
k...@seifried.org
description also is worded as if the two are
> interchangeable:
>
>
>
> The product does not properly compartmentalize or isolate functionality,
> processes, or resources that require different privilege levels, rights, or
> permissions.
>
>
>
> The title and description should be reverted to remove conflation of the
> terms.
>
>
>
> Thank you,
>
> Rob Wissmann
>
--
Kurt Seifried (He/Him)
k...@seifried.org
ll, though, since the developer might be doing this intentionally even
> > though the code is not technically essential.
>
> In the end, we chose 1164. It was added to a csv file where we are
> cateloging
> warnings from a couple tools and mapping to CWE. It is here in case anyone
> finds it useful:
>
> https://github.com/csutils/csmock/blob/main/cwe-map.csv
>
> Thanks for the help!
>
> -Steve
>
>
>
--
Kurt Seifried (He/Him)
k...@seifried.org
On Tue, May 24, 2022 at 12:24 PM Steve Grubb wrote:
> On Tuesday, May 24, 2022 1:55:17 PM EDT Kurt Seifried wrote:
> > On Tue, May 24, 2022 at 9:25 AM Steve Grubb wrote:
> > > Hello,
> > >
> > > I am continuing to look at ShellCheck and how to map it's w
have a variable called
"dir" and an actual instance of a file or directory or whatever called
"dir"? Probably not but maybe yes?
Maybe a more generic along the lines of are you using variables and values
that happen to share the same naming, e.g. "$dir" and "dir" which makes a
mess much easier?
>
> Best Regards,
> -Steve
>
>
--
Kurt Seifried (He/Him)
k...@seifried.org
users to find.
>
>
>
> Given how extensively DNS names are used, it seems reasonable for
> including this entry as a variant.
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
>
>
> *From:* Kurt Seifried
> *Sent:* Monday, January 24, 2022 11:50 AM
>
rworld.com/article/2529045/missing-dot-drops-sweden-off-the-internet.html
And various projects having issues with this spanning many years:
https://bugs.python.org/issue31997
https://github.com/openssl/openssl/issues/11560
--
Kurt Seifried (He/Him)
k...@seifried.org
g problem where they renamed some variables but
the "meaning" is still the same.
--
Kurt Seifried (He/Him)
k...@seifried.org
n this list. Is it time
> to deprecate these two entries outright? Are there any legitimate cases
> where password aging still makes sense (even from a practical standpoint)?
> Or maybe keep CWE-263 since it’s a followon weakness that occurs because of
> that bad choice?
>
>
a change if there is evidence of compromise of the
authenticator.
And ideally, we should rewrite BOTH of these CWE's to state "these are
retired/wrong"
--
Kurt Seifried (He/Him)
k...@seifried.org
design) – the
> behavior/mistake is still the same, regardless of the phase of the SDLC in
> which it occurs or who introduced the mistake.
>
Also in the system, the number of docker containers that run everything as
root now... sigh.
>
>
> - Steve
>
>
>
>
&g
be secure, we reveal that in the
> interoperable world of OpenPGP, unforeseen cross-configuration
> attacks become possible. Concretely, we propose different such
> attacks and show their practical efficacy by recovering plaintexts
> and even secret keys.
>
--
Kurt Seifried (He/Him)
k...@seifried.org
25 matches
Mail list logo
