diff --git a/cves/kernel/CVE-2017-18549.yml b/cves/kernel/CVE-2017-18549.yml index 39b92a6fd..66a8ceffd 100644 --- a/cves/kernel/CVE-2017-18549.yml +++ b/cves/kernel/CVE-2017-18549.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: 2017-06-23 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,13 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + RAM is (virtually) segregated into two parts, the Kernelspace (where privileged kernel programs and drivers run) + and the Userspace (where regular user software runs). In C, an uninitiated variable points to the address allocated in the Kernelspace, + and the variable holds whatever was in there from before (which could be sensitive information). + In this vulnerability this uninitialized variable's data is sent from the Kernelspace into the Userspace. + This data can contain important information which could be used maliciously if it is passed to the Userspace. + 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 +81,8 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: + - "https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1700077" fixes_instructions: | Please put the commit hash in "commit" below. @@ -116,7 +123,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: 5 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -131,10 +138,16 @@ 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: | + Generally the linux kernel is tested using the KUnit test suite. + However, I couldn't find any unit tests for the commctrl.c file. Interestingly, in the same folder, + there is a "TODO" file which says "Testing, More Testing, I/O Size Increase". + This suggests that unit tests were not conducted fro this file. + fix: false + fix_answer: | + Unit tests (most likely) would not help detect such vulnerabilities since if the variable is uninitalized, + it still points to a value (in C). If it were null (like in most other languages), then unit tests could have been used. discovered: question: | How was this vulnerability discovered? @@ -149,10 +162,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: | + "I was unable to find how the vulnerability was discovered. I + looked at the vulnerability on the NIST NVD database and also looked for it in + the commit. I even checked the linux kernel hypermail, but my search led me + nowhere. I do know that it was discovered by Seth Forshee. There is no + indication of it being found by automated means or its discovery being + associated with a competition. " + automated: false + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -169,8 +188,12 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + It is unlikely that it was discovered through automated means or a fuzzer. + This is an issue in the code. It pertains to an uninitialized variable resulting in a memory leak to the userspace. + There is no compiler warning or error message indicating that there was a memory leak, + which makes it difficult to automated tools to detect. (although AddressSantitizer could potencially be used to detect memory leaks). + answer: false specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -186,8 +209,9 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + "No indication of any specification violations. I checked commit, the mailing lists and bug reports" + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -221,8 +245,9 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: drivers + note: | + The file commctrl.c is in the 'drivers' directory, which means it pertains to the drivers subsystem. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -241,6 +266,13 @@ interesting_commits: note: - commit: note: + - commit: 5cc973f09e21b5a2f746307641879bc9f1da623b + note: | + This was this commit right before the error was fixed. This also involves a memory leak into the userspace. + Here, a variable was uninitialized and its contents were being written to the userspace. Based on the nature of the error, + it seems that it is quite common. The issue is that an uninitialized variable will always contain a garbage value from the kernel stack. + This 'garbage' can contain important information which could be used maliciously if it is passed to the userspace, + where it is more accessible to users and attackers. i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -253,8 +285,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 is about potentially sensitive information being passed from the kernelspace to the userspace. + It doesn't particularly involve internationalization. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -268,8 +302,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: Not a sandboxing vulnerability, since it pertains to a memory leak to the userspace, which is not access control realted. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -280,8 +314,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 directly writing to the userspace in RAM. + There is no inter process communication that was affected by this. discussion: question: | Was there any discussion surrounding this? @@ -307,9 +343,11 @@ 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: true + any_discussion: true + note: | + They discussed about how zeroing out the variable would prevent the issue from occurring. + Link: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-18549 vouch: question: | Was there any part of the fix that involved one person vouching for @@ -322,8 +360,9 @@ 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: | + Commit Signed off by Martin K. Petersen stacktrace: question: | Are there any stacktraces in the bug reports? @@ -337,9 +376,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: | + No stack trace was found, probably because the vulnerability involves a data leak which shouldn't result in a compiler error. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -358,8 +398,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: | + Checks would not particularly be helpful as the uninitialized variable still contains data from the kernel stack. + Traditionally we would check if the variable is 'null' to see if its uninitialized, but that doesn't apply here. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -371,8 +413,9 @@ 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 involves zeroing the variable out, if it is uninitiated. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -389,8 +432,12 @@ 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: | + Even if sensitive data from the kernelspace is leaked into the userspace, + a regular user wouldn't likely come across it or obtain it through a program, + only someone with malicious intent would do such a thing. + However, preventing such leakes in the first place would eliminate this issue altogether. least_privilege: applies: note: @@ -450,7 +497,10 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + I thing the mistake made here would be categorized as a lapse, + since there the developer forgot to zero out the memory of the + uninitialized variable before its passed on to the userspace. 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 @@ -475,5 +525,5 @@ nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. -nickname: -CVSS: +nickname: Data leak to Userspace +CVSS: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N diff --git a/cves/kernel/CVE-2018-13406.yml b/cves/kernel/CVE-2018-13406.yml index 268259c8d..ba812c1b5 100644 --- a/cves/kernel/CVE-2018-13406.yml +++ b/cves/kernel/CVE-2018-13406.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: 2018-05-11 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,13 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + This vulnerability involves a potential issue with integer + overflow, when an integer's exceeds its maximum size and overwrites adjacent + memory. The variable "cmap->len" is multiplied, such that it can result in a + number larger than INT_MAX (the maximum size of an integer), resulting in an + integer overflow. This could potentially be used for a Denial of service + attack (crashing the Kernel) or even escalation of privilege. 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 +81,8 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: + - "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-13406" fixes_instructions: | Please put the commit hash in "commit" below. @@ -114,7 +121,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? @@ -129,10 +136,15 @@ 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: true + code_answer: | + Generally the linux kernel is tested using the KUnit test suite. + However I couldn't find any unit tests in the drivers/video/ directory. + Unit Tests were not involved in this vulnerability. + fix: true + fix_answer: | + unit tests could be written to check if the int value is high enough to result in an over flow after it is used in calculation. + discovered: question: | How was this vulnerability discovered? @@ -147,10 +159,11 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: | + Unable to find discovery method. Mailing lists, commit logs and other forums were checked. + automated: false + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -167,8 +180,13 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + A fuzzer of automated tool could potentially find out about this vulnerability, + since it could check how the system responds to an input. + In this case, the fuzzer would enter an integer (or an input which affects the 'loc' variable + in that part of code) and it would result in the system crashing, + which would point towards this vulnerability. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -184,8 +202,9 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + No indication of any specification/standards violation found in records and discussion. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -219,8 +238,8 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: drivers + note: The file with this vulnerability is in the 'drivers' directory, which means it pertains to the drivers subsystem. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -237,8 +256,12 @@ interesting_commits: commits: - commit: note: - - commit: - note: + - commit: 353748a359f1821ee934afc579cf04572406b420 + note: | + This commit was authored right before the this vulnerability was found. + It also pertains to an intger overflow. This goes to show how common theese types of vulnerabilities are/ + Given how impactful they can be, we should frequently check and cross-check our code overflows. + i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -251,8 +274,8 @@ i18n: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: This vulnerability pertains to integer overflow. There is no obvious connection to internationalization. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -266,8 +289,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: This is not a sandbox vulnerability as it doesn't involve access controll. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -278,8 +301,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 pertains to an overflow in memory, which results in + a crash or an elevation of privilege." discussion: question: | Was there any discussion surrounding this? @@ -305,9 +330,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: true + any_discussion: true + note: + - https://lists.debian.org/debian-lts-announce/2019/03/msg00017.html + - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-13406 + - https://ubuntu.com/security/notices/USN-3752-3 vouch: question: | Was there any part of the fix that involved one person vouching for @@ -320,8 +348,8 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: Kees Cook Signed off the commit. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -335,9 +363,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: None were found, Integer overflows can produce stacktraces, howerver, I checked mailing lists and bug reports but was unable to find any. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,8 +384,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 developer forgot to check if the size of the integer would result in an overflow after it is run through calculations. + Using kmalloc_array() solved this issue as it checks for this and catches the condition. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -369,8 +399,9 @@ 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: | + No, since the issue with this vulnerability is about checking the size of the integer. kmalloc_array() is used for this fix. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -399,8 +430,10 @@ lessons: applies: note: distrust_input: - applies: - note: + applies: true + note: | + Here, the integer value could have been such that it exceeds the maximum INT size. + Inputs, even from other feeder functions should not be trusted and checks should be done to ensure they don't pose a threat. security_by_obscurity: applies: note: @@ -448,7 +481,11 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + The main mistake made here was not taking into account how the + multiplication could result in an integer exceeding the maximum INT value and + causing an integer overflow. Checks should be made to ensure that Integers (or + even floats) do not cause overflows during calculations. 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 @@ -473,5 +510,5 @@ nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. -nickname: +nickname: Integer Overflow Danger CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H