diff --git a/cves/kernel/CVE-2016-3135.yml b/cves/kernel/CVE-2016-3135.yml index c2935ddbe..8fb6bf374 100644 --- a/cves/kernel/CVE-2016-3135.yml +++ b/cves/kernel/CVE-2016-3135.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: '2016-03-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. @@ -55,7 +55,14 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + The vulnerability occurred during memory allocation where the size of the + object being allocated was not properly checked. If the requested size of + the allocation was too small, the memory heap (The place where programs + store information) could be corrupted due to integer overflow. Integer + overflow is where the size of an integer is greater than the memory + allocated for it and can corrupt other pieces of information within the heap. + This can lead to various attacks all throughout the system. bounty_instructions: | If you came across any indications that a bounty was paid out for this vulnerability, fill it out here. Or correct it if the information already here @@ -84,14 +91,8 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: - commit: d157bd761585605b7882935ffb86286919f62ea1 - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + note: 'Manually Confirmed' vcc_instructions: | The vulnerability-contributing commits. @@ -106,11 +107,9 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: - commit: 2e4e6a17af35be359cc8f1c924f8f198fbd478cc - note: Discovered automatically by archeogit. + note: 'Manually Confirmed' - commit: 711bdde6a884354ddae8da2fcb495b2a9364cc90 - note: Discovered automatically by archeogit. -- commit: 4481374ce88ba8f460c8b89f2572027bd27057d0 - note: Discovered automatically by archeogit. + note: 'Manually Confirmed' upvotes_instructions: | For the first round, ignore this upvotes number. @@ -118,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: 4 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -133,10 +132,10 @@ unit_tested: For the fix_answer below, check if the fix for the vulnerability involves adding or improving an automated test to ensure this doesn't happen again. - code: - code_answer: - fix: - fix_answer: + code: false + code_answer: 'No tests were checking for this case or the surroundings.' + fix: false + fix_answer: 'No tests added or improved as a result of this vulnerability.' discovered: question: | How was this vulnerability discovered? @@ -151,10 +150,14 @@ 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 found by a Google employee working on Project Zero. + They informed the Linux team on 2016-03-09 of two vulnerabilities including + this one and gave the dev team 90 days to fix the issue before it would + go public. + automated: false + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -171,8 +174,13 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + The developer could use tools to discover the potential for integer + overflow. Since the problem was a common missing check, tools have + been developed that can detect these issues. A fuzzing tool could input + values that typically cause integer overflows and the vulnerability could + have been spotted earlier. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -188,8 +196,8 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: 'No mention of specification violations.' + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -223,8 +231,9 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: ["net", "netfilter"] + note: | + The vulnerability takes place within both net and netfilter subsystems. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -240,9 +249,9 @@ interesting_commits: * Anything else you find interesting. commits: - commit: - note: - - commit: - note: + note: | + No interesting commits or conversations between the fixers and + the VCC. i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -255,8 +264,8 @@ i18n: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: It does not involve translation or unicode problems. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -270,8 +279,12 @@ 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: | + It is mentioned that the memory heap corruption could be used to + gain privileges. This can be done by manipulating environment variables + or taking information leaking from the heap to gain privileges. + ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -282,8 +295,10 @@ 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 vulnerability involves sockets although the issue + is not an IPC problem directly. discussion: question: | Was there any discussion surrounding this? @@ -309,9 +324,9 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: - any_discussion: - note: + discussed_as_security: false + any_discussion: false + note: 'No discussions about this vulnerability.' vouch: question: | Was there any part of the fix that involved one person vouching for @@ -324,8 +339,10 @@ 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 commits reference advice from Ben Hawkes (Google employee) and there are sign-offs + from Florian Westphal and Pablo Neira Ayuso. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -339,9 +356,9 @@ stacktrace: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - any_stacktraces: - stacktrace_with_fix: - note: + any_stacktraces: false + stacktrace_with_fix: false + note: 'No stacktraces are mentioned.' forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -360,8 +377,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 involves a small if statement that checks whether the size + of the memory allocated for the object is correct. If not, it returns NULL. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -373,8 +392,8 @@ order_of_operations: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: 'The order of operations stay the same.' lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -391,38 +410,45 @@ 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: - note: + applies: true + note: | + More layers of defense could have been in place. Once this one part + fails, a lot of issues could arise. least_privilege: - applies: + applies: false note: frameworks_are_optional: - applies: + applies: false note: native_wrappers: - applies: + applies: false note: distrust_input: - applies: - note: + applies: true + note: | + The size to allocate memory for was not distrusted and invalid values + could be entered into it creating heap corruption. The fix involved + lowering the trust. 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: | + Unintended inputs were not being checked which led to this + vulnerability. mistakes: question: | In your opinion, after all of this research, what mistakes were made that @@ -452,7 +478,14 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + The mistake made is one that all coders run into at some point. Failing + to recognize situations where inputs could break the system is easy to + come across and often takes a lot of extra time and brainpower to find. + This vulnerability seems to have been brought about by a small lapse in + attention that had far-reaching consequences. The CWE-190 suggests + mitigations like strictly defining the bounds and this was not performed + correctly until the fix. 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,7 +502,7 @@ CWE_instructions: | CWE: [123, 456] # also ok CWE: 123 # also ok CWE: -- 189 +- [189, 190] CWE_note: | CWE as registered in the NVD. If you are curating, check that this is correct and replace this comment with "Manually confirmed". diff --git a/cves/kernel/CVE-2022-1975.yml b/cves/kernel/CVE-2022-1975.yml index f670f5781..c747cae3a 100644 --- a/cves/kernel/CVE-2022-1975.yml +++ b/cves/kernel/CVE-2022-1975.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: '2022-05-04' 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,15 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + The vulnerability occurred when the Linux kernel didn't prevent + context switches (When a CPU switches tasks/processes) during + certain operations that should have been resolved uninterrupted. + An incorrect flag was set that gave instructions on how memory allocation + should be performed. It allowed sleeping (When a task/process waits for + a given amount of time in seconds) during the memory allocation. + This made it possible for the context to switch during a vulnerable + state which triggers an expectation that goes uncaught. 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: ['4071bf121d59944d5cd2238de0642f3d7995a997'] fixes_instructions: | Please put the commit hash in "commit" below. @@ -84,14 +92,8 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: - commit: 4071bf121d59944d5cd2238de0642f3d7995a997 - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + note: 'Manually Confirmed' vcc_instructions: | The vulnerability-contributing commits. @@ -106,9 +108,7 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: - commit: 9674da8759df0d6c0d24e1ede6e2a1acdef91e3c - note: Discovered automatically by archeogit. -- commit: 2a94fe48f32ccf7321450a2cc07f2b724a444e5b - note: Discovered automatically by archeogit. + note: 'Manually Confirmed' upvotes_instructions: | For the first round, ignore this upvotes number. @@ -116,7 +116,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: 9 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -131,10 +131,10 @@ unit_tested: For the fix_answer below, check if the fix for the vulnerability involves adding or improving an automated test to ensure this doesn't happen again. - code: - code_answer: - fix: - fix_answer: + code: false + code_answer: 'No tests were checking for this case or the surroundings.' + fix: false + fix_answer: 'No tests added or improved as a result of this vulnerability.' discovered: question: | How was this vulnerability discovered? @@ -149,10 +149,14 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: | + The vulnerability appears to have been discovered by a developer who was + looking for potential problems. This appears to be the case as the fix + was quickly added on 2022-05-05. The emails from the key developer list + the bug, its effects, and how they found it. They do not work for Google. + automated: false + contest: false + developer: true autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -169,8 +173,10 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + The vulnerability requires knowledge of the domain to execute the + problem and it requires a high amount of complexity. + answer: false specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -186,8 +192,8 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: 'No mention of specification violations.' + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -221,8 +227,10 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: net + note: | + The vulnerability occurs within net/nfc/ and multiple emails + and reports mention it. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -237,10 +245,10 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: - - commit: - note: + - commit: 4071bf121d59944d5cd2238de0642f3d7995a997 + note: | + No communication between the VCC and the fix. The original vulnerability + implementation occurred nine years previous to the fix. i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -253,8 +261,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: | + No, as it is a problem caused by sleeping and context switching. + It has nothing to do with il8n. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -268,8 +278,8 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: 'The vulnerability does not violate any access controls or privileges.' ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -280,8 +290,10 @@ 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 vulnerability involves the Netlink socket family. It occurs during + the firmware download process where NFC devices are communicating together. discussion: question: | Was there any discussion surrounding this? @@ -307,9 +319,9 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: - any_discussion: - note: + discussed_as_security: false + any_discussion: false + note: 'No discussion took place. The issue was spotted and fixed quickly.' vouch: question: | Was there any part of the fix that involved one person vouching for @@ -322,8 +334,11 @@ 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: | + Within the commit, it mentions being reviewed and signed off + by additional people. Reviewed by Krzysztof Kozlowski and sign-off by + Paolo Abeni and Duoming Zhou. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -337,9 +352,9 @@ stacktrace: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - any_stacktraces: - stacktrace_with_fix: - note: + any_stacktraces: true + stacktrace_with_fix: true + note: 'The fix mentions the stacktrace which points clearly to the fix file.' forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -358,8 +373,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: false + note: | + The fix was more about restricting the operation options rather + than checking fail cases. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -371,8 +388,11 @@ order_of_operations: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + The fix for the vulnerability made sure the memory allocation + occurred first and without interruption. The original issue + was that the allocation wasn't finished when contexts were switched. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -389,37 +409,40 @@ 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: - note: + applies: true + note: | + The solution involves reinstructing memory allocation and how it should + operate or else it can cause a fatal error. Maybe the lower-level issues + should be solved rather than patching up the symptoms. yagni: - applies: + applies: false note: complex_inputs: - applies: + applies: false note: mistakes: question: | @@ -450,7 +473,10 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + The mistake seems to originate from a small lapse of understanding. If the + VCC understood the purpose of the different memory allocation flag + options, they might have been able to detect the vulnerability beforehand. 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,8 +492,8 @@ CWE_instructions: | CWE: ["123", "456"] # this is ok CWE: [123, 456] # also ok CWE: 123 # also ok -CWE: -CWE_note: +CWE: 248 +CWE_note: 'The final result of the vulnerability is an uncaught exception.' nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that.