From e803dfddb0398735a2f3cf0776be0ee8eb150d9f Mon Sep 17 00:00:00 2001 From: Ash Thompson Date: Sat, 4 Nov 2023 20:57:46 -0400 Subject: [PATCH 1/8] 1st draft CVE-2013-3228 CVE-2020-10768 --- cves/kernel/CVE-2013-3228.yml | 585 +++++++++++---------------------- cves/kernel/CVE-2020-10768.yml | 575 +++++++++++--------------------- 2 files changed, 398 insertions(+), 762 deletions(-) diff --git a/cves/kernel/CVE-2013-3228.yml b/cves/kernel/CVE-2013-3228.yml index 7c246cf5b..143fcda9b 100644 --- a/cves/kernel/CVE-2013-3228.yml +++ b/cves/kernel/CVE-2013-3228.yml @@ -1,261 +1,104 @@ CVE: CVE-2013-3228 -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: '2013-04-22' -published_instructions: | - Is there a published fix or patch date for this vulnerability? - Please enter your date in YYYY-MM-DD format. -published_date: '2013-04-22' -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 +CWE: + - 200 +ipc: Yes. The affected function receives messages from external IR connections. It is part of a subsystem enabling IPC. +CVSS: 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: 5ae94c0d2f0bed41d6718be743985d61b7f5c47d - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' -vcc_instructions: | - The vulnerability-contributing commits. - - These are found by our tools by traversing the Git Blame history, where we - determine which commit(s) introduced the functionality. - - Look up these VCC commits and verify that they are not simple refactorings, - and that they are, in fact introducing the vulnerability into the system. - Often, introducing the file or function is where the VCC is, but VCCs can be - anything. - - Place any notes you would like to make in the notes field. -vccs: -- commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 - note: Discovered automatically by archeogit. -- commit: 0dc47877a3de00ceadea0005189656ae8dc52669 - 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: +i18n: + note: The messages being received are not read for text data, so i18n shouldn't be an issue. + answer: false 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. + Was the feature impacted by this vulnerability about internationalization + (i18n)? - 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? + 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. - 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. +vccs: + - commit: 0dc47877a3de00ceadea0005189656ae8dc52669 + note: This makes a patch closeby while skipping over this vulnerability. Note that the vulnerability existed in the kernel for the lifetime of the IrDA module. +fixes: + - commit: f89e8a6432409c6cbd5c2b6bb90ea694fd558de3 + note: "Fix is merged along with the branch of similar information leak fixes." + - commit: 5ae94c0d2f0bed41d6718be743985d61b7f5c47d + note: "Initial fixing commit, manually confirmed." +vouch: + note: "The fixing commit was only signed by the committer and author." + answer: false + question: > + Was there any part of the fix that involved one person vouching for - The automated, contest, and developer flags can be true, false, or nil. + another's work? - 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 + 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 - In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. + Answer must be true or false. - Examples for false: RFC violations, permissions issues, anything - that requires the tool to be "aware" of the project's - domain-specific requirements. + 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: | + 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? - 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. + 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. - Be sure to check the following artifacts for this: - * bug reports - * security advisories - * commit message - * mailing lists - * anything else + Don't feel the need to claim that ALL of these apply, but it's pretty likely + that one or two of them apply. - 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: + 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: - - commit: + applies: + complex_inputs: 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: + applies:The msg parameter contains a large number of attributes that may not be initialized. Needing to handle these to prevent an information leak was unclear initially. + 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: question: | Did this vulnerability violate a sandboxing feature that the system provides? @@ -268,21 +111,26 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: -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: +upvotes: 2 +CWE_note: | + Manually confirmed. +mistakes: This vulnerability is the result of a simple coding slip. An ambiguous + input meant it was unclear a particular value needed to be reset to 0. + Missing this value reset enabled an information leak with an unusual + attack vector that might not be considered during authoring or code reviewing + this file. Maybe with better/more accessible documentation of the details of + the ambiguous msg input, this would have been caught earlier. The fix is + simple and was able to be distributed to many affected protocols at once. Due + to the number of common protocols with the same vulnerability, it's possible + that copy-pasting was involved at some point and allowed for the proliferation + of this problem. +nickname: +subsystem: ["IrDA"] +discovered: Discovered with related vulnerabilities discussion: + note: "No discussion directly related to this vulnerability. A bug report + was filed that seemed to be causing crashes in an AWS instance, but + it was unclear if this crash was due to this vulnerability." question: | Was there any discussion surrounding this? @@ -307,24 +155,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: + any_discussion: false + discussed_as_security: false stacktrace: + note: The connected bug on bugzilla seems disconnected, but also does not contain any stacktraces. question: | Are there any stacktraces in the bug reports? @@ -337,10 +171,55 @@ stacktrace: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - any_stacktraces: - stacktrace_with_fix: - note: + any_stacktraces: false + stacktrace_with_fix: false +description: | + In the IR subsystem of the Linux kernel, a function responsible for receiving messages + was affected by an information leak. The message variable's length property needed to be reset to 0. + Missing this value reset enabled an information leak where a small part of protected kernel memory + could be read, possibly enabling the disclosure of sensative system information. +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: 2013-04-07 +specification: + note: There was no formal specification or documentation surrounding the use of the msg variable and the need to clear the affected variable. + answer: false + 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: 2013-04-22 +curation_level: 2 +published_date: 2013-04-22 forgotten_check: + note: A value needed to be set but there was no check involved. + answer: false question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -358,9 +237,28 @@ forgotten_check: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: +autodiscoverable: + note: This vulnerability involves reading from an unassigned function parameter value, so a fuzzer could likely have discovered it. + 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, + 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: [] order_of_operations: + note: The fix was a missing line of code, and rearranging the order of operations was not involved. + answer: false question: | Does the fix for the vulnerability involve correcting an order of operations? @@ -371,109 +269,28 @@ 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: -- 200 -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: +CWE Identifier: "200" +ipc_answer: + - + - "1" +ipc_note: "" +discovered_answer: Many protocols including the IrDA protocol shared a similar + receive message function, each one with the same information leak + vulnerability. The commit merging the fix for all these together is + f89e8a6432409c6cbd5c2b6bb90ea694fd558de3, however there was no bug or email + communication marking the original discovery of this vulnerability. +discovered_automated: + - + - "1" +discovered_developer: + - + - "1" +discovered_contest: + - + - "1" +related: CVE-2013-3222, CVE-2013-3223, CVE-2013-3224, CVE-2013-3225, + CVE-2013-3226, CVE-2013-3227, CVE-2013-3229, CVE-2013-3230, CVE-2013-3231, + CVE-2013-3232, CVE-2013-3233, CVE-2013-3234, CVE-2013-3235, CVE-2013-3236, + CVE-2013-3237, CVE-2013-3076. All these vulnerabilities stemmed from the same + weakness across many protocols and they were fixed together. +bugs_repeater: [] diff --git a/cves/kernel/CVE-2020-10768.yml b/cves/kernel/CVE-2020-10768.yml index 8d420799e..2c180290e 100644 --- a/cves/kernel/CVE-2020-10768.yml +++ b/cves/kernel/CVE-2020-10768.yml @@ -1,261 +1,106 @@ CVE: CVE-2020-10768 -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: '2020-09-16' -published_instructions: | - Is there a published fix or patch date for this vulnerability? - Please enter your date in YYYY-MM-DD format. -published_date: '2020-09-16' -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 +CWE: + - 440 +ipc: No. +CVSS: 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: 4d8df8cbb9156b0a0ab3f802b80cb5db57acc0bf - 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: 9137bb27e60e554dab694eafa4cca241fa3a694f - note: Discovered automatically by archeogit. -- commit: 21998a351512eba4ed5969006f0c55882d995ada - 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: +i18n: + note: This vulnerability originates in hardware and is exploited by setting a flag in the kernel. These inputs shouldn't involve i18n. + answer: false 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. + Was the feature impacted by this vulnerability about internationalization + (i18n)? - 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? + 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. - 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. +vccs: + - commit: 9137bb27e60e554dab694eafa4cca241fa3a694f + note: Addition of the prctl function for changing Spectre v2 mitigation level. + - commit: + note: +fixes: + - commit: 4d8df8cbb9156b0a0ab3f802b80cb5db57acc0bf + note: Made by the same Google employee who reported the vulnerability initially. + - commit: + note: +vouch: + note: Thomas Gleixner was involved with, signed off on and was ultimately the one merging and approving the fixes around this vulnerability. He signed off on Anthony Steinhauser's original email and commits with fixes to the vulnerability. + answer: true + question: > + Was there any part of the fix that involved one person vouching for - The automated, contest, and developer flags can be true, false, or nil. + another's work? - 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 + 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 - In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. + Answer must be true or false. - Examples for false: RFC violations, permissions issues, anything - that requires the tool to be "aware" of the project's - domain-specific requirements. + 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: | + 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? - 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. + 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. - Be sure to check the following artifacts for this: - * bug reports - * security advisories - * commit message - * mailing lists - * anything else + Don't feel the need to claim that ALL of these apply, but it's pretty likely + that one or two of them apply. - 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: + 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: - - commit: + applies: + complex_inputs: 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: + 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: question: | Did this vulnerability violate a sandboxing feature that the system provides? @@ -268,21 +113,18 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: -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: +upvotes: "6" +CWE_note: | + Manually confirmed. +mistakes: "This vulnerability stems from a lapse during the initial + implementation of the prctl() function for checking and changing + the status of indirect branch speculation. When the function was + written, it had a force disable in mind but a check for this value was forgotten." +nickname: Stealthy Spectre +subsystem: ["Userspace API"] +discovered: Anthony Steinhauser discussion: + note: No discussion was found besides the initial notice to the team. Because Steinhauser's notice also included a fixing commit, there was likely not need for discussion. question: | Was there any discussion surrounding this? @@ -307,24 +149,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? @@ -339,8 +167,60 @@ stacktrace: what your answer was. any_stacktraces: stacktrace_with_fix: - note: +description: "Indirect branch speculation allows for Spectre v2 attacks, also + called indirect branch poisoning. These attacks, and by extension this + vulnerability, allow for user-space programs to access full system memory and + gain access to sensitive information or passwords across running programs. An + option in the Linux kernel force-disables indirect branch speculation to + prevent these attacks. A hole in force-disabling allowed it to be re-enabled + in an invisible way, where branch speculation would be reported as + force-disabled even when it was enabled." +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: "When the first commit adding the affected function was made, + it was added with documentation with how the function should work. + This documentation stated that force disabling should prevent the + speculative branching feature from being enabled again, however the + implementation did not enforce this." + 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 + 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: 2020-06-09 +curation_level: 2 +published_date: 2013-06-09 forgotten_check: + note: "The fix for this vulnerability was to add a missing conditional check for whether FORCE_DISABLED is set to an existing if-statement." + answer: true question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -358,9 +238,30 @@ forgotten_check: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: +autodiscoverable: + note: Due to the contextual nature of the bug and the conditions needed to detect and exploit the vulnerability, it is unlikely that an automated tool would have detected this vulnerability. + answer: false + 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: + - commit: 21998a351512eba4ed5969006f0c55882d995ada + note: "This commit from 1 month before adds several conditions to the affected if-statement. These appear to help mitigate related potential vulnerabilities, but it was authored a month before it was committed on the same day as the fix." order_of_operations: + note: "This was a case of an entirely missing check, and every part of the relevant conditional are OR'd together, so order of operations does not apply" + answer: false question: | Does the fix for the vulnerability involve correcting an order of operations? @@ -371,106 +272,24 @@ 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: -CWE_note: -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:H/I:N/A:N +CWE Identifier: "440" +ipc_answer: + - + - "1" +ipc_note: "" +discovered_answer: This vulnerability was discovered and reported to the Linux + kernel mailing list by Google engineer Anthony Steinhauser, who quotes + concerns about implications for Chromium's security due to this problem. It is + unclear exactly how he discovered the vulnerability initially. +discovered_automated: + - + - "1" +discovered_developer: + - + - "1" +discovered_contest: + - + - "1" +related: +bugs_repeater: [] +announced: 2020-06-09 From 284bc84a1208f9698452cf12f0001b9b1a245e2a Mon Sep 17 00:00:00 2001 From: Ash Thompson Date: Thu, 9 Nov 2023 14:16:48 -0500 Subject: [PATCH 2/8] Update cves/kernel/CVE-2013-3228.yml migrate note to correct place Co-authored-by: Andy Meneely --- cves/kernel/CVE-2013-3228.yml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2013-3228.yml b/cves/kernel/CVE-2013-3228.yml index 143fcda9b..d172793c3 100644 --- a/cves/kernel/CVE-2013-3228.yml +++ b/cves/kernel/CVE-2013-3228.yml @@ -69,7 +69,11 @@ lessons: note: applies: complex_inputs: - note: + applies: true + note: | + The msg parameter contains a large number of attributes that may not be + initialized. Needing to handle these to prevent an information leak was unclear + initially. applies:The msg parameter contains a large number of attributes that may not be initialized. Needing to handle these to prevent an information leak was unclear initially. distrust_input: note: From 649e881fdac9a64dd420ef147613779a96eabda1 Mon Sep 17 00:00:00 2001 From: Ash Thompson Date: Thu, 9 Nov 2023 14:16:59 -0500 Subject: [PATCH 3/8] Update cves/kernel/CVE-2013-3228.yml Co-authored-by: Andy Meneely --- cves/kernel/CVE-2013-3228.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/cves/kernel/CVE-2013-3228.yml b/cves/kernel/CVE-2013-3228.yml index d172793c3..60ae60c2e 100644 --- a/cves/kernel/CVE-2013-3228.yml +++ b/cves/kernel/CVE-2013-3228.yml @@ -74,7 +74,6 @@ lessons: The msg parameter contains a large number of attributes that may not be initialized. Needing to handle these to prevent an information leak was unclear initially. - applies:The msg parameter contains a large number of attributes that may not be initialized. Needing to handle these to prevent an information leak was unclear initially. distrust_input: note: applies: From dc452878b778ab0c6e9d5920869166deaa049dec Mon Sep 17 00:00:00 2001 From: Ash Thompson Date: Thu, 9 Nov 2023 15:27:35 -0500 Subject: [PATCH 4/8] Full 2013 refactor --- cves/kernel/CVE-2013-3228.yml | 623 +++++++++++++++++++++++----------- 1 file changed, 424 insertions(+), 199 deletions(-) diff --git a/cves/kernel/CVE-2013-3228.yml b/cves/kernel/CVE-2013-3228.yml index 143fcda9b..8889805a5 100644 --- a/cves/kernel/CVE-2013-3228.yml +++ b/cves/kernel/CVE-2013-3228.yml @@ -1,12 +1,256 @@ CVE: CVE-2013-3228 -CWE: - - 200 -ipc: Yes. The affected function receives messages from external IR connections. It is part of a subsystem enabling IPC. -CVSS: -bugs: [] -i18n: - note: The messages being received are not read for text data, so i18n shouldn't be an issue. +yaml_instructions: | + ================= + ===YAML Primer=== + ================= + This is a dictionary data structure, akin to JSON. + Everything before a colon is a key, and the values here are usually strings + For one-line strings, you can just use quotes after the colon + For multi-line strings, as we do for our instructions, you put a | and then + indent by two spaces + + For readability, we hard-wrap multi-line strings at 80 characters. This is + not required, but appreciated. +curated_instructions: | + If you are manually editing this file, then you are "curating" it. + + Set the version number that you were given in your instructions. + + This will enable additional editorial checks on this file to make sure you + fill everything out properly. If you are a student, we cannot accept your work + as finished unless curated is properly updated. +curation_level: 2 +reported_instructions: | + What date was the vulnerability reported to the security team? Look at the + security bulletins and bug reports. It is not necessarily the same day that + the CVE was created. Leave blank if no date is given. + + Please enter your date in YYYY-MM-DD format. +reported_date: '2013-04-07' +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: '2013-04-22' +published_instructions: | + Is there a published fix or patch date for this vulnerability? + Please enter your date in YYYY-MM-DD format. +published_date: '2013-04-22' +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: | + In the IR subsystem of the Linux kernel (IrDA), a function responsible for receiving messages + was affected by an information leak. The message variable's length property needed to be reset to 0. + Missing this value reset enabled an information leak where a small part of protected kernel memory + could be read, possibly enabling the disclosure of sensative system information. +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: ['https://bugzilla.redhat.com/show_bug.cgi?id=956069'] +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: f89e8a6432409c6cbd5c2b6bb90ea694fd558de3 + note: "Fix is merged along with the branch of similar information leak fixes." +- commit: 5ae94c0d2f0bed41d6718be743985d61b7f5c47d + note: "Initial fixing commit, manually confirmed." +vccs_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: 0dc47877a3de00ceadea0005189656ae8dc52669 + note: | + Manually confirmed. This makes a patch closeby while skipping over this + vulnerability. Note that the vulnerability existed in the kernel for the + lifetime of the IrDA module. +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: 2 +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: | + Many protocols including the IrDA protocol shared a similar + receive message function, each one with the same information leak + vulnerability. There was no bug or email + communication marking the original discovery of this vulnerability. + automated: false + contest: false + developer: true +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: true + answer: | + This vulnerability involves reading from an unassigned function parameter + value, so a fuzzer could likely have discovered it. +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: | + There was no formal specification or documentation surrounding the use of + the msg variable and the need to explicitly clear the affected attribute. answer: false +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: ["net", "IrDA"] + note: IrDA contains drivers for infrared sensors, and is a subsystem of net. +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: 0dc47877a3de00ceadea0005189656ae8dc52669 + note: | + This was a significant rewrite of the file containing the vulnerability + written in 2008. The vulnerability was not affected by this rewrite. +i18n: question: | Was the feature impacted by this vulnerability about internationalization (i18n)? @@ -18,87 +262,11 @@ i18n: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. -vccs: - - commit: 0dc47877a3de00ceadea0005189656ae8dc52669 - note: This makes a patch closeby while skipping over this vulnerability. Note that the vulnerability existed in the kernel for the lifetime of the IrDA module. -fixes: - - commit: f89e8a6432409c6cbd5c2b6bb90ea694fd558de3 - note: "Fix is merged along with the branch of similar information leak fixes." - - commit: 5ae94c0d2f0bed41d6718be743985d61b7f5c47d - note: "Initial fixing commit, manually confirmed." -vouch: - note: "The fixing commit was only signed by the committer and author." answer: false - 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. -bounty: - amt: - url: - announced: -lessons: - yagni: - note: - applies: - 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. - serial_killer: - note: - applies: - complex_inputs: - note: - applies:The msg parameter contains a large number of attributes that may not be initialized. Needing to handle these to prevent an information leak was unclear initially. - 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: [] + note: | + The messages being received are not read for text data, so i18n shouldn't + be an issue. sandbox: - note: - answer: question: | Did this vulnerability violate a sandboxing feature that the system provides? @@ -111,26 +279,27 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. -upvotes: 2 -CWE_note: | - Manually confirmed. -mistakes: This vulnerability is the result of a simple coding slip. An ambiguous - input meant it was unclear a particular value needed to be reset to 0. - Missing this value reset enabled an information leak with an unusual - attack vector that might not be considered during authoring or code reviewing - this file. Maybe with better/more accessible documentation of the details of - the ambiguous msg input, this would have been caught earlier. The fix is - simple and was able to be distributed to many affected protocols at once. Due - to the number of common protocols with the same vulnerability, it's possible - that copy-pasting was involved at some point and allowed for the proliferation - of this problem. -nickname: -subsystem: ["IrDA"] -discovered: Discovered with related vulnerabilities + answer: true + note: | + This vulnerability allowed for user space programs to read sensitive kernel + memory, which they should be unauthorized for. This violates fundemental + OS-level sandboxing. +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: true + note: | + The affected function receives messages from external IR + connections, and delivers them to the operating system. It is part of a + subsystem enabling IPC as a driver. discussion: - note: "No discussion directly related to this vulnerability. A bug report - was filed that seemed to be causing crashes in an AWS instance, but - it was unclear if this crash was due to this vulnerability." question: | Was there any discussion surrounding this? @@ -155,10 +324,33 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - any_discussion: false discussed_as_security: false + any_discussion: false + note: | + No discussion directly related to this vulnerability. A bug report + was filed that seemed to be causing crashes in an AWS instance, but + it was unclear if this crash was due to this vulnerability. +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: | + The fixing commit was signed by the author, and the committer + who would have verified the fix and is vouching for it by + making the commit. Sameul Ortiz is also notified of the fix. + Cc: Samuel Ortiz + Signed-off-by: Mathias Krause + Signed-off-by: David S. Miller stacktrace: - note: The connected bug on bugzilla seems disconnected, but also does not contain any stacktraces. question: | Are there any stacktraces in the bug reports? @@ -173,53 +365,10 @@ stacktrace: what your answer was. any_stacktraces: false stacktrace_with_fix: false -description: | - In the IR subsystem of the Linux kernel, a function responsible for receiving messages - was affected by an information leak. The message variable's length property needed to be reset to 0. - Missing this value reset enabled an information leak where a small part of protected kernel memory - could be read, possibly enabling the disclosure of sensative system information. -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: 2013-04-07 -specification: - note: There was no formal specification or documentation surrounding the use of the msg variable and the need to clear the affected variable. - answer: false - 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: 2013-04-22 -curation_level: 2 -published_date: 2013-04-22 + note: | + The connected bug on bugzilla seems disconnected, and also does not + contain any stacktraces. forgotten_check: - note: A value needed to be set but there was no check involved. - answer: false question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -237,28 +386,9 @@ 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. -autodiscoverable: - note: This vulnerability involves reading from an unassigned function parameter value, so a fuzzer could likely have discovered it. - 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, - 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: [] -order_of_operations: - note: The fix was a missing line of code, and rearranging the order of operations was not involved. answer: false + note: A value needed to be set but there was no check involved. +order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of operations? @@ -269,28 +399,123 @@ 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. -CWE Identifier: "200" -ipc_answer: - - - - "1" -ipc_note: "" -discovered_answer: Many protocols including the IrDA protocol shared a similar - receive message function, each one with the same information leak - vulnerability. The commit merging the fix for all these together is - f89e8a6432409c6cbd5c2b6bb90ea694fd558de3, however there was no bug or email - communication marking the original discovery of this vulnerability. -discovered_automated: - - - - "1" -discovered_developer: - - - - "1" -discovered_contest: - - - - "1" -related: CVE-2013-3222, CVE-2013-3223, CVE-2013-3224, CVE-2013-3225, - CVE-2013-3226, CVE-2013-3227, CVE-2013-3229, CVE-2013-3230, CVE-2013-3231, - CVE-2013-3232, CVE-2013-3233, CVE-2013-3234, CVE-2013-3235, CVE-2013-3236, - CVE-2013-3237, CVE-2013-3076. All these vulnerabilities stemmed from the same - weakness across many protocols and they were fixed together. -bugs_repeater: [] + answer: false + note: | + The fix was a missing line of code, and rearranging the order of operations + was not involved. +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: false + note: + least_privilege: + applies: false + note: + frameworks_are_optional: + applies: false + note: + native_wrappers: + applies: false + note: + distrust_input: + applies: false + note: + security_by_obscurity: + applies: false + note: + serial_killer: + applies: false + note: + environment_variables: + applies: false + note: + secure_by_default: + applies: false + note: + yagni: + applies: false + note: + complex_inputs: + applies: true + note: | + The msg parameter contains a large number of attributes that may not be + initialized. Needing to handle these to prevent an information leak was + unclear initially. +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: | + This vulnerability is the result of a simple coding slip. An ambiguous + input meant it was unclear a particular value needed to be reset to 0. + Missing this value reset enabled an information leak with an unusual + attack vector that might not be considered during authoring or code reviewing + this file. Maybe with better/more accessible documentation of the details of + the ambiguous msg input, this would have been caught earlier. The fix is + simple and was able to be distributed to many affected protocols at once. Due + to the number of common protocols with the same vulnerability, it's possible + that copy-pasting was involved at some point and allowed for the proliferation + of this problem. +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: +- 200 +CWE_note: | + 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: 'AV:L/AC:L/Au:N/C:C/I:N/A:N' \ No newline at end of file From 7490cd3c814b17132b3f2da4ca4ea826d8953da1 Mon Sep 17 00:00:00 2001 From: Ash Thompson Date: Thu, 9 Nov 2023 15:55:01 -0500 Subject: [PATCH 5/8] Fixes syntax in 2013 --- cves/kernel/CVE-2013-3228.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/cves/kernel/CVE-2013-3228.yml b/cves/kernel/CVE-2013-3228.yml index 8889805a5..b4fb7d591 100644 --- a/cves/kernel/CVE-2013-3228.yml +++ b/cves/kernel/CVE-2013-3228.yml @@ -107,9 +107,9 @@ vccs_instructions: | vccs: - commit: 0dc47877a3de00ceadea0005189656ae8dc52669 note: | - Manually confirmed. This makes a patch closeby while skipping over this - vulnerability. Note that the vulnerability existed in the kernel for the - lifetime of the IrDA module. + Manually confirmed. This makes a patch closeby while skipping over this + vulnerability. Note that the vulnerability existed in the kernel for the + lifetime of the IrDA module. upvotes_instructions: | For the first round, ignore this upvotes number. From 24c23e563e2c453a6aae059dc9114e30846ed0a1 Mon Sep 17 00:00:00 2001 From: Aaron Thompson Date: Sat, 11 Nov 2023 12:30:31 -0500 Subject: [PATCH 6/8] Revises CVE-2020-10768 document --- cves/kernel/CVE-2020-10768.yml | 647 ++++++++++++++++++++++----------- 1 file changed, 444 insertions(+), 203 deletions(-) diff --git a/cves/kernel/CVE-2020-10768.yml b/cves/kernel/CVE-2020-10768.yml index 2c180290e..2319bd62e 100644 --- a/cves/kernel/CVE-2020-10768.yml +++ b/cves/kernel/CVE-2020-10768.yml @@ -1,106 +1,298 @@ CVE: CVE-2020-10768 -CWE: - - 440 -ipc: No. -CVSS: -bugs: [] -i18n: - note: This vulnerability originates in hardware and is exploited by setting a flag in the kernel. These inputs shouldn't involve i18n. - answer: false - question: | - Was the feature impacted by this vulnerability about internationalization - (i18n)? +yaml_instructions: | + ================= + ===YAML Primer=== + ================= + This is a dictionary data structure, akin to JSON. + Everything before a colon is a key, and the values here are usually strings + For one-line strings, you can just use quotes after the colon + For multi-line strings, as we do for our instructions, you put a | and then + indent by two spaces + + For readability, we hard-wrap multi-line strings at 80 characters. This is + not required, but appreciated. +curated_instructions: | + If you are manually editing this file, then you are "curating" it. + + Set the version number that you were given in your instructions. + + This will enable additional editorial checks on this file to make sure you + fill everything out properly. If you are a student, we cannot accept your work + as finished unless curated is properly updated. +curation_level: 2 +reported_instructions: | + What date was the vulnerability reported to the security team? Look at the + security bulletins and bug reports. It is not necessarily the same day that + the CVE was created. Leave blank if no date is given. + + Please enter your date in YYYY-MM-DD format. +reported_date: '2020-06-09' +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: '2020-06-09' +published_instructions: | + Is there a published fix or patch date for this vulnerability? + Please enter your date in YYYY-MM-DD format. +published_date: '2020-06-09' +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: | + Indirect branch speculation allows for Spectre v2 attacks, also + called indirect branch poisoning. These attacks, and by extension this + vulnerability, allow for user-space programs to access full system memory and + gain access to sensitive information or passwords across running programs. An + option in the Linux kernel force-disables indirect branch speculation to + prevent these attacks. A hole in force-disabling allowed it to be re-enabled + in an invisible way, where branch speculation would be reported as + force-disabled even when it was enabled. +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? - 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. + Please list bug IDs to https://bugzilla.kernel.org/ - 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: - - commit: 9137bb27e60e554dab694eafa4cca241fa3a694f - note: Addition of the prctl function for changing Spectre v2 mitigation level. - - commit: - note: -fixes: - - commit: 4d8df8cbb9156b0a0ab3f802b80cb5db57acc0bf - note: Made by the same Google employee who reported the vulnerability initially. - - commit: - note: -vouch: - note: Thomas Gleixner was involved with, signed off on and was ultimately the one merging and approving the fixes around this vulnerability. He signed off on Anthony Steinhauser's original email and commits with fixes to the vulnerability. - answer: true - question: > - Was there any part of the fix that involved one person vouching for + 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: ['1845868'] +fixes_instructions: | + Please put the commit hash in "commit" below. - another's work? + 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: 4d8df8cbb9156b0a0ab3f802b80cb5db57acc0bf + note: | + Manually confirmed. + Made by the same Google employee who reported the vulnerability initially. +- commit: 21998a351512eba4ed5969006f0c55882d995ada + note: | + Fixes a vulnerability introduced with prctl being added as a command + line argument. +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: 9137bb27e60e554dab694eafa4cca241fa3a694f + note: | + Manually confirmed. Marks the addition of the prctl function, + which contained this vulnerability from the start. +- commit: 7cc765a67d8e04ef7d772425ca5a2a1e2b894c15 + note: | + Adds prctl as an option when Spectre v2 mitigations are being selected, + allowing the mitigation to be chosen on a per-process basis. Makes the + vulnerability from the initial prctl commit accessible. +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: 6 +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? - 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 + For code: and fix: - your answer should be boolean. - Answer must be true or false. + 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. - 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: + 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: false + code_answer: | + A unit test for this vulnerability could not be found. The Linux Test Project + also does not have tests for this vulnerability, but does have checks for Meltdown, + a related vulnerability. + fix: false + fix_answer: +discovered: 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? + 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: | + This vulnerability was discovered and reported to the Linux + kernel mailing list by Google engineer Anthony Steinhauser on 2020-06-09, who + quoted concerns about implications for Chromium's security due to this + problem. It is unclear exactly how he discovered the vulnerability initially. + News articles mentioning that this vulnerability was found were released the + same day. + automated: false + contest: false + developer: true +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. - 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. + Examples for true answers: SQL injection, XSS, buffer overflow - Don't feel the need to claim that ALL of these apply, but it's pretty likely - that one or two of them apply. + In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. - 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: + 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: | + Due to the contextual nature of the bug and the conditions needed to detect and + exploit the vulnerability, it is unlikely that an automated tool would have + detected this vulnerability. + answer: false +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: | + When the first commit adding the affected function was made, + it was added with documentation with how the function should work. + This documentation stated that force disabling should prevent the + speculative branching feature from being enabled again, however the + implementation did not enforce this. + answer: true +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: cpu + note: | + Involved with code meant to interface between OS-level processes and the CPU hardware. + Exists in a subsystem of the kernel's cpu system called "Userspace API". +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: 21998a351512eba4ed5969006f0c55882d995ada + note: | + This commit from 1 month before adds several conditions to the affected + if-statement. These appear to help mitigate related potential vulnerabilities, + but it was authored a month before it was committed on the same day as the fix. + - commit: note: - applies: -reviews: [] +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: false + note: | + This vulnerability originates in hardware and is exploited by setting a flag + in the kernel. These inputs shouldn't involve internationalization. sandbox: - note: - answer: question: | Did this vulnerability violate a sandboxing feature that the system provides? @@ -108,23 +300,32 @@ sandbox: 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. + like.o 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: "6" -CWE_note: | - Manually confirmed. -mistakes: "This vulnerability stems from a lapse during the initial - implementation of the prctl() function for checking and changing - the status of indirect branch speculation. When the function was - written, it had a force disable in mind but a check for this value was forgotten." -nickname: Stealthy Spectre -subsystem: ["Userspace API"] -discovered: Anthony Steinhauser + answer: true + note: | + The Spectre v2 vulnerability allows user-space programs to read the memory of + other user-space programs running in parallel, violating sandboxing at the + hardware level. +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: false + note: | + The affected function was responsible for getting and setting the value of a + system-level variable. This variable acted as a signal to the processor to + behave in a "safe" way. This is not exactly inter-process. discussion: - note: No discussion was found besides the initial notice to the team. Because Steinhauser's notice also included a fixing commit, there was likely not need for discussion. question: | Was there any discussion surrounding this? @@ -149,10 +350,32 @@ 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: + discussed_as_security: false + any_discussion: false + note: | + No discussion was found besides the initial notice to the team. Because + Steinhauser's notice also included a fixing commit, there was likely not need + for discussion. +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: true + note: | + Thomas Gleixner was involved with, signed off on and was ultimately the one + merging and approving the fixes around this vulnerability. He signed off on + Anthony Steinhauser's original email and commits with fixes to the vulnerability. + Signed-off-by: Anthony Steinhauser + Signed-off-by: Thomas Gleixner stacktrace: - note: question: | Are there any stacktraces in the bug reports? @@ -165,62 +388,11 @@ stacktrace: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - any_stacktraces: - stacktrace_with_fix: -description: "Indirect branch speculation allows for Spectre v2 attacks, also - called indirect branch poisoning. These attacks, and by extension this - vulnerability, allow for user-space programs to access full system memory and - gain access to sensitive information or passwords across running programs. An - option in the Linux kernel force-disables indirect branch speculation to - prevent these attacks. A hole in force-disabling allowed it to be re-enabled - in an invisible way, where branch speculation would be reported as - force-disabled even when it was enabled." -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: "When the first commit adding the affected function was made, - it was added with documentation with how the function should work. - This documentation stated that force disabling should prevent the - speculative branching feature from being enabled again, however the - implementation did not enforce this." - 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 - 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: 2020-06-09 -curation_level: 2 -published_date: 2013-06-09 + any_stacktraces: false + stacktrace_with_fix: false + note: | + The bug was reported with a fix, and no stacktraces were included. forgotten_check: - note: "The fix for this vulnerability was to add a missing conditional check for whether FORCE_DISABLED is set to an existing if-statement." - answer: true question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -238,30 +410,11 @@ 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. -autodiscoverable: - note: Due to the contextual nature of the bug and the conditions needed to detect and exploit the vulnerability, it is unlikely that an automated tool would have detected this vulnerability. - answer: false - 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: - - commit: 21998a351512eba4ed5969006f0c55882d995ada - note: "This commit from 1 month before adds several conditions to the affected if-statement. These appear to help mitigate related potential vulnerabilities, but it was authored a month before it was committed on the same day as the fix." + answer: true + note: | + The fix for this vulnerability was to add a missing conditional check to an + existing if-statement. order_of_operations: - note: "This was a case of an entirely missing check, and every part of the relevant conditional are OR'd together, so order of operations does not apply" - answer: false question: | Does the fix for the vulnerability involve correcting an order of operations? @@ -272,24 +425,112 @@ 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. -CWE Identifier: "440" -ipc_answer: - - - - "1" -ipc_note: "" -discovered_answer: This vulnerability was discovered and reported to the Linux - kernel mailing list by Google engineer Anthony Steinhauser, who quotes - concerns about implications for Chromium's security due to this problem. It is - unclear exactly how he discovered the vulnerability initially. -discovered_automated: - - - - "1" -discovered_developer: - - - - "1" -discovered_contest: - - - - "1" -related: -bugs_repeater: [] -announced: 2020-06-09 + answer: false + note: | + This was a case of an entirely missing check, and every part of the relevant + conditional is OR'd together, so order of operations does not apply +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: | + This vulnerability stems from a lapse during the initial + implementation of the prctl() function for checking and changing + the status of indirect branch speculation. When the function was + written, it had a force disable in mind but a check for this value was forgotten. +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: 440 +CWE_note: +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: 'Stealthy Spectre' +CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N \ No newline at end of file From 27f218e4dd92fca657f7283ceb42837389860d4b Mon Sep 17 00:00:00 2001 From: Aaron Thompson Date: Sat, 11 Nov 2023 12:52:11 -0500 Subject: [PATCH 7/8] Minor additions for CVE-2013-3228 --- cves/kernel/CVE-2013-3228.yml | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/cves/kernel/CVE-2013-3228.yml b/cves/kernel/CVE-2013-3228.yml index b4fb7d591..7c5a982bc 100644 --- a/cves/kernel/CVE-2013-3228.yml +++ b/cves/kernel/CVE-2013-3228.yml @@ -132,10 +132,12 @@ unit_tested: For the fix_answer below, check if the fix for the vulnerability involves adding or improving an automated test to ensure this doesn't happen again. - code: - code_answer: - fix: - fix_answer: + code: false + code_answer: | + This aspect of the original code was not unit tested. + fix: false + fix_answer: | + The fix did not involve adding an automated test for related issues. discovered: question: | How was this vulnerability discovered? @@ -230,8 +232,10 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: ["net", "IrDA"] - note: IrDA contains drivers for infrared sensors, and is a subsystem of net. + name: net + note: | + IrDA contains drivers for infrared sensors, and is a subsystem of the kernel's + networking (net) subsystem interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -342,7 +346,7 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: + answer: true note: | The fixing commit was signed by the author, and the committer who would have verified the fix and is vouching for it by From 67350b185c731b0455baed825085036b6d569016 Mon Sep 17 00:00:00 2001 From: Aaron Thompson Date: Sat, 11 Nov 2023 12:59:36 -0500 Subject: [PATCH 8/8] Minor YAML syntax fix --- cves/kernel/CVE-2013-3228.yml | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/cves/kernel/CVE-2013-3228.yml b/cves/kernel/CVE-2013-3228.yml index 7c5a982bc..2b5d3b196 100644 --- a/cves/kernel/CVE-2013-3228.yml +++ b/cves/kernel/CVE-2013-3228.yml @@ -152,14 +152,12 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: | - Many protocols including the IrDA protocol shared a similar + answer: 'Many protocols including the IrDA protocol shared a similar receive message function, each one with the same information leak - vulnerability. There was no bug or email - communication marking the original discovery of this vulnerability. + vulnerability. These were discovered together.' automated: false contest: false - developer: true + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -176,10 +174,10 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: true - answer: | + note: | This vulnerability involves reading from an unassigned function parameter value, so a fuzzer could likely have discovered it. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -391,7 +389,8 @@ forgotten_check: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: false - note: A value needed to be set but there was no check involved. + note: | + A value needed to be set but there was no check involved. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of