diff --git a/cves/kernel/CVE-2012-6545.yml b/cves/kernel/CVE-2012-6545.yml index 511e7c715..ce1f75795 100644 --- a/cves/kernel/CVE-2012-6545.yml +++ b/cves/kernel/CVE-2012-6545.yml @@ -19,7 +19,7 @@ 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 @@ -34,7 +34,7 @@ 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: '2013-03-15' +announced_date: '2013-03-05' published_instructions: | Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. @@ -55,7 +55,10 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + Memory on an object was not being initialized correctly, which meant the memory was + being leaked. A well thought out program could use this to read + sensitive information. This was a violation of confidentiality. 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,22 +87,12 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: - commit: 9344a972961d1a6d2c04d9008b13617bcb6ec2ef - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + note: 'Manually confirmed' - commit: f9432c5ec8b1e9a09b9b0e5569e3c73db8de432a - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + note: 'Manually confirmed' - commit: 9ad2de43f1aee7e7274a4e0d41465489299e344b - 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. @@ -128,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: 2 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -143,10 +136,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: | + No tests found. + fix: false + fix_answer: | + No tests found. discovered: question: | How was this vulnerability discovered? @@ -161,10 +156,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: | + It seems this was a minor memory leak discovered and fixed by a developer. + The only written history on this are the git commits, and this email sent + by the developer who fixed it: https://www.openwall.com/lists/oss-security/2013/03/05/13. + It was small enough to go unreported for around 7 months. + automated: false + contest: false + developer: true autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -181,8 +180,11 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + This was a simple memory leak, so some a memory profiler could + have found this. Some code review tools might have been able to pick up on the + missed memory allocation as well. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -198,8 +200,9 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + No specific specifications were mentioned in any documentation. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -233,8 +236,9 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: ['drivers', 'bluetooth'] + note: | + This mistake dealt with connecting to bluetooth. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -265,8 +269,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: | + There was no note of internationalization, and this problem had little to + no connection to user-language input. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -280,8 +286,10 @@ 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 mistake dealt with the system's memory. There was no explicit intent + to limit access. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -292,8 +300,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: | + This mistake dealt with the overall memory of the system. It left info + open to be read, but it directly did not have to do with the + communication between processes. discussion: question: | Was there any discussion surrounding this? @@ -319,9 +330,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: false + any_discussion: true + note: | + The only discussion had to do with making a CVE out of the mistake: + https://www.openwall.com/lists/oss-security/2013/03/05/13 vouch: question: | Was there any part of the fix that involved one person vouching for @@ -334,8 +347,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: false + note: | + The only correspondence between two people were questions regarding publishing + the mistake as a CVE. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -349,9 +364,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 fix went unnoticed for 7 months. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -370,8 +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. - answer: - note: + answer: true + note: | + The fix was just making sure the memory was set and accounted for. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -383,8 +400,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: | + Things were still done in the same order as before the fix. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -401,37 +419,37 @@ 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: + applies: false note: mistakes: question: | @@ -462,7 +480,11 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + The main mistake here was a lapse in managing memory. The developer forgot + to initialize data on an object. This could leak to a memory leak, + which could be read by other processes. If a developer can make + sure their memory is accounted for, they should be ok. 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 @@ -480,9 +502,7 @@ CWE_instructions: | 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". +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. diff --git a/cves/kernel/CVE-2014-2851.yml b/cves/kernel/CVE-2014-2851.yml index c186fae84..2ee18764c 100644 --- a/cves/kernel/CVE-2014-2851.yml +++ b/cves/kernel/CVE-2014-2851.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: '2014-04-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,10 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + There were improper counters in a for loop, possibly leading to integer overflow. + A counter for an object was incremented, but never decremented. + This could be used to gain elevated privileges, or cause denial of service. 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 +78,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: [1086730] fixes_instructions: | Please put the commit hash in "commit" below. @@ -84,10 +87,6 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: - commit: b04c46190219a4f845e46a459e3102137b7f6cac note: | Taken from NVD references list with Git commit. If you are @@ -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: 3 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -133,9 +132,9 @@ 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: false code_answer: - fix: + fix: false fix_answer: discovered: question: | @@ -151,10 +150,13 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: | + According to Petr Matousek on 2014-04-11 at 11:50:15 UTC, the bug was simply + discovered (https://www.openwall.com/lists/oss-security/2014/04/11/3). A proposed + patch was given at the same time. Somebody must have caught it during development. + automated: false + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -171,8 +173,10 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + It is possible, since this is an integer overflow. Some kind of tool could + have been used to check the code for something like this. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -188,8 +192,9 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + There was no mention of any specifications. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -223,8 +228,9 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: ['net', 'ipv4'] + note: | + This was found in the net/ip4/ping.c file. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -255,8 +261,9 @@ 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 mistake did not have to do with language based user input. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -270,8 +277,9 @@ 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 mistake had to do with memory management. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -282,8 +290,9 @@ 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: | + This mistake had to do with memory management. discussion: question: | Was there any discussion surrounding this? @@ -309,9 +318,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: + discussed_as_security: false + any_discussion: false + note: | + There was only one message about this, and it was simply informational. vouch: question: | Was there any part of the fix that involved one person vouching for @@ -324,8 +334,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: false + note: | + The fix was pretty much supplied on discovery, from the looks of things. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -339,9 +350,23 @@ 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: | + There is an example trace in the message attached to the proposed solution: + + unreferenced object 0xcd0e8840 (size 192): + comm "dumpstate", pid 7583, jiffies 78360 (age 91.810s) + hex dump (first 32 bytes): + 02 00 00 00 06 00 00 00 01 00 00 00 ef 03 00 00 ................ + f1 03 00 00 f7 03 00 00 04 04 00 00 bb 0b 00 00 ................ + backtrace: + [] kmemleak_alloc+0x3c/0xa0 + [] __kmalloc+0xe7/0x1d0 + [] groups_alloc+0x34/0xb0 + [] SyS_setgroups+0x3c/0xf0 + [] syscall_call+0x7/0xb + [] 0xffffffff forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -360,8 +385,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: true + note: | + The solution involves keeping better track of a pointer in a loop. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -373,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: true + note: | + The solution invovles referencing a pointer later in the code. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -391,37 +418,37 @@ 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: + applies: false note: mistakes: question: | @@ -452,7 +479,9 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + This was a lapse in memory management. The developer mistakenly referenced + an object that could point to unmanaged memory. This can cause a memory leak. 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