From 27f7e34e44a80a74ad407f60885c6ac65ebb7394 Mon Sep 17 00:00:00 2001 From: Anirudh Suresh Date: Wed, 1 Nov 2023 21:40:41 -0400 Subject: [PATCH 1/4] added CVE's --- CVE-2013-7348.yml | 477 ++++++++++++++++++++++++++++++++++++++++++++++ CVE-2022-3105.yml | 477 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 954 insertions(+) create mode 100644 CVE-2013-7348.yml create mode 100644 CVE-2022-3105.yml diff --git a/CVE-2013-7348.yml b/CVE-2013-7348.yml new file mode 100644 index 000000000..083f6c830 --- /dev/null +++ b/CVE-2013-7348.yml @@ -0,0 +1,477 @@ +CVE: CVE-2013-7348 +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-04-01' +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-04-01' +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: d558023207e008a4476a3b7bb8706b2a2bf5d84f + 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: e23754f880f10124f0a2848f9d17e361a295378e + 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: +- 399 +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-2022-3105.yml b/CVE-2022-3105.yml new file mode 100644 index 000000000..2ae82b0f6 --- /dev/null +++ b/CVE-2022-3105.yml @@ -0,0 +1,477 @@ +CVE: CVE-2022-3105 +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: '2022-12-14' +published_instructions: | + Is there a published fix or patch date for this vulnerability? + Please enter your date in YYYY-MM-DD format. +published_date: '2022-12-14' +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: 7694a7de22c53a312ea98960fcafc6ec62046531 + 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: 6884c6c4bd09fb35b79a3967d15821cdfcbe77a3 + 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:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H From d62746433ab5dd8458dc00ae9f4b4ddf9a003120 Mon Sep 17 00:00:00 2001 From: Anirudh Suresh Date: Wed, 1 Nov 2023 23:01:35 -0400 Subject: [PATCH 2/4] trying again --- CVE-2013-7348.yml | 591 +++++++++++++++++++-------------------------- CVE-2022-3105.yml | 593 +++++++++++++++++++--------------------------- 2 files changed, 491 insertions(+), 693 deletions(-) diff --git a/CVE-2013-7348.yml b/CVE-2013-7348.yml index 083f6c830..f0fbab108 100644 --- a/CVE-2013-7348.yml +++ b/CVE-2013-7348.yml @@ -1,195 +1,174 @@ CVE: CVE-2013-7348 -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-04-01' -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-04-01' -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/ +CWE: + - 399 +ipc: + note: + answer: + 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. - Bug ID's can appear in several places: - * Mentioned in commit messages - * Mentioned in mailing list discussions - * References from NVD entry - * Various other places + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +CVSS: bugs: [] -fixes_instructions: | - Please put the commit hash in "commit" below. +i18n: + note: + answer: + question: | + Was the feature impacted by this vulnerability about internationalization + (i18n)? - This must be a git commit hash from the systemd source repo, a 40-character - hexademical string/ + 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. - Place any notes you would like to make in the notes field. + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +vccs: + - note: Discovered automatically by archeogit. + commit: e23754f880f10124f0a2848f9d17e361a295378e fixes: -- commit: - note: -- commit: + - note: + commit: + - note: + commit: + - 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' + commit: d558023207e008a4476a3b7bb8706b2a2bf5d84f +vouch: note: -- commit: d558023207e008a4476a3b7bb8706b2a2bf5d84f - 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: e23754f880f10124f0a2848f9d17e361a295378e - 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? + answer: + question: > + Was there any part of the fix that involved one person vouching for - For code: and fix: - your answer should be boolean. + another's work? - 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: + 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. +bounty: + amt: + url: + announced: +lessons: + yagni: + note: + applies: question: | - How was this vulnerability discovered? + 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? - 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. + 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. - The automated, contest, and developer flags can be true, false, or nil. + 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 there is no evidence as to how this vulnerability was found, then please - explain where you looked. + 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. + serial_killer: + note: + applies: + complex_inputs: + note: + applies: + distrust_input: + note: + applies: + least_privilege: + note: + applies: + native_wrappers: + note: + applies: + defense_in_depth: + note: + applies: + secure_by_default: + note: + applies: + environment_variables: + note: + applies: + security_by_obscurity: + note: + applies: + frameworks_are_optional: + note: + applies: +reviews: [] +sandbox: + note: 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. + question: | + Did this vulnerability violate a sandboxing feature that the system + provides? - Examples for true answers: SQL injection, XSS, buffer overflow + 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. - In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +upvotes: 0 +CWE_note: | + CWE as registered in the NVD. If you are curating, check that this + is correct and replace this comment with "Manually confirmed". +mistakes: + answer: + 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? - Examples for false: RFC violations, permissions issues, anything - that requires the tool to be "aware" of the project's - domain-specific requirements. + There can, and usually are, many mistakes behind a vulnerability. - 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. + 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 - Be sure to check the following artifacts for this: - * bug reports - * security advisories - * commit message - * mailing lists - * anything else + These are grey areas, of course. But do your best to analyze the mistakes + according to this framework. - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: - answer: + 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. +nickname: subsystem: - question: | + name: + note: + 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 @@ -200,9 +179,12 @@ subsystem: 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 @@ -216,71 +198,30 @@ subsystem: * 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. +discovered: answer: - note: -sandbox: + contest: question: | - Did this vulnerability violate a sandboxing feature that the system - provides? + How was this vulnerability discovered? - 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. + 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. - 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. + The automated, contest, and developer flags can be true, false, or nil. - 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: + If there is no evidence as to how this vulnerability was found, then please + explain where you looked. + automated: + developer: discussion: + note: question: | Was there any discussion surrounding this? @@ -305,24 +246,10 @@ 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: -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: + discussed_as_security: stacktrace: + note: question: | Are there any stacktraces in the bug reports? @@ -337,8 +264,49 @@ stacktrace: what your answer was. any_stacktraces: stacktrace_with_fix: +description: +unit_tested: + fix: + code: + 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. + fix_answer: + code_answer: +reported_date: +specification: note: + answer: + 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. +announced_date: 2014-04-01 +curation_level: 2 +published_date: 2014-04-01 forgotten_check: + note: + answer: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,9 +324,45 @@ 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: +autodiscoverable: note: + answer: + 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. +interesting_commits: + commits: + - note: + commit: + - note: + commit: + 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. order_of_operations: + note: + answer: question: | Does the fix for the vulnerability involve correcting an order of operations? @@ -369,109 +373,4 @@ 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: -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: -- 399 -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-2022-3105.yml b/CVE-2022-3105.yml index 2ae82b0f6..8fe4fa9e3 100644 --- a/CVE-2022-3105.yml +++ b/CVE-2022-3105.yml @@ -1,195 +1,174 @@ CVE: CVE-2022-3105 -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: '2022-12-14' -published_instructions: | - Is there a published fix or patch date for this vulnerability? - Please enter your date in YYYY-MM-DD format. -published_date: '2022-12-14' -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/ +CWE: + - 476 +ipc: + note: + answer: + 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. - Bug ID's can appear in several places: - * Mentioned in commit messages - * Mentioned in mailing list discussions - * References from NVD entry - * Various other places + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H 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/ +i18n: + note: + answer: + question: | + Was the feature impacted by this vulnerability about internationalization + (i18n)? +s + 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. - Place any notes you would like to make in the notes field. + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +vccs: + - note: Discovered automatically by archeogit. + commit: 6884c6c4bd09fb35b79a3967d15821cdfcbe77a3 fixes: -- commit: - note: -- commit: + - note: + commit: + - note: + commit: + - 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' + commit: 7694a7de22c53a312ea98960fcafc6ec62046531 +vouch: note: -- commit: 7694a7de22c53a312ea98960fcafc6ec62046531 - 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: 6884c6c4bd09fb35b79a3967d15821cdfcbe77a3 - 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? + answer: + question: > + Was there any part of the fix that involved one person vouching for - For code: and fix: - your answer should be boolean. + another's work? - 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: + 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. +bounty: + amt: + url: + announced: +lessons: + yagni: + note: + applies: question: | - How was this vulnerability discovered? + 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? - 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. + 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. - The automated, contest, and developer flags can be true, false, or nil. + 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 there is no evidence as to how this vulnerability was found, then please - explain where you looked. + 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. + serial_killer: + note: + applies: + complex_inputs: + note: + applies: + distrust_input: + note: + applies: + least_privilege: + note: + applies: + native_wrappers: + note: + applies: + defense_in_depth: + note: + applies: + secure_by_default: + note: + applies: + environment_variables: + note: + applies: + security_by_obscurity: + note: + applies: + frameworks_are_optional: + note: + applies: +reviews: [] +sandbox: + note: 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. + question: | + Did this vulnerability violate a sandboxing feature that the system + provides? - Examples for true answers: SQL injection, XSS, buffer overflow + 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. - In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +upvotes: 0 +CWE_note: | + CWE as registered in the NVD. If you are curating, check that this + is correct and replace this comment with "Manually confirmed". +mistakes: + answer: + 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? - Examples for false: RFC violations, permissions issues, anything - that requires the tool to be "aware" of the project's - domain-specific requirements. + There can, and usually are, many mistakes behind a vulnerability. - 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. + 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 - Be sure to check the following artifacts for this: - * bug reports - * security advisories - * commit message - * mailing lists - * anything else + These are grey areas, of course. But do your best to analyze the mistakes + according to this framework. - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: - answer: + 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. +nickname: subsystem: - question: | + name: + note: + 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 @@ -200,9 +179,12 @@ subsystem: 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 @@ -216,71 +198,30 @@ subsystem: * 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. +discovered: answer: - note: -sandbox: + contest: question: | - Did this vulnerability violate a sandboxing feature that the system - provides? + How was this vulnerability discovered? - 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. + 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. - 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. + The automated, contest, and developer flags can be true, false, or nil. - 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: + If there is no evidence as to how this vulnerability was found, then please + explain where you looked. + automated: + developer: discussion: + note: question: | Was there any discussion surrounding this? @@ -305,24 +246,10 @@ 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: -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: + discussed_as_security: stacktrace: + note: question: | Are there any stacktraces in the bug reports? @@ -337,8 +264,49 @@ stacktrace: what your answer was. any_stacktraces: stacktrace_with_fix: +description: +unit_tested: + fix: + code: + 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. + fix_answer: + code_answer: +reported_date: +specification: note: + answer: + 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. +announced_date: 2022-12-14 +curation_level: 2 +published_date: 2022-12-14 forgotten_check: + note: + answer: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,9 +324,45 @@ 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: +autodiscoverable: note: + answer: + 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. +interesting_commits: + commits: + - note: + commit: + - note: + commit: + 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. order_of_operations: + note: + answer: question: | Does the fix for the vulnerability involve correcting an order of operations? @@ -369,109 +373,4 @@ 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: -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:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H From 96e01fe8c17a44c6be54782305c5bd3c33aa7a7f Mon Sep 17 00:00:00 2001 From: Anirudh Suresh <60349205+as9215@users.noreply.github.com> Date: Tue, 7 Nov 2023 11:41:37 -0500 Subject: [PATCH 3/4] CVE-2013-7348.yml --- CVE-2013-7348.yml | 95 +++++++++++++++++++++++------------------------ 1 file changed, 47 insertions(+), 48 deletions(-) diff --git a/CVE-2013-7348.yml b/CVE-2013-7348.yml index f0fbab108..aaa233697 100644 --- a/CVE-2013-7348.yml +++ b/CVE-2013-7348.yml @@ -2,8 +2,8 @@ CVE: CVE-2013-7348 CWE: - 399 ipc: - note: - answer: + note: There are no commands within that function that utilizes signals, pipes, message passing, or standard input/output + answer: False question: | Did the feature that this vulnerability affected use inter-process communication? IPC includes OS signals, pipes, stdin/stdout, message @@ -13,11 +13,11 @@ 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. -CVSS: +CVSS: 4.6 bugs: [] i18n: - note: - answer: + note: Internationalization pertains to user interfaces and input with different languages and characters. This function does not process user input. However, it does perform i/o functions on files. + answer: False question: | Was the feature impacted by this vulnerability about internationalization (i18n)? @@ -33,22 +33,17 @@ vccs: - note: Discovered automatically by archeogit. commit: e23754f880f10124f0a2848f9d17e361a295378e fixes: - - note: - commit: - - note: - commit: - - 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' + - note: Add locking of q->sysfs_lock into elevator_change() (an exported function) to ensure it is held to protect q->elevator from elevator_init(), even if elevator_change() is called from non-sysfs paths. sysfs path (elv_iosched_store) uses __elevator_change(), non-locking version, as the lock is already taken by elv_iosched_store(). + commit: 7c8a3679e3d8e9d92d58f282161760a0e247df97 + - note: This fixes Report Descriptor for Logitech MOMO Force. By default the Logitech MOMO Force (Black) presents a combined accel/brake axis ('Y'). This patch modifies the HID descriptor to present seperate accel/brake axes ('Y' and 'Z'). + commit: 348cbaa800f8161168b20f85f72abb541c145132 + - note: Manually confirmed commit: d558023207e008a4476a3b7bb8706b2a2bf5d84f vouch: - note: - answer: + note: While scrolling through kernel.org, there are many commits that consist of upstreams commits with members signing off on, and acknowledging other commits. + answer: True question: > - Was there any part of the fix that involved one person vouching for - - another's work? + Was there any part of the fix that involved one person vouching for another's work? This can include: @@ -65,8 +60,8 @@ bounty: announced: lessons: yagni: - note: - applies: + note: Input sanitization and error handling apply to this vulnerability, because with these practices, the risk posed by this vulnerability could be mitigated. + applies: True 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 @@ -83,38 +78,38 @@ lessons: free to give it a small name and add one in the same format as these. serial_killer: note: - applies: + applies: False complex_inputs: note: - applies: + applies: True distrust_input: note: - applies: + applies: True least_privilege: note: - applies: + applies: False native_wrappers: note: - applies: + applies: False defense_in_depth: note: - applies: + applies: False secure_by_default: note: - applies: + applies: False environment_variables: note: - applies: + applies: False security_by_obscurity: note: - applies: + applies: False frameworks_are_optional: note: - applies: + applies: False reviews: [] sandbox: - note: - answer: + note: If a threat actor gained control over the kernel, the vulnerability could be exploited to escape a sandbox. This could allow privilege escalation, resource access, and path traversal. + answer: True question: | Did this vulnerability violate a sandboxing feature that the system provides? @@ -132,7 +127,8 @@ CWE_note: | CWE as registered in the NVD. If you are curating, check that this is correct and replace this comment with "Manually confirmed". mistakes: - answer: + answer: The vulnerability described in CVE-2013-7348 may have arisen from a combination of coding mistakes, design flaws, and shortcomings in error handling. In this case, the code related to asynchronous I/O (AIO) operations within the Linux kernel may have lacked robust resource management, leading to memory corruption and potential privilege escalation. Coding mistakes, such as improper memory allocation and deallocation, could have played a role, as well as complex code that made it harder to identify vulnerabilities. Additionally, design flaws in the implementation of AIO and resource allocation might have contributed to the issue. Testing gaps and a potential lack of comprehensive security testing could have allowed the vulnerability to go undetected. Adequate documentation, clear security requirements, and heightened security awareness among developers and reviewers are essential in mitigating such vulnerabilities and maintaining robust security in software systems. + question: | In your opinion, after all of this research, what mistakes were made that led to this vulnerability? Coding mistakes? Design mistakes? @@ -163,8 +159,8 @@ mistakes: industry would find interesting. nickname: subsystem: - name: - note: + name: fs + note: This vulnerability involves asynchronous I/O (AIO) implementation, which deals with file I/O operations and resource management. Issues related to file I/O, memory allocation, and resource management are typically associated with the "fs" subsystem, as it deals with the file system operations and related kernel functionality. question: > What subsystems was the mistake in? These are WITHIN linux kernel @@ -203,8 +199,8 @@ subsystem: name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok discovered: - answer: - contest: + answer: After looking through kernel.org, openwall.com, and github, I wasn't able to find any evidence as to how this vulnerability was found. + contest: nil question: | How was this vulnerability discovered? @@ -218,15 +214,19 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - automated: - developer: + automated: nil + developer: nil discussion: - note: + note: https://mirrors.edge.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.0.10 question: | - Was there any discussion surrounding this? + 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. - A discussion can include debates, disputes, or polite talk about how to - resolve uncertainty. Example include: * Is this out of our scope? @@ -246,8 +246,8 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - any_discussion: - discussed_as_security: + any_discussion: True + discussed_as_security: True stacktrace: note: question: | @@ -361,8 +361,8 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. order_of_operations: - note: - answer: + note: The fix involves error handling. It does not include include moving the code. + answer: False question: | Does the fix for the vulnerability involve correcting an order of operations? @@ -373,4 +373,3 @@ 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. - From dd84faf70cc84f59a99ca3305928df191e4da9ad Mon Sep 17 00:00:00 2001 From: Anirudh Suresh <60349205+as9215@users.noreply.github.com> Date: Tue, 7 Nov 2023 11:42:40 -0500 Subject: [PATCH 4/4] CVE-2022-3105.yml --- CVE-2022-3105.yml | 99 ++++++++++++++++++++++------------------------- 1 file changed, 47 insertions(+), 52 deletions(-) diff --git a/CVE-2022-3105.yml b/CVE-2022-3105.yml index 8fe4fa9e3..d6158e195 100644 --- a/CVE-2022-3105.yml +++ b/CVE-2022-3105.yml @@ -2,8 +2,8 @@ CVE: CVE-2022-3105 CWE: - 476 ipc: - note: - answer: + note: This is primarily used for communication between user-space applications and kernel-space InfiniBand (IB) and Remote Direct Memory Access (RDMA) drivers. It doesn't directly deal with inter-process communication (IPC) mechanisms such as OS signals, pipes, stdin/stdout, message passing, clipboard, or file-based IPC. + answer: False question: | Did the feature that this vulnerability affected use inter-process communication? IPC includes OS signals, pipes, stdin/stdout, message @@ -14,14 +14,14 @@ ipc: Write a note about how you came to the conclusions you did, regardless of what your answer was. CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H -bugs: [] +bugs: [2153067] i18n: - note: - answer: + note: It is unlikely that the vulnerabilities or issues related to this code have a direct impact on internationalization (i18n) features. Internationalization features in software are generally concerned with providing support for different languages, character encodings, locales, and user interface translations, among other aspects. + answer: False question: | Was the feature impacted by this vulnerability about internationalization (i18n)? -s + 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. @@ -37,14 +37,11 @@ fixes: commit: - note: commit: - - 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' + - note: Manually confirmed commit: 7694a7de22c53a312ea98960fcafc6ec62046531 vouch: - note: - answer: + note: I checked the kernel.org hyperlink in the references section of nvd + answer: True question: > Was there any part of the fix that involved one person vouching for @@ -66,7 +63,7 @@ bounty: lessons: yagni: note: - applies: + applies: [distrust_input, complex_input] 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 @@ -83,38 +80,38 @@ lessons: free to give it a small name and add one in the same format as these. serial_killer: note: - applies: + applies: False complex_inputs: - note: - applies: + note: error handling can have errors smoothly handled if a null pointer is dereferenced + applies: True distrust_input: - note: - applies: + note: input validation can be used to avoid a null pointer dereference + applies: True least_privilege: note: - applies: + applies: False native_wrappers: note: - applies: + applies: False defense_in_depth: note: - applies: + applies: False secure_by_default: note: - applies: + applies: False environment_variables: note: - applies: + applies: False security_by_obscurity: note: - applies: + applies: False frameworks_are_optional: note: - applies: + applies: False reviews: [] sandbox: - note: - answer: + note: This vulnerability relates more to memory allocation and error handling as opposed to sandboxing violations or access control issues. + answer: False question: | Did this vulnerability violate a sandboxing feature that the system provides? @@ -128,11 +125,10 @@ sandbox: Write a note about how you came to the conclusions you did, regardless of what your answer was. upvotes: 0 -CWE_note: | - CWE as registered in the NVD. If you are curating, check that this - is correct and replace this comment with "Manually confirmed". +CWE_note: Manually confirmed mistakes: - answer: + answer: The vulnerability stems from coding mistakes and design flaws. The critical coding mistake lies in the failure to check the result of a memory allocation operation, specifically, the use of kmalloc_array. This error handling oversight can be attributed to a lack of attention to the return value of the allocation function. Design mistakes may also be relevant if there are patterns of a lack of error handling and memory management throughout the code. Miscommunications could have contributed improper error handling practices in the code but there is no evidence that miscommunication is the direct cause. + question: | In your opinion, after all of this research, what mistakes were made that led to this vulnerability? Coding mistakes? Design mistakes? @@ -161,10 +157,10 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. -nickname: +nickname: NULL Pointer Dereference subsystem: - name: - note: + name: RDMA + note: this is known because of the headers directly referencing rdma, the function names, and the subsystem references. question: > What subsystems was the mistake in? These are WITHIN linux kernel @@ -203,8 +199,8 @@ subsystem: name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok discovered: - answer: - contest: + answer: 2022-12-13 + contest: False question: | How was this vulnerability discovered? @@ -218,10 +214,10 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - automated: - developer: + automated: False + developer: True discussion: - note: + note: I was not able to find any disagreements question: | Was there any discussion surrounding this? @@ -246,8 +242,8 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - any_discussion: - discussed_as_security: + any_discussion: True + discussed_as_security: True stacktrace: note: question: | @@ -267,7 +263,7 @@ stacktrace: description: unit_tested: fix: - code: + code: True question: | Were automated unit tests involved in this vulnerability? Was the original code unit tested, or not unit tested? Did the fix involve @@ -283,10 +279,10 @@ unit_tested: adding or improving an automated test to ensure this doesn't happen again. fix_answer: code_answer: -reported_date: +reported_date: 2022-12-13 specification: - note: - answer: + note: POSIX may be violated by failing to handle memory allocation errors. + answer: True 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 @@ -305,8 +301,8 @@ announced_date: 2022-12-14 curation_level: 2 published_date: 2022-12-14 forgotten_check: - note: - answer: + note: This is shown in the kernel.org fix demonstrated by jiasheng jiang. According to the log, the author inserted code to check the data variable. + answer: True question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -325,8 +321,8 @@ forgotten_check: Write a note about how you came to the conclusions you did, regardless of what your answer was. autodiscoverable: - note: - answer: + note: An empty dataset would trigger this vulnerability + answer: True instructions: | Is it plausible that a fully automated tool could have discovered this? These are tools that require little knowledge of the domain, @@ -361,8 +357,8 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. order_of_operations: - note: - answer: + note: The fix requires adding a check for memory allocation prior to dereferencing + answer: False question: | Does the fix for the vulnerability involve correcting an order of operations? @@ -373,4 +369,3 @@ 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. -