diff --git a/cves/kernel/CVE-2013-3228.yml b/cves/kernel/CVE-2013-3228.yml index 7c246cf5b..2b5d3b196 100644 --- a/cves/kernel/CVE-2013-3228.yml +++ b/cves/kernel/CVE-2013-3228.yml @@ -19,14 +19,14 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that the CVE was created. Leave blank if no date is given. Please enter your date in YYYY-MM-DD format. -reported_date: +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. @@ -55,7 +55,11 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +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 @@ -75,7 +79,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: ['https://bugzilla.redhat.com/show_bug.cgi?id=956069'] fixes_instructions: | Please put the commit hash in "commit" below. @@ -84,15 +88,11 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: +- commit: f89e8a6432409c6cbd5c2b6bb90ea694fd558de3 + note: "Fix is merged along with the branch of similar information leak fixes." - 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: | + 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 @@ -105,10 +105,11 @@ vcc_instructions: | 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. + 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. @@ -116,7 +117,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: +upvotes: 2 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -131,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? @@ -149,10 +152,12 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: 'Many protocols including the IrDA protocol shared a similar + receive message function, each one with the same information leak + vulnerability. These were discovered together.' + automated: false + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -169,8 +174,10 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - 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 @@ -186,8 +193,10 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + 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 @@ -221,8 +230,10 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + 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)? @@ -237,10 +248,10 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: - - commit: - note: + - 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 @@ -253,8 +264,10 @@ i18n: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + The messages being received are not read for text data, so i18n shouldn't + be an issue. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -268,8 +281,11 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + 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 @@ -280,8 +296,11 @@ ipc: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + 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: question: | Was there any discussion surrounding this? @@ -307,9 +326,12 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: - any_discussion: - note: + discussed_as_security: false + any_discussion: false + note: | + 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 @@ -322,8 +344,14 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: 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 + 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: question: | Are there any stacktraces in the bug reports? @@ -337,9 +365,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: - note: + any_stacktraces: false + stacktrace_with_fix: false + note: | + The connected bug on bugzilla seems disconnected, and also does not + contain any stacktraces. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -358,8 +388,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. - answer: - note: + 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 @@ -371,8 +402,10 @@ order_of_operations: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + 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 @@ -389,38 +422,41 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. defense_in_depth: - applies: + applies: false note: least_privilege: - applies: + applies: false note: frameworks_are_optional: - applies: + applies: false note: native_wrappers: - applies: + applies: false note: distrust_input: - applies: + applies: false note: security_by_obscurity: - applies: + applies: false note: serial_killer: - applies: + applies: false note: environment_variables: - applies: + applies: false note: secure_by_default: - applies: + applies: false note: yagni: - applies: + applies: false note: complex_inputs: - applies: - 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. mistakes: question: | In your opinion, after all of this research, what mistakes were made that @@ -450,7 +486,17 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + 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 @@ -469,11 +515,10 @@ CWE_instructions: | 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". + 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: +nickname: +CVSS: 'AV:L/AC:L/Au:N/C:C/I:N/A:N' \ No newline at end of file diff --git a/cves/kernel/CVE-2020-10768.yml b/cves/kernel/CVE-2020-10768.yml index 8d420799e..2319bd62e 100644 --- a/cves/kernel/CVE-2020-10768.yml +++ b/cves/kernel/CVE-2020-10768.yml @@ -19,14 +19,14 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that the CVE was created. Leave blank if no date is given. Please enter your date in YYYY-MM-DD format. -reported_date: +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. @@ -34,11 +34,11 @@ announced_instructions: | 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' +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-09-16' +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. @@ -55,7 +55,15 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +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 @@ -75,7 +83,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: ['1845868'] fixes_instructions: | Please put the commit hash in "commit" below. @@ -84,14 +92,14 @@ fixes_instructions: | 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' + 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. @@ -106,9 +114,14 @@ vcc_instructions: | 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. + 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. @@ -116,7 +129,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: +upvotes: 6 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -131,9 +144,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: + 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: | @@ -149,10 +165,16 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + 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 @@ -169,8 +191,11 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + 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 @@ -186,8 +211,13 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + 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 @@ -221,8 +251,10 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + 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)? @@ -237,8 +269,11 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: + - 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: i18n: @@ -253,8 +288,10 @@ i18n: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + This vulnerability originates in hardware and is exploited by setting a flag + in the kernel. These inputs shouldn't involve internationalization. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -263,13 +300,16 @@ 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. - answer: - note: + 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 @@ -280,8 +320,11 @@ ipc: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + 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: question: | Was there any discussion surrounding this? @@ -307,9 +350,12 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: - any_discussion: - note: + discussed_as_security: false + any_discussion: false + note: | + 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 @@ -322,8 +368,13 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: 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: question: | Are there any stacktraces in the bug reports? @@ -337,9 +388,10 @@ stacktrace: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - any_stacktraces: - stacktrace_with_fix: - note: + any_stacktraces: false + stacktrace_with_fix: false + note: | + The bug was reported with a fix, and no stacktraces were included. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -358,8 +410,10 @@ forgotten_check: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + The fix for this vulnerability was to add a missing conditional check to an + existing if-statement. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -371,8 +425,10 @@ order_of_operations: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + 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 @@ -450,7 +506,11 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + 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 @@ -466,11 +526,11 @@ CWE_instructions: | CWE: ["123", "456"] # this is ok CWE: [123, 456] # also ok CWE: 123 # also ok -CWE: -CWE_note: +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: -CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N +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