From aeedf6d2f2cc040cdc3428d14e72a88007cf3d24 Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 16:54:51 -0500 Subject: [PATCH 01/15] Add CVEs --- CVE-2012-6657.yml | 477 +++++++++++++++++++++++++++++++++++++++++++++ CVE-2019-15216.yml | 477 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 954 insertions(+) create mode 100644 CVE-2012-6657.yml create mode 100644 CVE-2019-15216.yml diff --git a/CVE-2012-6657.yml b/CVE-2012-6657.yml new file mode 100644 index 000000000..7585d19a1 --- /dev/null +++ b/CVE-2012-6657.yml @@ -0,0 +1,477 @@ +CVE: CVE-2012-6657 +yaml_instructions: | + ================= + ===YAML Primer=== + ================= + This is a dictionary data structure, akin to JSON. + Everything before a colon is a key, and the values here are usually strings + For one-line strings, you can just use quotes after the colon + For multi-line strings, as we do for our instructions, you put a | and then + indent by two spaces + + For readability, we hard-wrap multi-line strings at 80 characters. This is + not required, but appreciated. +curated_instructions: | + If you are manually editing this file, then you are "curating" it. + + Set the version number that you were given in your instructions. + + This will enable additional editorial checks on this file to make sure you + fill everything out properly. If you are a student, we cannot accept your work + as finished unless curated is properly updated. +curation_level: 0 +reported_instructions: | + What date was the vulnerability reported to the security team? Look at the + security bulletins and bug reports. It is not necessarily the same day that + the CVE was created. Leave blank if no date is given. + + Please enter your date in YYYY-MM-DD format. +reported_date: +announced_instructions: | + Was there a date that this vulnerability was announced to the world? You can + find this in changelogs, blogs, bug reports, or perhaps the CVE date. + + This is not the same as published date in the NVD - that is below. + + Please enter your date in YYYY-MM-DD format. +announced_date: '2014-09-28' +published_instructions: | + Is there a published fix or patch date for this vulnerability? + Please enter your date in YYYY-MM-DD format. +published_date: '2014-09-28' +description_instructions: | + You can get an initial description from the CVE entry on cve.mitre.org. These + descriptions are a fine start, but they can be kind of jargony. + + Rewrite this description IN YOUR OWN WORDS. Make it interesting and easy to + read to anyone with some programming experience. We can always pull up the NVD + description later to get more technical. + + Try to still be specific in your description, but remove project-specific + stuff. Remove references to versions, specific filenames, and other jargon + that outsiders to this project would not understand. Technology like "regular + expressions" is fine, and security phrases like "invalid write" are fine to + keep too. + + Your target audience is people just like you before you took any course in + security +description: +bounty_instructions: | + If you came across any indications that a bounty was paid out for this + vulnerability, fill it out here. Or correct it if the information already here + was wrong. Otherwise, leave it blank. +bounty: + amt: + announced: + url: +reviews: [] +bugs_instructions: | + What bugs are involved in this vulnerability? + + Please list bug IDs to https://bugzilla.kernel.org/ + + Bug ID's can appear in several places: + * Mentioned in commit messages + * Mentioned in mailing list discussions + * References from NVD entry + * Various other places +bugs: [] +fixes_instructions: | + Please put the commit hash in "commit" below. + + This must be a git commit hash from the systemd source repo, a 40-character + hexademical string/ + + Place any notes you would like to make in the notes field. +fixes: +- commit: + note: +- commit: + note: +- commit: 3e10986d1d698140747fcfc2761ec9cb64c1d582 + note: | + Taken from NVD references list with Git commit. If you are + curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' +vcc_instructions: | + The vulnerability-contributing commits. + + These are found by our tools by traversing the Git Blame history, where we + determine which commit(s) introduced the functionality. + + Look up these VCC commits and verify that they are not simple refactorings, + and that they are, in fact introducing the vulnerability into the system. + Often, introducing the file or function is where the VCC is, but VCCs can be + anything. + + Place any notes you would like to make in the notes field. +vccs: +- commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 + note: Discovered automatically by archeogit. +upvotes_instructions: | + For the first round, ignore this upvotes number. + + For the second round of reviewing, you will be giving a certain amount of + upvotes to each vulnerability you see. Your peers will tell you how + interesting they think this vulnerability is, and you'll add that to the + upvotes score on your branch. +upvotes: +unit_tested: + question: | + Were automated unit tests involved in this vulnerability? + Was the original code unit tested, or not unit tested? Did the fix involve + improving the automated tests? + + For code: and fix: - your answer should be boolean. + + For the code_answer below, look not only at the fix but the surrounding + code near the fix in related directories and determine if and was there were + unit tests involved for this subsystem. + + For the fix_answer below, check if the fix for the vulnerability involves + adding or improving an automated test to ensure this doesn't happen again. + code: + code_answer: + fix: + fix_answer: +discovered: + question: | + How was this vulnerability discovered? + + Go to the bug report and read the conversation to find out how this was + originally found. Answer in longform below in "answer", fill in the date in + YYYY-MM-DD, and then determine if the vulnerability was found by a Google + employee (you can tell from their email address). If it's clear that the + vulenrability was discovered by a contest, fill in the name there. + + The automated, contest, and developer flags can be true, false, or nil. + + If there is no evidence as to how this vulnerability was found, then please + explain where you looked. + answer: + automated: + contest: + developer: +autodiscoverable: + instructions: | + Is it plausible that a fully automated tool could have discovered + this? These are tools that require little knowledge of the domain, + e.g. automatic static analysis, compiler warnings, fuzzers. + + Examples for true answers: SQL injection, XSS, buffer overflow + + In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. + + Examples for false: RFC violations, permissions issues, anything + that requires the tool to be "aware" of the project's + domain-specific requirements. + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. + note: + answer: +specification: + instructions: | + Is there mention of a violation of a specification? For example, the POSIX + spec, an RFC spec, a network protocol spec, or some other requirements + specification. + + Be sure to check the following artifacts for this: + * bug reports + * security advisories + * commit message + * mailing lists + * anything else + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. + note: + answer: +subsystem: + question: | + What subsystems was the mistake in? These are WITHIN linux kernel + + Determining the subsystem is a subjective task. This is to help us group + similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y + + Some areas to look for pertinent information: + - Bug labels + - Directory names + - How developers refer to an area of the system in comments, + commit messages, etc. + + Look at the path of the source code files code that were fixed to get + directory names. Look at comments in the code. Look at the bug reports how + the bug report was tagged. + + Example linux kernel subsystems are: + * drivers + * crypto + * fs + * net + * lib + + Name should be: + * all lowercase English letters + * NOT a specific file + * can have digits, and _-@/ + + Can be multiple subsystems involved, in which case you can make it an array + e.g. + name: ["subsystemA", "subsystemB"] # ok + name: subsystemA # also ok + name: + note: +interesting_commits: + question: | + Are there any interesting commits between your VCC(s) and fix(es)? + + Use this to specify any commits you think are notable in some way, and + explain why in the note. + + Example interesting commits: + * Mentioned as a problematic commit in the past + e.g. "This fixes regression in commit xys" + * A significant rewrite in the git history + * Other commits that fixed a similar issue as this vulnerability + * Anything else you find interesting. + commits: + - commit: + note: + - commit: + note: +i18n: + question: | + Was the feature impacted by this vulnerability about internationalization + (i18n)? + + An internationalization feature is one that enables people from all + over the world to use the system. This includes translations, locales, + typography, unicode, or various other features. + + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: + note: +sandbox: + question: | + Did this vulnerability violate a sandboxing feature that the system + provides? + + A sandboxing feature is one that allows files, users, or other features + limited access. Vulnerabilities that violate sandboxes are usually based on + access control, checking privileges incorrectly, path traversal, and the + like. + + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: + note: +ipc: + question: | + Did the feature that this vulnerability affected use inter-process + communication? IPC includes OS signals, pipes, stdin/stdout, message + passing, and clipboard. Writing to files that another program in this + software system reads is another form of IPC. + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: + note: +discussion: + question: | + Was there any discussion surrounding this? + + A discussion can include debates, disputes, or polite talk about how to + resolve uncertainty. + + Example include: + * Is this out of our scope? + * Is this a security? + * How should we fix this? + + Just because you see multiple comments doesn't mean it's a discussion. + For example: + * "Fix line 10". "Ok" is not what we call a discussion + * "Ping" (reminding people) + + Check the bugs reports, pull requests, and mailing lists archives. + + These answers should be boolean. + discussed_as_security: true or false + any_discussion: true or false + + Put any links to disagreements you found in the notes section, or any other + comment you want to make. + discussed_as_security: + any_discussion: + note: +vouch: + question: | + Was there any part of the fix that involved one person vouching for + another's work? + + This can include: + * signing off on a commit message + * mentioning a discussion with a colleague checking the work + * upvoting a solution on a pull request + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of what your answer was. + answer: + note: +stacktrace: + question: | + Are there any stacktraces in the bug reports? + + Secondly, if there is a stacktrace, is the fix in the same file that the + stacktrace points to? + + If there are no stacktraces, then both of these are false - but be sure to + mention where you checked in the note. + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + any_stacktraces: + stacktrace_with_fix: + note: +forgotten_check: + question: | + Does the fix for the vulnerability involve adding a forgotten check? + + A "forgotten check" can mean many things. It often manifests as the fix + inserting an entire if-statement or a conditional to an existing + if-statement. Or a call to a method that checks something. + + Example of checks can include: + * null pointer checks + * check the current role, e.g. root + * boundary checks for a number + * consult file permissions + * check a return value + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: + note: +order_of_operations: + question: | + Does the fix for the vulnerability involve correcting an order of + operations? + + This means the fix involves moving code around or changing the order of + how things are done. + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: + note: +lessons: + question: | + Are there any common lessons we have learned from class that apply to this + vulnerability? In other words, could this vulnerability serve as an example + of one of those lessons? + + Leave "applies" blank or put false if you did not see that lesson (you do + not need to put a reason). Put "true" if you feel the lesson applies and put + a quick explanation of how it applies. + + Don't feel the need to claim that ALL of these apply, but it's pretty likely + that one or two of them apply. + + If you think of another lesson we covered in class that applies here, feel + free to give it a small name and add one in the same format as these. + defense_in_depth: + applies: + note: + least_privilege: + applies: + note: + frameworks_are_optional: + applies: + note: + native_wrappers: + applies: + note: + distrust_input: + applies: + note: + security_by_obscurity: + applies: + note: + serial_killer: + applies: + note: + environment_variables: + applies: + note: + secure_by_default: + applies: + note: + yagni: + applies: + note: + complex_inputs: + applies: + note: +mistakes: + question: | + In your opinion, after all of this research, what mistakes were made that + led to this vulnerability? Coding mistakes? Design mistakes? + Maintainability? Requirements? Miscommunications? + + There can, and usually are, many mistakes behind a vulnerability. + + Remember that mistakes can come in many forms: + * slip: failing to complete a properly planned step due to inattention + e.g. wrong key in the ignition + e.g. using < instead of <= + * lapse: failing to complete a properly planned step due to memory failure + e.g. forgetting to put car in reverse before backing up + e.g. forgetting to check null + * planning error: error that occurs when the plan is inadequate + e.g. getting stuck in traffic because you didn't consider the + impact of the bridge closing + e.g. calling the wrong method + e.g. using a poor design + + These are grey areas, of course. But do your best to analyze the mistakes + according to this framework. + + Look at the CWE entry for this vulnerability and examine the mitigations + they have written there. Are they doing those? Does the fix look proper? + + Write a thoughtful entry here that people in the software engineering + industry would find interesting. + answer: +CWE_instructions: | + Please go to http://cwe.mitre.org and find the most specific, appropriate CWE + entry that describes your vulnerability. We recommend going to + https://cwe.mitre.org/data/definitions/699.html for the Software Development + view of the vulnerabilities. We also recommend the tool + http://www.cwevis.org/viz to help see how the classifications work. + + If you have anything to note about why you classified it this way, write + something in CWE_note. This field is optional. + + Just the number here is fine. No need for name or CWE prefix. If more than one + apply here, then place them in an array like this + CWE: ["123", "456"] # this is ok + CWE: [123, 456] # also ok + CWE: 123 # also ok +CWE: +- 264 +CWE_note: | + CWE as registered in the NVD. If you are curating, check that this + is correct and replace this comment with "Manually confirmed". +nickname_instructions: | + A catchy name for this vulnerability that would draw attention it. + If the report mentions a nickname, use that. + Must be under 30 characters. Optional. +nickname: +CVSS: diff --git a/CVE-2019-15216.yml b/CVE-2019-15216.yml new file mode 100644 index 000000000..5d6a54eb8 --- /dev/null +++ b/CVE-2019-15216.yml @@ -0,0 +1,477 @@ +CVE: CVE-2019-15216 +yaml_instructions: | + ================= + ===YAML Primer=== + ================= + This is a dictionary data structure, akin to JSON. + Everything before a colon is a key, and the values here are usually strings + For one-line strings, you can just use quotes after the colon + For multi-line strings, as we do for our instructions, you put a | and then + indent by two spaces + + For readability, we hard-wrap multi-line strings at 80 characters. This is + not required, but appreciated. +curated_instructions: | + If you are manually editing this file, then you are "curating" it. + + Set the version number that you were given in your instructions. + + This will enable additional editorial checks on this file to make sure you + fill everything out properly. If you are a student, we cannot accept your work + as finished unless curated is properly updated. +curation_level: 0 +reported_instructions: | + What date was the vulnerability reported to the security team? Look at the + security bulletins and bug reports. It is not necessarily the same day that + the CVE was created. Leave blank if no date is given. + + Please enter your date in YYYY-MM-DD format. +reported_date: +announced_instructions: | + Was there a date that this vulnerability was announced to the world? You can + find this in changelogs, blogs, bug reports, or perhaps the CVE date. + + This is not the same as published date in the NVD - that is below. + + Please enter your date in YYYY-MM-DD format. +announced_date: '2019-08-19' +published_instructions: | + Is there a published fix or patch date for this vulnerability? + Please enter your date in YYYY-MM-DD format. +published_date: '2019-08-19' +description_instructions: | + You can get an initial description from the CVE entry on cve.mitre.org. These + descriptions are a fine start, but they can be kind of jargony. + + Rewrite this description IN YOUR OWN WORDS. Make it interesting and easy to + read to anyone with some programming experience. We can always pull up the NVD + description later to get more technical. + + Try to still be specific in your description, but remove project-specific + stuff. Remove references to versions, specific filenames, and other jargon + that outsiders to this project would not understand. Technology like "regular + expressions" is fine, and security phrases like "invalid write" are fine to + keep too. + + Your target audience is people just like you before you took any course in + security +description: +bounty_instructions: | + If you came across any indications that a bounty was paid out for this + vulnerability, fill it out here. Or correct it if the information already here + was wrong. Otherwise, leave it blank. +bounty: + amt: + announced: + url: +reviews: [] +bugs_instructions: | + What bugs are involved in this vulnerability? + + Please list bug IDs to https://bugzilla.kernel.org/ + + Bug ID's can appear in several places: + * Mentioned in commit messages + * Mentioned in mailing list discussions + * References from NVD entry + * Various other places +bugs: [] +fixes_instructions: | + Please put the commit hash in "commit" below. + + This must be a git commit hash from the systemd source repo, a 40-character + hexademical string/ + + Place any notes you would like to make in the notes field. +fixes: +- commit: + note: +- commit: + note: +- commit: ef61eb43ada6c1d6b94668f0f514e4c268093ff3 + note: | + Taken from NVD references list with Git commit. If you are + curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' +vcc_instructions: | + The vulnerability-contributing commits. + + These are found by our tools by traversing the Git Blame history, where we + determine which commit(s) introduced the functionality. + + Look up these VCC commits and verify that they are not simple refactorings, + and that they are, in fact introducing the vulnerability into the system. + Often, introducing the file or function is where the VCC is, but VCCs can be + anything. + + Place any notes you would like to make in the notes field. +vccs: +- commit: 6bc235a2e24a5ef677daee3fd4f74f6cd643e23c + note: Discovered automatically by archeogit. +upvotes_instructions: | + For the first round, ignore this upvotes number. + + For the second round of reviewing, you will be giving a certain amount of + upvotes to each vulnerability you see. Your peers will tell you how + interesting they think this vulnerability is, and you'll add that to the + upvotes score on your branch. +upvotes: +unit_tested: + question: | + Were automated unit tests involved in this vulnerability? + Was the original code unit tested, or not unit tested? Did the fix involve + improving the automated tests? + + For code: and fix: - your answer should be boolean. + + For the code_answer below, look not only at the fix but the surrounding + code near the fix in related directories and determine if and was there were + unit tests involved for this subsystem. + + For the fix_answer below, check if the fix for the vulnerability involves + adding or improving an automated test to ensure this doesn't happen again. + code: + code_answer: + fix: + fix_answer: +discovered: + question: | + How was this vulnerability discovered? + + Go to the bug report and read the conversation to find out how this was + originally found. Answer in longform below in "answer", fill in the date in + YYYY-MM-DD, and then determine if the vulnerability was found by a Google + employee (you can tell from their email address). If it's clear that the + vulenrability was discovered by a contest, fill in the name there. + + The automated, contest, and developer flags can be true, false, or nil. + + If there is no evidence as to how this vulnerability was found, then please + explain where you looked. + answer: + automated: + contest: + developer: +autodiscoverable: + instructions: | + Is it plausible that a fully automated tool could have discovered + this? These are tools that require little knowledge of the domain, + e.g. automatic static analysis, compiler warnings, fuzzers. + + Examples for true answers: SQL injection, XSS, buffer overflow + + In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. + + Examples for false: RFC violations, permissions issues, anything + that requires the tool to be "aware" of the project's + domain-specific requirements. + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. + note: + answer: +specification: + instructions: | + Is there mention of a violation of a specification? For example, the POSIX + spec, an RFC spec, a network protocol spec, or some other requirements + specification. + + Be sure to check the following artifacts for this: + * bug reports + * security advisories + * commit message + * mailing lists + * anything else + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. + note: + answer: +subsystem: + question: | + What subsystems was the mistake in? These are WITHIN linux kernel + + Determining the subsystem is a subjective task. This is to help us group + similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y + + Some areas to look for pertinent information: + - Bug labels + - Directory names + - How developers refer to an area of the system in comments, + commit messages, etc. + + Look at the path of the source code files code that were fixed to get + directory names. Look at comments in the code. Look at the bug reports how + the bug report was tagged. + + Example linux kernel subsystems are: + * drivers + * crypto + * fs + * net + * lib + + Name should be: + * all lowercase English letters + * NOT a specific file + * can have digits, and _-@/ + + Can be multiple subsystems involved, in which case you can make it an array + e.g. + name: ["subsystemA", "subsystemB"] # ok + name: subsystemA # also ok + name: + note: +interesting_commits: + question: | + Are there any interesting commits between your VCC(s) and fix(es)? + + Use this to specify any commits you think are notable in some way, and + explain why in the note. + + Example interesting commits: + * Mentioned as a problematic commit in the past + e.g. "This fixes regression in commit xys" + * A significant rewrite in the git history + * Other commits that fixed a similar issue as this vulnerability + * Anything else you find interesting. + commits: + - commit: + note: + - commit: + note: +i18n: + question: | + Was the feature impacted by this vulnerability about internationalization + (i18n)? + + An internationalization feature is one that enables people from all + over the world to use the system. This includes translations, locales, + typography, unicode, or various other features. + + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: + note: +sandbox: + question: | + Did this vulnerability violate a sandboxing feature that the system + provides? + + A sandboxing feature is one that allows files, users, or other features + limited access. Vulnerabilities that violate sandboxes are usually based on + access control, checking privileges incorrectly, path traversal, and the + like. + + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: + note: +ipc: + question: | + Did the feature that this vulnerability affected use inter-process + communication? IPC includes OS signals, pipes, stdin/stdout, message + passing, and clipboard. Writing to files that another program in this + software system reads is another form of IPC. + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: + note: +discussion: + question: | + Was there any discussion surrounding this? + + A discussion can include debates, disputes, or polite talk about how to + resolve uncertainty. + + Example include: + * Is this out of our scope? + * Is this a security? + * How should we fix this? + + Just because you see multiple comments doesn't mean it's a discussion. + For example: + * "Fix line 10". "Ok" is not what we call a discussion + * "Ping" (reminding people) + + Check the bugs reports, pull requests, and mailing lists archives. + + These answers should be boolean. + discussed_as_security: true or false + any_discussion: true or false + + Put any links to disagreements you found in the notes section, or any other + comment you want to make. + discussed_as_security: + any_discussion: + note: +vouch: + question: | + Was there any part of the fix that involved one person vouching for + another's work? + + This can include: + * signing off on a commit message + * mentioning a discussion with a colleague checking the work + * upvoting a solution on a pull request + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of what your answer was. + answer: + note: +stacktrace: + question: | + Are there any stacktraces in the bug reports? + + Secondly, if there is a stacktrace, is the fix in the same file that the + stacktrace points to? + + If there are no stacktraces, then both of these are false - but be sure to + mention where you checked in the note. + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + any_stacktraces: + stacktrace_with_fix: + note: +forgotten_check: + question: | + Does the fix for the vulnerability involve adding a forgotten check? + + A "forgotten check" can mean many things. It often manifests as the fix + inserting an entire if-statement or a conditional to an existing + if-statement. Or a call to a method that checks something. + + Example of checks can include: + * null pointer checks + * check the current role, e.g. root + * boundary checks for a number + * consult file permissions + * check a return value + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: + note: +order_of_operations: + question: | + Does the fix for the vulnerability involve correcting an order of + operations? + + This means the fix involves moving code around or changing the order of + how things are done. + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: + note: +lessons: + question: | + Are there any common lessons we have learned from class that apply to this + vulnerability? In other words, could this vulnerability serve as an example + of one of those lessons? + + Leave "applies" blank or put false if you did not see that lesson (you do + not need to put a reason). Put "true" if you feel the lesson applies and put + a quick explanation of how it applies. + + Don't feel the need to claim that ALL of these apply, but it's pretty likely + that one or two of them apply. + + If you think of another lesson we covered in class that applies here, feel + free to give it a small name and add one in the same format as these. + defense_in_depth: + applies: + note: + least_privilege: + applies: + note: + frameworks_are_optional: + applies: + note: + native_wrappers: + applies: + note: + distrust_input: + applies: + note: + security_by_obscurity: + applies: + note: + serial_killer: + applies: + note: + environment_variables: + applies: + note: + secure_by_default: + applies: + note: + yagni: + applies: + note: + complex_inputs: + applies: + note: +mistakes: + question: | + In your opinion, after all of this research, what mistakes were made that + led to this vulnerability? Coding mistakes? Design mistakes? + Maintainability? Requirements? Miscommunications? + + There can, and usually are, many mistakes behind a vulnerability. + + Remember that mistakes can come in many forms: + * slip: failing to complete a properly planned step due to inattention + e.g. wrong key in the ignition + e.g. using < instead of <= + * lapse: failing to complete a properly planned step due to memory failure + e.g. forgetting to put car in reverse before backing up + e.g. forgetting to check null + * planning error: error that occurs when the plan is inadequate + e.g. getting stuck in traffic because you didn't consider the + impact of the bridge closing + e.g. calling the wrong method + e.g. using a poor design + + These are grey areas, of course. But do your best to analyze the mistakes + according to this framework. + + Look at the CWE entry for this vulnerability and examine the mitigations + they have written there. Are they doing those? Does the fix look proper? + + Write a thoughtful entry here that people in the software engineering + industry would find interesting. + answer: +CWE_instructions: | + Please go to http://cwe.mitre.org and find the most specific, appropriate CWE + entry that describes your vulnerability. We recommend going to + https://cwe.mitre.org/data/definitions/699.html for the Software Development + view of the vulnerabilities. We also recommend the tool + http://www.cwevis.org/viz to help see how the classifications work. + + If you have anything to note about why you classified it this way, write + something in CWE_note. This field is optional. + + Just the number here is fine. No need for name or CWE prefix. If more than one + apply here, then place them in an array like this + CWE: ["123", "456"] # this is ok + CWE: [123, 456] # also ok + CWE: 123 # also ok +CWE: +- 476 +CWE_note: | + CWE as registered in the NVD. If you are curating, check that this + is correct and replace this comment with "Manually confirmed". +nickname_instructions: | + A catchy name for this vulnerability that would draw attention it. + If the report mentions a nickname, use that. + Must be under 30 characters. Optional. +nickname: +CVSS: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H From 5fff135c8117e4c84238d874f68ad3bf4a85b9f3 Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 16:55:27 -0500 Subject: [PATCH 02/15] Changed curation level to 2 --- CVE-2012-6657.yml | 2 +- CVE-2019-15216.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/CVE-2012-6657.yml b/CVE-2012-6657.yml index 7585d19a1..9410b587a 100644 --- a/CVE-2012-6657.yml +++ b/CVE-2012-6657.yml @@ -19,7 +19,7 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that diff --git a/CVE-2019-15216.yml b/CVE-2019-15216.yml index 5d6a54eb8..60342f17d 100644 --- a/CVE-2019-15216.yml +++ b/CVE-2019-15216.yml @@ -19,7 +19,7 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that From d82714efe0582ee0b518421fb84e22347e7b6faa Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 17:43:57 -0500 Subject: [PATCH 03/15] Removed files --- CVE-2012-6657.yml | 477 --------------------------------------------- CVE-2019-15216.yml | 477 --------------------------------------------- 2 files changed, 954 deletions(-) delete mode 100644 CVE-2012-6657.yml delete mode 100644 CVE-2019-15216.yml diff --git a/CVE-2012-6657.yml b/CVE-2012-6657.yml deleted file mode 100644 index 9410b587a..000000000 --- a/CVE-2012-6657.yml +++ /dev/null @@ -1,477 +0,0 @@ -CVE: CVE-2012-6657 -yaml_instructions: | - ================= - ===YAML Primer=== - ================= - This is a dictionary data structure, akin to JSON. - Everything before a colon is a key, and the values here are usually strings - For one-line strings, you can just use quotes after the colon - For multi-line strings, as we do for our instructions, you put a | and then - indent by two spaces - - For readability, we hard-wrap multi-line strings at 80 characters. This is - not required, but appreciated. -curated_instructions: | - If you are manually editing this file, then you are "curating" it. - - Set the version number that you were given in your instructions. - - This will enable additional editorial checks on this file to make sure you - fill everything out properly. If you are a student, we cannot accept your work - as finished unless curated is properly updated. -curation_level: 2 -reported_instructions: | - What date was the vulnerability reported to the security team? Look at the - security bulletins and bug reports. It is not necessarily the same day that - the CVE was created. Leave blank if no date is given. - - Please enter your date in YYYY-MM-DD format. -reported_date: -announced_instructions: | - Was there a date that this vulnerability was announced to the world? You can - find this in changelogs, blogs, bug reports, or perhaps the CVE date. - - This is not the same as published date in the NVD - that is below. - - Please enter your date in YYYY-MM-DD format. -announced_date: '2014-09-28' -published_instructions: | - Is there a published fix or patch date for this vulnerability? - Please enter your date in YYYY-MM-DD format. -published_date: '2014-09-28' -description_instructions: | - You can get an initial description from the CVE entry on cve.mitre.org. These - descriptions are a fine start, but they can be kind of jargony. - - Rewrite this description IN YOUR OWN WORDS. Make it interesting and easy to - read to anyone with some programming experience. We can always pull up the NVD - description later to get more technical. - - Try to still be specific in your description, but remove project-specific - stuff. Remove references to versions, specific filenames, and other jargon - that outsiders to this project would not understand. Technology like "regular - expressions" is fine, and security phrases like "invalid write" are fine to - keep too. - - Your target audience is people just like you before you took any course in - security -description: -bounty_instructions: | - If you came across any indications that a bounty was paid out for this - vulnerability, fill it out here. Or correct it if the information already here - was wrong. Otherwise, leave it blank. -bounty: - amt: - announced: - url: -reviews: [] -bugs_instructions: | - What bugs are involved in this vulnerability? - - Please list bug IDs to https://bugzilla.kernel.org/ - - Bug ID's can appear in several places: - * Mentioned in commit messages - * Mentioned in mailing list discussions - * References from NVD entry - * Various other places -bugs: [] -fixes_instructions: | - Please put the commit hash in "commit" below. - - This must be a git commit hash from the systemd source repo, a 40-character - hexademical string/ - - Place any notes you would like to make in the notes field. -fixes: -- commit: - note: -- commit: - note: -- commit: 3e10986d1d698140747fcfc2761ec9cb64c1d582 - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' -vcc_instructions: | - The vulnerability-contributing commits. - - These are found by our tools by traversing the Git Blame history, where we - determine which commit(s) introduced the functionality. - - Look up these VCC commits and verify that they are not simple refactorings, - and that they are, in fact introducing the vulnerability into the system. - Often, introducing the file or function is where the VCC is, but VCCs can be - anything. - - Place any notes you would like to make in the notes field. -vccs: -- commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 - note: Discovered automatically by archeogit. -upvotes_instructions: | - For the first round, ignore this upvotes number. - - For the second round of reviewing, you will be giving a certain amount of - upvotes to each vulnerability you see. Your peers will tell you how - interesting they think this vulnerability is, and you'll add that to the - upvotes score on your branch. -upvotes: -unit_tested: - question: | - Were automated unit tests involved in this vulnerability? - Was the original code unit tested, or not unit tested? Did the fix involve - improving the automated tests? - - For code: and fix: - your answer should be boolean. - - For the code_answer below, look not only at the fix but the surrounding - code near the fix in related directories and determine if and was there were - unit tests involved for this subsystem. - - For the fix_answer below, check if the fix for the vulnerability involves - adding or improving an automated test to ensure this doesn't happen again. - code: - code_answer: - fix: - fix_answer: -discovered: - question: | - How was this vulnerability discovered? - - Go to the bug report and read the conversation to find out how this was - originally found. Answer in longform below in "answer", fill in the date in - YYYY-MM-DD, and then determine if the vulnerability was found by a Google - employee (you can tell from their email address). If it's clear that the - vulenrability was discovered by a contest, fill in the name there. - - The automated, contest, and developer flags can be true, false, or nil. - - If there is no evidence as to how this vulnerability was found, then please - explain where you looked. - answer: - automated: - contest: - developer: -autodiscoverable: - instructions: | - Is it plausible that a fully automated tool could have discovered - this? These are tools that require little knowledge of the domain, - e.g. automatic static analysis, compiler warnings, fuzzers. - - Examples for true answers: SQL injection, XSS, buffer overflow - - In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. - - Examples for false: RFC violations, permissions issues, anything - that requires the tool to be "aware" of the project's - domain-specific requirements. - - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: - answer: -specification: - instructions: | - Is there mention of a violation of a specification? For example, the POSIX - spec, an RFC spec, a network protocol spec, or some other requirements - specification. - - Be sure to check the following artifacts for this: - * bug reports - * security advisories - * commit message - * mailing lists - * anything else - - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: - answer: -subsystem: - question: | - What subsystems was the mistake in? These are WITHIN linux kernel - - Determining the subsystem is a subjective task. This is to help us group - similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y - - Some areas to look for pertinent information: - - Bug labels - - Directory names - - How developers refer to an area of the system in comments, - commit messages, etc. - - Look at the path of the source code files code that were fixed to get - directory names. Look at comments in the code. Look at the bug reports how - the bug report was tagged. - - Example linux kernel subsystems are: - * drivers - * crypto - * fs - * net - * lib - - Name should be: - * all lowercase English letters - * NOT a specific file - * can have digits, and _-@/ - - Can be multiple subsystems involved, in which case you can make it an array - e.g. - name: ["subsystemA", "subsystemB"] # ok - name: subsystemA # also ok - name: - note: -interesting_commits: - question: | - Are there any interesting commits between your VCC(s) and fix(es)? - - Use this to specify any commits you think are notable in some way, and - explain why in the note. - - Example interesting commits: - * Mentioned as a problematic commit in the past - e.g. "This fixes regression in commit xys" - * A significant rewrite in the git history - * Other commits that fixed a similar issue as this vulnerability - * Anything else you find interesting. - commits: - - commit: - note: - - commit: - note: -i18n: - question: | - Was the feature impacted by this vulnerability about internationalization - (i18n)? - - An internationalization feature is one that enables people from all - over the world to use the system. This includes translations, locales, - typography, unicode, or various other features. - - Answer should be true or false - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - answer: - note: -sandbox: - question: | - Did this vulnerability violate a sandboxing feature that the system - provides? - - A sandboxing feature is one that allows files, users, or other features - limited access. Vulnerabilities that violate sandboxes are usually based on - access control, checking privileges incorrectly, path traversal, and the - like. - - Answer should be true or false - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - answer: - note: -ipc: - question: | - Did the feature that this vulnerability affected use inter-process - communication? IPC includes OS signals, pipes, stdin/stdout, message - passing, and clipboard. Writing to files that another program in this - software system reads is another form of IPC. - - Answer must be true or false. - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - answer: - note: -discussion: - question: | - Was there any discussion surrounding this? - - A discussion can include debates, disputes, or polite talk about how to - resolve uncertainty. - - Example include: - * Is this out of our scope? - * Is this a security? - * How should we fix this? - - Just because you see multiple comments doesn't mean it's a discussion. - For example: - * "Fix line 10". "Ok" is not what we call a discussion - * "Ping" (reminding people) - - Check the bugs reports, pull requests, and mailing lists archives. - - These answers should be boolean. - discussed_as_security: true or false - any_discussion: true or false - - Put any links to disagreements you found in the notes section, or any other - comment you want to make. - discussed_as_security: - any_discussion: - note: -vouch: - question: | - Was there any part of the fix that involved one person vouching for - another's work? - - This can include: - * signing off on a commit message - * mentioning a discussion with a colleague checking the work - * upvoting a solution on a pull request - - Answer must be true or false. - Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: -stacktrace: - question: | - Are there any stacktraces in the bug reports? - - Secondly, if there is a stacktrace, is the fix in the same file that the - stacktrace points to? - - If there are no stacktraces, then both of these are false - but be sure to - mention where you checked in the note. - - Answer must be true or false. - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - any_stacktraces: - stacktrace_with_fix: - note: -forgotten_check: - question: | - Does the fix for the vulnerability involve adding a forgotten check? - - A "forgotten check" can mean many things. It often manifests as the fix - inserting an entire if-statement or a conditional to an existing - if-statement. Or a call to a method that checks something. - - Example of checks can include: - * null pointer checks - * check the current role, e.g. root - * boundary checks for a number - * consult file permissions - * check a return value - - Answer must be true or false. - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - answer: - note: -order_of_operations: - question: | - Does the fix for the vulnerability involve correcting an order of - operations? - - This means the fix involves moving code around or changing the order of - how things are done. - - Answer must be true or false. - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - answer: - note: -lessons: - question: | - Are there any common lessons we have learned from class that apply to this - vulnerability? In other words, could this vulnerability serve as an example - of one of those lessons? - - Leave "applies" blank or put false if you did not see that lesson (you do - not need to put a reason). Put "true" if you feel the lesson applies and put - a quick explanation of how it applies. - - Don't feel the need to claim that ALL of these apply, but it's pretty likely - that one or two of them apply. - - If you think of another lesson we covered in class that applies here, feel - free to give it a small name and add one in the same format as these. - defense_in_depth: - applies: - note: - least_privilege: - applies: - note: - frameworks_are_optional: - applies: - note: - native_wrappers: - applies: - note: - distrust_input: - applies: - note: - security_by_obscurity: - applies: - note: - serial_killer: - applies: - note: - environment_variables: - applies: - note: - secure_by_default: - applies: - note: - yagni: - applies: - note: - complex_inputs: - applies: - note: -mistakes: - question: | - In your opinion, after all of this research, what mistakes were made that - led to this vulnerability? Coding mistakes? Design mistakes? - Maintainability? Requirements? Miscommunications? - - There can, and usually are, many mistakes behind a vulnerability. - - Remember that mistakes can come in many forms: - * slip: failing to complete a properly planned step due to inattention - e.g. wrong key in the ignition - e.g. using < instead of <= - * lapse: failing to complete a properly planned step due to memory failure - e.g. forgetting to put car in reverse before backing up - e.g. forgetting to check null - * planning error: error that occurs when the plan is inadequate - e.g. getting stuck in traffic because you didn't consider the - impact of the bridge closing - e.g. calling the wrong method - e.g. using a poor design - - These are grey areas, of course. But do your best to analyze the mistakes - according to this framework. - - Look at the CWE entry for this vulnerability and examine the mitigations - they have written there. Are they doing those? Does the fix look proper? - - Write a thoughtful entry here that people in the software engineering - industry would find interesting. - answer: -CWE_instructions: | - Please go to http://cwe.mitre.org and find the most specific, appropriate CWE - entry that describes your vulnerability. We recommend going to - https://cwe.mitre.org/data/definitions/699.html for the Software Development - view of the vulnerabilities. We also recommend the tool - http://www.cwevis.org/viz to help see how the classifications work. - - If you have anything to note about why you classified it this way, write - something in CWE_note. This field is optional. - - Just the number here is fine. No need for name or CWE prefix. If more than one - apply here, then place them in an array like this - CWE: ["123", "456"] # this is ok - CWE: [123, 456] # also ok - CWE: 123 # also ok -CWE: -- 264 -CWE_note: | - CWE as registered in the NVD. If you are curating, check that this - is correct and replace this comment with "Manually confirmed". -nickname_instructions: | - A catchy name for this vulnerability that would draw attention it. - If the report mentions a nickname, use that. - Must be under 30 characters. Optional. -nickname: -CVSS: diff --git a/CVE-2019-15216.yml b/CVE-2019-15216.yml deleted file mode 100644 index 60342f17d..000000000 --- a/CVE-2019-15216.yml +++ /dev/null @@ -1,477 +0,0 @@ -CVE: CVE-2019-15216 -yaml_instructions: | - ================= - ===YAML Primer=== - ================= - This is a dictionary data structure, akin to JSON. - Everything before a colon is a key, and the values here are usually strings - For one-line strings, you can just use quotes after the colon - For multi-line strings, as we do for our instructions, you put a | and then - indent by two spaces - - For readability, we hard-wrap multi-line strings at 80 characters. This is - not required, but appreciated. -curated_instructions: | - If you are manually editing this file, then you are "curating" it. - - Set the version number that you were given in your instructions. - - This will enable additional editorial checks on this file to make sure you - fill everything out properly. If you are a student, we cannot accept your work - as finished unless curated is properly updated. -curation_level: 2 -reported_instructions: | - What date was the vulnerability reported to the security team? Look at the - security bulletins and bug reports. It is not necessarily the same day that - the CVE was created. Leave blank if no date is given. - - Please enter your date in YYYY-MM-DD format. -reported_date: -announced_instructions: | - Was there a date that this vulnerability was announced to the world? You can - find this in changelogs, blogs, bug reports, or perhaps the CVE date. - - This is not the same as published date in the NVD - that is below. - - Please enter your date in YYYY-MM-DD format. -announced_date: '2019-08-19' -published_instructions: | - Is there a published fix or patch date for this vulnerability? - Please enter your date in YYYY-MM-DD format. -published_date: '2019-08-19' -description_instructions: | - You can get an initial description from the CVE entry on cve.mitre.org. These - descriptions are a fine start, but they can be kind of jargony. - - Rewrite this description IN YOUR OWN WORDS. Make it interesting and easy to - read to anyone with some programming experience. We can always pull up the NVD - description later to get more technical. - - Try to still be specific in your description, but remove project-specific - stuff. Remove references to versions, specific filenames, and other jargon - that outsiders to this project would not understand. Technology like "regular - expressions" is fine, and security phrases like "invalid write" are fine to - keep too. - - Your target audience is people just like you before you took any course in - security -description: -bounty_instructions: | - If you came across any indications that a bounty was paid out for this - vulnerability, fill it out here. Or correct it if the information already here - was wrong. Otherwise, leave it blank. -bounty: - amt: - announced: - url: -reviews: [] -bugs_instructions: | - What bugs are involved in this vulnerability? - - Please list bug IDs to https://bugzilla.kernel.org/ - - Bug ID's can appear in several places: - * Mentioned in commit messages - * Mentioned in mailing list discussions - * References from NVD entry - * Various other places -bugs: [] -fixes_instructions: | - Please put the commit hash in "commit" below. - - This must be a git commit hash from the systemd source repo, a 40-character - hexademical string/ - - Place any notes you would like to make in the notes field. -fixes: -- commit: - note: -- commit: - note: -- commit: ef61eb43ada6c1d6b94668f0f514e4c268093ff3 - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' -vcc_instructions: | - The vulnerability-contributing commits. - - These are found by our tools by traversing the Git Blame history, where we - determine which commit(s) introduced the functionality. - - Look up these VCC commits and verify that they are not simple refactorings, - and that they are, in fact introducing the vulnerability into the system. - Often, introducing the file or function is where the VCC is, but VCCs can be - anything. - - Place any notes you would like to make in the notes field. -vccs: -- commit: 6bc235a2e24a5ef677daee3fd4f74f6cd643e23c - note: Discovered automatically by archeogit. -upvotes_instructions: | - For the first round, ignore this upvotes number. - - For the second round of reviewing, you will be giving a certain amount of - upvotes to each vulnerability you see. Your peers will tell you how - interesting they think this vulnerability is, and you'll add that to the - upvotes score on your branch. -upvotes: -unit_tested: - question: | - Were automated unit tests involved in this vulnerability? - Was the original code unit tested, or not unit tested? Did the fix involve - improving the automated tests? - - For code: and fix: - your answer should be boolean. - - For the code_answer below, look not only at the fix but the surrounding - code near the fix in related directories and determine if and was there were - unit tests involved for this subsystem. - - For the fix_answer below, check if the fix for the vulnerability involves - adding or improving an automated test to ensure this doesn't happen again. - code: - code_answer: - fix: - fix_answer: -discovered: - question: | - How was this vulnerability discovered? - - Go to the bug report and read the conversation to find out how this was - originally found. Answer in longform below in "answer", fill in the date in - YYYY-MM-DD, and then determine if the vulnerability was found by a Google - employee (you can tell from their email address). If it's clear that the - vulenrability was discovered by a contest, fill in the name there. - - The automated, contest, and developer flags can be true, false, or nil. - - If there is no evidence as to how this vulnerability was found, then please - explain where you looked. - answer: - automated: - contest: - developer: -autodiscoverable: - instructions: | - Is it plausible that a fully automated tool could have discovered - this? These are tools that require little knowledge of the domain, - e.g. automatic static analysis, compiler warnings, fuzzers. - - Examples for true answers: SQL injection, XSS, buffer overflow - - In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. - - Examples for false: RFC violations, permissions issues, anything - that requires the tool to be "aware" of the project's - domain-specific requirements. - - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: - answer: -specification: - instructions: | - Is there mention of a violation of a specification? For example, the POSIX - spec, an RFC spec, a network protocol spec, or some other requirements - specification. - - Be sure to check the following artifacts for this: - * bug reports - * security advisories - * commit message - * mailing lists - * anything else - - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: - answer: -subsystem: - question: | - What subsystems was the mistake in? These are WITHIN linux kernel - - Determining the subsystem is a subjective task. This is to help us group - similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y - - Some areas to look for pertinent information: - - Bug labels - - Directory names - - How developers refer to an area of the system in comments, - commit messages, etc. - - Look at the path of the source code files code that were fixed to get - directory names. Look at comments in the code. Look at the bug reports how - the bug report was tagged. - - Example linux kernel subsystems are: - * drivers - * crypto - * fs - * net - * lib - - Name should be: - * all lowercase English letters - * NOT a specific file - * can have digits, and _-@/ - - Can be multiple subsystems involved, in which case you can make it an array - e.g. - name: ["subsystemA", "subsystemB"] # ok - name: subsystemA # also ok - name: - note: -interesting_commits: - question: | - Are there any interesting commits between your VCC(s) and fix(es)? - - Use this to specify any commits you think are notable in some way, and - explain why in the note. - - Example interesting commits: - * Mentioned as a problematic commit in the past - e.g. "This fixes regression in commit xys" - * A significant rewrite in the git history - * Other commits that fixed a similar issue as this vulnerability - * Anything else you find interesting. - commits: - - commit: - note: - - commit: - note: -i18n: - question: | - Was the feature impacted by this vulnerability about internationalization - (i18n)? - - An internationalization feature is one that enables people from all - over the world to use the system. This includes translations, locales, - typography, unicode, or various other features. - - Answer should be true or false - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - answer: - note: -sandbox: - question: | - Did this vulnerability violate a sandboxing feature that the system - provides? - - A sandboxing feature is one that allows files, users, or other features - limited access. Vulnerabilities that violate sandboxes are usually based on - access control, checking privileges incorrectly, path traversal, and the - like. - - Answer should be true or false - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - answer: - note: -ipc: - question: | - Did the feature that this vulnerability affected use inter-process - communication? IPC includes OS signals, pipes, stdin/stdout, message - passing, and clipboard. Writing to files that another program in this - software system reads is another form of IPC. - - Answer must be true or false. - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - answer: - note: -discussion: - question: | - Was there any discussion surrounding this? - - A discussion can include debates, disputes, or polite talk about how to - resolve uncertainty. - - Example include: - * Is this out of our scope? - * Is this a security? - * How should we fix this? - - Just because you see multiple comments doesn't mean it's a discussion. - For example: - * "Fix line 10". "Ok" is not what we call a discussion - * "Ping" (reminding people) - - Check the bugs reports, pull requests, and mailing lists archives. - - These answers should be boolean. - discussed_as_security: true or false - any_discussion: true or false - - Put any links to disagreements you found in the notes section, or any other - comment you want to make. - discussed_as_security: - any_discussion: - note: -vouch: - question: | - Was there any part of the fix that involved one person vouching for - another's work? - - This can include: - * signing off on a commit message - * mentioning a discussion with a colleague checking the work - * upvoting a solution on a pull request - - Answer must be true or false. - Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: -stacktrace: - question: | - Are there any stacktraces in the bug reports? - - Secondly, if there is a stacktrace, is the fix in the same file that the - stacktrace points to? - - If there are no stacktraces, then both of these are false - but be sure to - mention where you checked in the note. - - Answer must be true or false. - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - any_stacktraces: - stacktrace_with_fix: - note: -forgotten_check: - question: | - Does the fix for the vulnerability involve adding a forgotten check? - - A "forgotten check" can mean many things. It often manifests as the fix - inserting an entire if-statement or a conditional to an existing - if-statement. Or a call to a method that checks something. - - Example of checks can include: - * null pointer checks - * check the current role, e.g. root - * boundary checks for a number - * consult file permissions - * check a return value - - Answer must be true or false. - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - answer: - note: -order_of_operations: - question: | - Does the fix for the vulnerability involve correcting an order of - operations? - - This means the fix involves moving code around or changing the order of - how things are done. - - Answer must be true or false. - Write a note about how you came to the conclusions you did, regardless of - what your answer was. - answer: - note: -lessons: - question: | - Are there any common lessons we have learned from class that apply to this - vulnerability? In other words, could this vulnerability serve as an example - of one of those lessons? - - Leave "applies" blank or put false if you did not see that lesson (you do - not need to put a reason). Put "true" if you feel the lesson applies and put - a quick explanation of how it applies. - - Don't feel the need to claim that ALL of these apply, but it's pretty likely - that one or two of them apply. - - If you think of another lesson we covered in class that applies here, feel - free to give it a small name and add one in the same format as these. - defense_in_depth: - applies: - note: - least_privilege: - applies: - note: - frameworks_are_optional: - applies: - note: - native_wrappers: - applies: - note: - distrust_input: - applies: - note: - security_by_obscurity: - applies: - note: - serial_killer: - applies: - note: - environment_variables: - applies: - note: - secure_by_default: - applies: - note: - yagni: - applies: - note: - complex_inputs: - applies: - note: -mistakes: - question: | - In your opinion, after all of this research, what mistakes were made that - led to this vulnerability? Coding mistakes? Design mistakes? - Maintainability? Requirements? Miscommunications? - - There can, and usually are, many mistakes behind a vulnerability. - - Remember that mistakes can come in many forms: - * slip: failing to complete a properly planned step due to inattention - e.g. wrong key in the ignition - e.g. using < instead of <= - * lapse: failing to complete a properly planned step due to memory failure - e.g. forgetting to put car in reverse before backing up - e.g. forgetting to check null - * planning error: error that occurs when the plan is inadequate - e.g. getting stuck in traffic because you didn't consider the - impact of the bridge closing - e.g. calling the wrong method - e.g. using a poor design - - These are grey areas, of course. But do your best to analyze the mistakes - according to this framework. - - Look at the CWE entry for this vulnerability and examine the mitigations - they have written there. Are they doing those? Does the fix look proper? - - Write a thoughtful entry here that people in the software engineering - industry would find interesting. - answer: -CWE_instructions: | - Please go to http://cwe.mitre.org and find the most specific, appropriate CWE - entry that describes your vulnerability. We recommend going to - https://cwe.mitre.org/data/definitions/699.html for the Software Development - view of the vulnerabilities. We also recommend the tool - http://www.cwevis.org/viz to help see how the classifications work. - - If you have anything to note about why you classified it this way, write - something in CWE_note. This field is optional. - - Just the number here is fine. No need for name or CWE prefix. If more than one - apply here, then place them in an array like this - CWE: ["123", "456"] # this is ok - CWE: [123, 456] # also ok - CWE: 123 # also ok -CWE: -- 476 -CWE_note: | - CWE as registered in the NVD. If you are curating, check that this - is correct and replace this comment with "Manually confirmed". -nickname_instructions: | - A catchy name for this vulnerability that would draw attention it. - If the report mentions a nickname, use that. - Must be under 30 characters. Optional. -nickname: -CVSS: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H From d83cc8d432120e3e996e51495d6f482b141549fb Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 17:44:24 -0500 Subject: [PATCH 04/15] Changed level to 2 --- cves/kernel/CVE-2012-6657.yml | 2 +- cves/kernel/CVE-2019-15216.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cves/kernel/CVE-2012-6657.yml b/cves/kernel/CVE-2012-6657.yml index 7585d19a1..9410b587a 100644 --- a/cves/kernel/CVE-2012-6657.yml +++ b/cves/kernel/CVE-2012-6657.yml @@ -19,7 +19,7 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that diff --git a/cves/kernel/CVE-2019-15216.yml b/cves/kernel/CVE-2019-15216.yml index 5d6a54eb8..60342f17d 100644 --- a/cves/kernel/CVE-2019-15216.yml +++ b/cves/kernel/CVE-2019-15216.yml @@ -19,7 +19,7 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that From 620f9eb2c74fce218b21bea35f2d83754e74cd4a Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 20:12:08 -0500 Subject: [PATCH 05/15] Donei tihnk --- cves/kernel/CVE-2012-6657.yml | 93 +++++++++++++++----------------- cves/kernel/CVE-2019-15216.yml | 97 ++++++++++++++++------------------ 2 files changed, 90 insertions(+), 100 deletions(-) diff --git a/cves/kernel/CVE-2012-6657.yml b/cves/kernel/CVE-2012-6657.yml index 9410b587a..ad6b268b1 100644 --- a/cves/kernel/CVE-2012-6657.yml +++ b/cves/kernel/CVE-2012-6657.yml @@ -55,7 +55,8 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: The function sock_setsockopt does not check the type of socket before running tcp_set_keepalive + on it, users could use a RAW socket to crash the system. bounty_instructions: | If you came across any indications that a bounty was paid out for this vulnerability, fill it out here. Or correct it if the information already here @@ -84,14 +85,9 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: - commit: 3e10986d1d698140747fcfc2761ec9cb64c1d582 note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + Manually confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -129,10 +125,10 @@ unit_tested: For the fix_answer below, check if the fix for the vulnerability involves adding or improving an automated test to ensure this doesn't happen again. - code: - code_answer: - fix: - fix_answer: + code: false + code_answer: No automated unit tests were involved. + fix: false + fix_answer: Only the change to the function was part of the commit. discovered: question: | How was this vulnerability discovered? @@ -167,8 +163,9 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: The vulnerability relies on a specific type of socket to be used, + a fully automated tool could not find the issue. + answer: false specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -184,8 +181,8 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: No mention of a violation of a specification. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -219,7 +216,7 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: + name: net note: interesting_commits: question: | @@ -235,10 +232,7 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: - - commit: - note: + note: no i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -251,8 +245,8 @@ i18n: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: Issue was purely about socket types. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -266,8 +260,9 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: The funtion in question (sock_setsockopt) is used to control socket behavior. + It was not properly checking if the socket was RAW ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -278,8 +273,8 @@ ipc: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: Not part of IPC discussion: question: | Was there any discussion surrounding this? @@ -305,9 +300,9 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: - any_discussion: - note: + discussed_as_security: false + any_discussion: false + note: First mention was that it was an issue and required a quick fix. vouch: question: | Was there any part of the fix that involved one person vouching for @@ -320,8 +315,8 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: n/a stacktrace: question: | Are there any stacktraces in the bug reports? @@ -335,9 +330,9 @@ stacktrace: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - any_stacktraces: - stacktrace_with_fix: - note: + any_stacktraces: false + stacktrace_with_fix: false + note: No stacktrace given in report forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,8 +351,8 @@ forgotten_check: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: Yes, system forgets to check if Socket is RAW. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -369,8 +364,8 @@ order_of_operations: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: Fix adds one new check. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -387,37 +382,37 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. defense_in_depth: - applies: + applies: false note: least_privilege: - applies: + applies: false note: frameworks_are_optional: - applies: + applies: false note: native_wrappers: - applies: + applies: false note: distrust_input: - applies: + applies: false note: security_by_obscurity: - applies: + applies: false note: serial_killer: - applies: + applies: false note: environment_variables: - applies: + applies: false note: secure_by_default: - applies: + applies: false note: yagni: - applies: + applies: false note: complex_inputs: - applies: + applies: false note: mistakes: question: | diff --git a/cves/kernel/CVE-2019-15216.yml b/cves/kernel/CVE-2019-15216.yml index 60342f17d..92e3778f5 100644 --- a/cves/kernel/CVE-2019-15216.yml +++ b/cves/kernel/CVE-2019-15216.yml @@ -55,7 +55,8 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: When a USB device is unplugged, the system attempts to log a message + using the device's name AFTER it has been unregistered and name deallocated, causing an error. bounty_instructions: | If you came across any indications that a bounty was paid out for this vulnerability, fill it out here. Or correct it if the information already here @@ -84,14 +85,9 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: - commit: ef61eb43ada6c1d6b94668f0f514e4c268093ff3 note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + Manually confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -129,10 +125,10 @@ unit_tested: For the fix_answer below, check if the fix for the vulnerability involves adding or improving an automated test to ensure this doesn't happen again. - code: - code_answer: - fix: - fix_answer: + code: false + code_answer: No tests were associated with this section of code. + fix: false + fix_answer: Only a preexisting function was added, no tests were changed. discovered: question: | How was this vulnerability discovered? @@ -147,10 +143,10 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: The syzkaller USB fuzzer found the issue as stated in the patch log + automated: true + contest: false + developer: true autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -167,8 +163,8 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: Yes, a fuzzer found the issue in this case. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -184,8 +180,8 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: No mention of a violation of a specification. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -219,7 +215,7 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: + name: drivers note: interesting_commits: question: | @@ -235,10 +231,8 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: - - commit: - note: + note: The code was originally written in 2010 and this function was not touched until + the issue was found and a new line for the fix was added in 2019. i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -251,8 +245,8 @@ i18n: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: This was about USB connections. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -266,8 +260,8 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: False + note: The issue was a result of attempting to access information no longer available. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -278,8 +272,8 @@ ipc: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: No + note: Was in drivers. discussion: question: | Was there any discussion surrounding this? @@ -305,9 +299,9 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: - any_discussion: - note: + discussed_as_security: false + any_discussion: false + note: First mention was that it was an issue and required a quick fix. vouch: question: | Was there any part of the fix that involved one person vouching for @@ -320,8 +314,8 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: The bug existed for 9 years before it was found, it was not noticed until a fuzzer found it. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -335,8 +329,9 @@ stacktrace: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - any_stacktraces: - stacktrace_with_fix: + any_stacktraces: yes + stacktrace_with_fix: The file with the bug is at the top of the stacktrace but not near the line + where the fix was implemented. note: forgotten_check: question: | @@ -356,7 +351,7 @@ forgotten_check: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: + answer: false note: order_of_operations: question: | @@ -369,8 +364,8 @@ order_of_operations: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: A message based on a device's data attempted to send after the data was removed. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -387,37 +382,37 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. defense_in_depth: - applies: + applies: false note: least_privilege: - applies: + applies: false note: frameworks_are_optional: - applies: + applies: false note: native_wrappers: - applies: + applies: false note: distrust_input: - applies: + applies: false note: security_by_obscurity: - applies: + applies: false note: serial_killer: - applies: + applies: false note: environment_variables: - applies: + applies: false note: secure_by_default: - applies: + applies: false note: yagni: - applies: + applies: false note: complex_inputs: - applies: + applies: false note: mistakes: question: | From efcf87d71486b9aefd4591e11c0f6fca39b5b086 Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 20:31:05 -0500 Subject: [PATCH 06/15] Fixed yml error --- cves/kernel/CVE-2012-6657.yml | 12 ++++++------ cves/kernel/CVE-2019-15216.yml | 8 ++++---- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/cves/kernel/CVE-2012-6657.yml b/cves/kernel/CVE-2012-6657.yml index ad6b268b1..db56973f1 100644 --- a/cves/kernel/CVE-2012-6657.yml +++ b/cves/kernel/CVE-2012-6657.yml @@ -143,10 +143,10 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: Discovered by a developer, no used of tools were mentioned. + automated: false + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -468,5 +468,5 @@ nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. -nickname: -CVSS: +nickname: Socket type non check. +CVSS: \ No newline at end of file diff --git a/cves/kernel/CVE-2019-15216.yml b/cves/kernel/CVE-2019-15216.yml index 92e3778f5..3b581b1d7 100644 --- a/cves/kernel/CVE-2019-15216.yml +++ b/cves/kernel/CVE-2019-15216.yml @@ -260,7 +260,7 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: False + answer: false note: The issue was a result of attempting to access information no longer available. ipc: question: | @@ -272,7 +272,7 @@ ipc: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: No + answer: false note: Was in drivers. discussion: question: | @@ -443,7 +443,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: The main mistake was a lack of critical thinking about order of operations. CWE_instructions: | Please go to http://cwe.mitre.org and find the most specific, appropriate CWE entry that describes your vulnerability. We recommend going to @@ -468,5 +468,5 @@ nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. -nickname: +nickname: US Driver data collection after disconnect CVSS: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H From 5b1e89558636b9793c95524d9da49559310a1843 Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 20:46:16 -0500 Subject: [PATCH 07/15] Fixed more --- cves/kernel/CVE-2012-6657.yml | 3 +-- cves/kernel/CVE-2019-15216.yml | 8 ++++---- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/cves/kernel/CVE-2012-6657.yml b/cves/kernel/CVE-2012-6657.yml index db56973f1..06fdfe344 100644 --- a/cves/kernel/CVE-2012-6657.yml +++ b/cves/kernel/CVE-2012-6657.yml @@ -102,7 +102,7 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: - commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 - note: Discovered automatically by archeogit. + note: Manually verified upvotes_instructions: | For the first round, ignore this upvotes number. @@ -231,7 +231,6 @@ interesting_commits: * A significant rewrite in the git history * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. - commits: note: no i18n: question: | diff --git a/cves/kernel/CVE-2019-15216.yml b/cves/kernel/CVE-2019-15216.yml index 3b581b1d7..d90a9f684 100644 --- a/cves/kernel/CVE-2019-15216.yml +++ b/cves/kernel/CVE-2019-15216.yml @@ -102,7 +102,7 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: - commit: 6bc235a2e24a5ef677daee3fd4f74f6cd643e23c - note: Discovered automatically by archeogit. + note: Manually verified upvotes_instructions: | For the first round, ignore this upvotes number. @@ -230,7 +230,7 @@ interesting_commits: * A significant rewrite in the git history * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. - commits: + - commits: note: The code was originally written in 2010 and this function was not touched until the issue was found and a new line for the fix was added in 2019. i18n: @@ -329,10 +329,10 @@ stacktrace: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - any_stacktraces: yes + any_stacktraces: true stacktrace_with_fix: The file with the bug is at the top of the stacktrace but not near the line where the fix was implemented. - note: + note: trace was given in report forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? From af81adf5e4965b8f068307263c478b185670290d Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 20:49:43 -0500 Subject: [PATCH 08/15] Fix syntax --- cves/kernel/CVE-2019-15216.yml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/cves/kernel/CVE-2019-15216.yml b/cves/kernel/CVE-2019-15216.yml index d90a9f684..14604b352 100644 --- a/cves/kernel/CVE-2019-15216.yml +++ b/cves/kernel/CVE-2019-15216.yml @@ -230,8 +230,7 @@ interesting_commits: * A significant rewrite in the git history * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. - - commits: - note: The code was originally written in 2010 and this function was not touched until + note: The code was originally written in 2010 and this function was not touched until the issue was found and a new line for the fix was added in 2019. i18n: question: | From 6dc07b520157adb95243cd2cff66eb4d30995150 Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 20:56:27 -0500 Subject: [PATCH 09/15] A --- cves/kernel/CVE-2012-6657.yml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/cves/kernel/CVE-2012-6657.yml b/cves/kernel/CVE-2012-6657.yml index 06fdfe344..7d696caf0 100644 --- a/cves/kernel/CVE-2012-6657.yml +++ b/cves/kernel/CVE-2012-6657.yml @@ -86,8 +86,7 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: - commit: 3e10986d1d698140747fcfc2761ec9cb64c1d582 - note: | - Manually confirmed + note: Manually Confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -231,7 +230,9 @@ interesting_commits: * A significant rewrite in the git history * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. - note: no + commits: + - commit: + note: i18n: question: | Was the feature impacted by this vulnerability about internationalization From 48c3b45b6da833570a0a70c1e265c3acba21b06c Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 20:59:49 -0500 Subject: [PATCH 10/15] 2012 fixed --- cves/kernel/CVE-2012-6657.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2012-6657.yml b/cves/kernel/CVE-2012-6657.yml index 7d696caf0..3efaf7716 100644 --- a/cves/kernel/CVE-2012-6657.yml +++ b/cves/kernel/CVE-2012-6657.yml @@ -443,7 +443,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: lapse: Forgot to check if socket was RAW CWE_instructions: | Please go to http://cwe.mitre.org and find the most specific, appropriate CWE entry that describes your vulnerability. We recommend going to From acbe0736df1fac3e383eb2f29f63e545938fce6c Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 21:02:10 -0500 Subject: [PATCH 11/15] Fixing 2019 --- cves/kernel/CVE-2019-15216.yml | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/cves/kernel/CVE-2019-15216.yml b/cves/kernel/CVE-2019-15216.yml index 14604b352..8ca92f8d6 100644 --- a/cves/kernel/CVE-2019-15216.yml +++ b/cves/kernel/CVE-2019-15216.yml @@ -86,8 +86,7 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: - commit: ef61eb43ada6c1d6b94668f0f514e4c268093ff3 - note: | - Manually confirmed + note: Manually confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -230,8 +229,10 @@ interesting_commits: * A significant rewrite in the git history * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. - note: The code was originally written in 2010 and this function was not touched until - the issue was found and a new line for the fix was added in 2019. + commits: + - commit: + note: The code was originally written in 2010 and this function was not touched until + the issue was found and a new line for the fix was added in 2019. i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -467,5 +468,5 @@ nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. -nickname: US Driver data collection after disconnect +nickname: Requesting Null Data CVSS: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H From 2c41863309226133d86e7efee12036df9a6a2abc Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 21:04:21 -0500 Subject: [PATCH 12/15] Fixed syn --- cves/kernel/CVE-2019-15216.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2019-15216.yml b/cves/kernel/CVE-2019-15216.yml index 8ca92f8d6..c1827651f 100644 --- a/cves/kernel/CVE-2019-15216.yml +++ b/cves/kernel/CVE-2019-15216.yml @@ -231,7 +231,8 @@ interesting_commits: * Anything else you find interesting. commits: - commit: - note: The code was originally written in 2010 and this function was not touched until + note: | + The code was originally written in 2010 and this function was not touched until the issue was found and a new line for the fix was added in 2019. i18n: question: | From f8b8b4c32c8d3a5b4fdc54646def94c2c17352da Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 21:05:53 -0500 Subject: [PATCH 13/15] Removed : --- cves/kernel/CVE-2012-6657.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2012-6657.yml b/cves/kernel/CVE-2012-6657.yml index 3efaf7716..5c683c88a 100644 --- a/cves/kernel/CVE-2012-6657.yml +++ b/cves/kernel/CVE-2012-6657.yml @@ -443,7 +443,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: lapse: Forgot to check if socket was RAW + answer: lapse - Forgot to check if socket was RAW CWE_instructions: | Please go to http://cwe.mitre.org and find the most specific, appropriate CWE entry that describes your vulnerability. We recommend going to From 86c36656f702ea100aec8c7281c9c2364deb1f41 Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Wed, 8 Nov 2023 21:10:55 -0500 Subject: [PATCH 14/15] Fixed 2019 --- cves/kernel/CVE-2019-15216.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/cves/kernel/CVE-2019-15216.yml b/cves/kernel/CVE-2019-15216.yml index c1827651f..332eff759 100644 --- a/cves/kernel/CVE-2019-15216.yml +++ b/cves/kernel/CVE-2019-15216.yml @@ -331,9 +331,9 @@ stacktrace: Write a note about how you came to the conclusions you did, regardless of what your answer was. any_stacktraces: true - stacktrace_with_fix: The file with the bug is at the top of the stacktrace but not near the line + stacktrace_with_fix: false + note: The file with the bug is at the top of the stacktrace but not near the line where the fix was implemented. - note: trace was given in report forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -353,7 +353,7 @@ forgotten_check: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: false - note: + note: Out of order order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of From 9e47409e431585bf2fc04b3437490d3449575bd5 Mon Sep 17 00:00:00 2001 From: jgw6160 Date: Sat, 18 Nov 2023 18:03:07 -0500 Subject: [PATCH 15/15] Added upvotes --- cves/kernel/CVE-2012-6657.yml | 2 +- cves/kernel/CVE-2019-15216.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cves/kernel/CVE-2012-6657.yml b/cves/kernel/CVE-2012-6657.yml index 5c683c88a..1fb9e890e 100644 --- a/cves/kernel/CVE-2012-6657.yml +++ b/cves/kernel/CVE-2012-6657.yml @@ -109,7 +109,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: +upvotes: 7 unit_tested: question: | Were automated unit tests involved in this vulnerability? diff --git a/cves/kernel/CVE-2019-15216.yml b/cves/kernel/CVE-2019-15216.yml index 332eff759..17417d397 100644 --- a/cves/kernel/CVE-2019-15216.yml +++ b/cves/kernel/CVE-2019-15216.yml @@ -109,7 +109,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: +upvotes: 15 unit_tested: question: | Were automated unit tests involved in this vulnerability?