From d22b44de89d9243ec30b1dcf56c6aa2038645355 Mon Sep 17 00:00:00 2001 From: Patrick Sorensen Date: Mon, 6 Nov 2023 14:19:36 -0500 Subject: [PATCH 1/9] Initialized vulnerabilities with curation_level 2 --- cves/kernel/CVE-2013-0290.yml | 2 +- cves/kernel/CVE-2015-8787.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cves/kernel/CVE-2013-0290.yml b/cves/kernel/CVE-2013-0290.yml index ed8367e52..42dfa00cc 100644 --- a/cves/kernel/CVE-2013-0290.yml +++ b/cves/kernel/CVE-2013-0290.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 diff --git a/cves/kernel/CVE-2015-8787.yml b/cves/kernel/CVE-2015-8787.yml index 34fcfd6a4..9926f390c 100644 --- a/cves/kernel/CVE-2015-8787.yml +++ b/cves/kernel/CVE-2015-8787.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 From a842c6a8f3a59e5a77a2b08046546bee83b6e64c Mon Sep 17 00:00:00 2001 From: Patrick Sorensen Date: Wed, 8 Nov 2023 21:25:47 -0500 Subject: [PATCH 2/9] Completed initial research of CVE-2015-8787 --- cves/kernel/CVE-2015-8787.yml | 97 +++++++++++++++++++++-------------- 1 file changed, 58 insertions(+), 39 deletions(-) diff --git a/cves/kernel/CVE-2015-8787.yml b/cves/kernel/CVE-2015-8787.yml index 9926f390c..c21f88198 100644 --- a/cves/kernel/CVE-2015-8787.yml +++ b/cves/kernel/CVE-2015-8787.yml @@ -26,7 +26,7 @@ reported_instructions: | the CVE was created. Leave blank if no date is given. Please enter your date in YYYY-MM-DD format. -reported_date: +reported_date: '2015-10-27' 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: 'An update to the nf_nat_redirect_ipv4 function in + net/netfilter/nf_nat_redirect.c in the Linux kernel removed a NULL check within + a NAT redirect IPv4. If the system were to attempt a redirect to the NULL pointer, + it would cause a crash and could be used in a denial of service attack.' 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: [1300731] fixes_instructions: | Please put the commit hash in "commit" below. @@ -129,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: | @@ -141,16 +144,16 @@ discovered: 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. + vulnerability 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: - automated: - contest: - developer: + answer: 'Vulnerability was found automatically by archeogit' + automated: 'true' + contest: 'false' + developer: 'false' autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -167,8 +170,9 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: 'Yes a fully automated tool could be used to find this vulnerability, as + passing a NULL value to be redirected would be accepted by the system' + answer: 'true' specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -184,8 +188,9 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: 'TCP specification violation, vulnerability in the TCP stack allowed for packets + to be redirected to not configured, NULL interface' + answer: 'true' subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -219,7 +224,7 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: + name: ['net', 'netfilter'] note: interesting_commits: question: | @@ -235,8 +240,8 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: + - commit: 'https://marc.info/?l=netfilter-devel&m=106668497403047&w=2' + note: 'Fixed same issue in 2003' - commit: note: i18n: @@ -251,8 +256,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: 'The vulnerability had to do with TCP connections to a NULL reference, + which was not impacted by internationalization' sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -266,8 +272,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: 'The vulnerability resulted in a denial of service, and was not related to + access control' ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -278,8 +285,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: 'true' + note: 'The vulnerability affected the TCP connection within the system, which is + an IPC' discussion: question: | Was there any discussion surrounding this? @@ -305,9 +313,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: 'The issue was a trivial removal of a NULL check and no discussion was + had around it' vouch: question: | Was there any part of the fix that involved one person vouching for @@ -320,8 +329,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: 'Both the original commit as well as the fix commit had several developers sign off on them' stacktrace: question: | Are there any stacktraces in the bug reports? @@ -335,9 +344,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 stack trace was used to find and fix the issue' forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,8 +365,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 vulnerabitilty was caused by a removal of a NULL check, which was then + updated in the fix' order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -369,8 +379,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 fix did not involve a change in the order of operations' lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -387,8 +397,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 there is an expectation an error will be caught, it should still + be defended against elsewhere in the event those preventitive measures fail. In + this case a NULL check was removed, and once the NULL value was passed that one + expected if statement there were no other defense measures in place to stop it + from crashing the system.' least_privilege: applies: note: @@ -448,7 +462,12 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: 'A NULL check was removed, + if (indev != NULL) { + in favor of + if (indev && indev->ifa_list) { + which allowed for a NULL value to be accepted. A similar issue occurred in + 2003 but the 2015 commit was not properly reviewed.' 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 +492,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: 'Kernel NULL Pointer Deref' CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H From 28d7a7d4ca95f734c1304c51adea11521c67985c Mon Sep 17 00:00:00 2001 From: Patrick Sorensen Date: Wed, 8 Nov 2023 22:58:23 -0500 Subject: [PATCH 3/9] Completed initial research of CVE-2013-0290 --- cves/kernel/CVE-2013-0290.yml | 129 +++++++++++++++++++++------------- cves/kernel/CVE-2015-8787.yml | 83 +++++++++++++--------- 2 files changed, 131 insertions(+), 81 deletions(-) diff --git a/cves/kernel/CVE-2013-0290.yml b/cves/kernel/CVE-2013-0290.yml index 42dfa00cc..095720395 100644 --- a/cves/kernel/CVE-2013-0290.yml +++ b/cves/kernel/CVE-2013-0290.yml @@ -26,7 +26,7 @@ reported_instructions: | 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-02-12' 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: | + The __skb_recv_datagram function in net/core/datagram.c in the Linux kernel + didn't handle an MSG_PEEK flag with zero-length data. This locked the system + in an infinite loop and could result in a 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: [911473] fixes_instructions: | Please put the commit hash in "commit" below. @@ -89,9 +92,7 @@ fixes: - commit: note: - commit: 77c1090f94d1b0b5186fb13a1b71b47b1343f87f - 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. @@ -129,10 +130,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: 'The original code was not unit tested' + fix: 'false' + fix_answer: 'The fix was not unit tested' discovered: question: | How was this vulnerability discovered? @@ -147,10 +148,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: | + The vulnerability was discovered by a developer, + Tommi Rantala , testing the code with a fuzzer + automated: 'false' + contest: 'false' + developer: 'true' autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -167,8 +170,11 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + The vulnerability was caused by the system waiting in an infinite loop on a + packet with no payload. The issue was reported by a developer who used a + fuzzer and discovered the issue + answer: 'true' specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -184,8 +190,11 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + TCP specification violation, vulnerability in the socket buffers being + passed into the system. When the SKB is of zero-length it should be skipped + but the missing check results in a DOS. + answer: 'true' subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -219,7 +228,7 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: + name: ["net", "core"] note: interesting_commits: question: | @@ -235,8 +244,10 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: + - commit: 3f518bf745cbd6007d8069100fb9cb09e960c872 + note: | + Interesting the initial commit which created the issue was made almost + exactly a year before the vulnerability was fixed - commit: note: i18n: @@ -251,8 +262,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 vulnerability had to do with an infinite loop caused by a packet, + being sent with no payload, which was not impacted by internationalization sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -266,8 +279,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: | + The vulnerability resulted in a denial of service, and was not related to + access control ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -278,8 +293,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 affected passing socket buffers within the system, which + is an IPC' discussion: question: | Was there any discussion surrounding this? @@ -305,9 +322,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: 'false' + note: | + The issue was a trivial filtering of zero-length data and no discussion was + had around it vouch: question: | Was there any part of the fix that involved one person vouching for @@ -320,8 +339,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: 'The fixed commit was tested, CCed, and signed off on by several developers' stacktrace: question: | Are there any stacktraces in the bug reports? @@ -335,9 +354,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: 'true' + stacktrace_with_fix: 'true' + note: | + Within the fix commit is the stacktrace, which includes the file where the + fix was made. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,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: | + A flag check was forgotten to ensure zero-length data was not passed into the system, which + caused the vulnerability. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -369,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 fix did not involve a change in the order of operations' lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -386,9 +409,14 @@ 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: + defense_in_depth: + applies: 'true' + note: | + Even if there is an expectation an error will be caught, it should still + be defended against elsewhere in the event those preventative measures fail. In + this case a check was forgotten to ensure zero-length data was not passed into + the system, and once that data was passed there were no other defense measures + in place to stop it from crashing the system. least_privilege: applies: note: @@ -399,8 +427,12 @@ lessons: applies: note: distrust_input: - applies: - note: + applies: 'true' + note: | + This vulnerability was a result of zero-length data being sent to the + system and not properly being handled. The input within a system should + not be so easily trusted and checks should be put in place to ensure all + possible inputs are handled without crashing the system. security_by_obscurity: applies: note: @@ -448,7 +480,10 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + The initial commit was not tested properly to ensure all input into the + system would be handled properly. It then took a year to find and fix the + issue, again a result of poor testing of the system. 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 +508,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: 'Kernel Local DOS' +CVSS: CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:C diff --git a/cves/kernel/CVE-2015-8787.yml b/cves/kernel/CVE-2015-8787.yml index c21f88198..07f4b5a3f 100644 --- a/cves/kernel/CVE-2015-8787.yml +++ b/cves/kernel/CVE-2015-8787.yml @@ -55,10 +55,12 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: 'An update to the nf_nat_redirect_ipv4 function in - net/netfilter/nf_nat_redirect.c in the Linux kernel removed a NULL check within - a NAT redirect IPv4. If the system were to attempt a redirect to the NULL pointer, - it would cause a crash and could be used in a denial of service attack.' +description: | + An update to the nf_nat_redirect_ipv4 function in + net/netfilter/nf_nat_redirect.c in the Linux kernel removed a NULL check + within a NAT redirect IPv4. If the system were to attempt a redirect to the + NULL pointer, it would cause a crash and could be used in a denial of service + attack. 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 @@ -92,9 +94,7 @@ fixes: - commit: note: - commit: 94f9cd81436c85d8c3a318ba92e236ede73752fc - 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. @@ -133,9 +133,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: 'false' - code_answer: + code_answer: 'The original code was not unit tested' fix: 'false' - fix_answer: + fix_answer: 'The fixed code was not unit tested' discovered: question: | How was this vulnerability discovered? @@ -170,8 +170,9 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: 'Yes a fully automated tool could be used to find this vulnerability, as - passing a NULL value to be redirected would be accepted by the system' + note: | + Yes a fully automated tool could be used to find this vulnerability, as + passing a NULL value to be redirected would be accepted by the system answer: 'true' specification: instructions: | @@ -188,8 +189,9 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: 'TCP specification violation, vulnerability in the TCP stack allowed for packets - to be redirected to not configured, NULL interface' + note: | + TCP specification violation, vulnerability in the TCP stack allowed for + packets to be redirected to not configured, NULL interface answer: 'true' subsystem: question: | @@ -224,7 +226,7 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: ['net', 'netfilter'] + name: ["net", "netfilter"] note: interesting_commits: question: | @@ -257,8 +259,9 @@ i18n: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: 'false' - note: 'The vulnerability had to do with TCP connections to a NULL reference, - which was not impacted by internationalization' + note: | + The vulnerability had to do with TCP connections to a NULL reference, + which was not impacted by internationalization sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -273,8 +276,9 @@ sandbox: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: 'false' - note: 'The vulnerability resulted in a denial of service, and was not related to - access control' + note: | + The vulnerability resulted in a denial of service, and was not related to + access control' ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -286,8 +290,9 @@ ipc: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: 'true' - note: 'The vulnerability affected the TCP connection within the system, which is - an IPC' + note: | + The vulnerability affected the TCP connection within the system, which is + an IPC' discussion: question: | Was there any discussion surrounding this? @@ -315,8 +320,9 @@ discussion: comment you want to make. discussed_as_security: 'false' any_discussion: 'false' - note: 'The issue was a trivial removal of a NULL check and no discussion was - had around it' + note: | + The issue was a trivial removal of a NULL check and no discussion was + had around it vouch: question: | Was there any part of the fix that involved one person vouching for @@ -330,7 +336,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: 'true' - note: 'Both the original commit as well as the fix commit had several developers sign off on them' + note: | + Both the original commit as well as the fix commit had several developers + sign off on them' stacktrace: question: | Are there any stacktraces in the bug reports? @@ -366,8 +374,9 @@ forgotten_check: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: 'true' - note: 'The vulnerabitilty was caused by a removal of a NULL check, which was then - updated in the fix' + note: | + The vulnerability was caused by a removal of a NULL check, which was then + updated in the fix order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -398,11 +407,12 @@ lessons: free to give it a small name and add one in the same format as these. defense_in_depth: applies: 'true' - note: 'Even if there is an expectation an error will be caught, it should still - be defended against elsewhere in the event those preventitive measures fail. In - this case a NULL check was removed, and once the NULL value was passed that one - expected if statement there were no other defense measures in place to stop it - from crashing the system.' + note: | + Even if there is an expectation an error will be caught, it should still + be defended against elsewhere in the event those preventative measures + fail. In this case a NULL check was removed, and once the NULL value was + passed there were no other defense measures in place to stop it from + crashing the system. least_privilege: applies: note: @@ -413,8 +423,12 @@ lessons: applies: note: distrust_input: - applies: - note: + applies: 'true' + note: | + This vulnerability was a result of NULL data being sent to the system and + not properly being handled. The input within a system should not be so + easily trusted and checks should be put in place to ensure all possible + inputs are handled without crashing the system. security_by_obscurity: applies: note: @@ -462,12 +476,13 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: 'A NULL check was removed, + answer: | + A NULL check was removed, if (indev != NULL) { in favor of if (indev && indev->ifa_list) { which allowed for a NULL value to be accepted. A similar issue occurred in - 2003 but the 2015 commit was not properly reviewed.' + 2003 but the 2015 commit was not properly reviewed. 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 From afb7fc8a6f23af63bce97eee89290d2707c7a069 Mon Sep 17 00:00:00 2001 From: Patrick Sorensen Date: Wed, 8 Nov 2023 23:05:34 -0500 Subject: [PATCH 4/9] Updated formatting --- cves/kernel/CVE-2015-8787.yml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/cves/kernel/CVE-2015-8787.yml b/cves/kernel/CVE-2015-8787.yml index 07f4b5a3f..7546b496c 100644 --- a/cves/kernel/CVE-2015-8787.yml +++ b/cves/kernel/CVE-2015-8787.yml @@ -478,9 +478,7 @@ mistakes: industry would find interesting. answer: | A NULL check was removed, - if (indev != NULL) { - in favor of - if (indev && indev->ifa_list) { + 'if (indev != NULL) {' in favor of 'if (indev && indev->ifa_list) {' which allowed for a NULL value to be accepted. A similar issue occurred in 2003 but the 2015 commit was not properly reviewed. CWE_instructions: | From da16ab9e15748bb7ab6fa49f94813ee3d369d5ae Mon Sep 17 00:00:00 2001 From: Patrick Sorensen Date: Wed, 8 Nov 2023 23:15:59 -0500 Subject: [PATCH 5/9] Added false flags to lessons section --- cves/kernel/CVE-2013-0290.yml | 18 +++++++++--------- cves/kernel/CVE-2015-8787.yml | 18 +++++++++--------- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/cves/kernel/CVE-2013-0290.yml b/cves/kernel/CVE-2013-0290.yml index 095720395..733f9a74f 100644 --- a/cves/kernel/CVE-2013-0290.yml +++ b/cves/kernel/CVE-2013-0290.yml @@ -418,13 +418,13 @@ lessons: the system, and once that data was passed there were no other defense measures in place to stop it from crashing the system. least_privilege: - applies: + applies: 'false' note: frameworks_are_optional: - applies: + applies: 'false' note: native_wrappers: - applies: + applies: 'false' note: distrust_input: applies: 'true' @@ -434,22 +434,22 @@ lessons: not be so easily trusted and checks should be put in place to ensure all possible inputs are handled without crashing the system. 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: | diff --git a/cves/kernel/CVE-2015-8787.yml b/cves/kernel/CVE-2015-8787.yml index 7546b496c..e9e229366 100644 --- a/cves/kernel/CVE-2015-8787.yml +++ b/cves/kernel/CVE-2015-8787.yml @@ -414,13 +414,13 @@ lessons: passed there were no other defense measures in place to stop it from crashing the system. least_privilege: - applies: + applies: 'false' note: frameworks_are_optional: - applies: + applies: 'false' note: native_wrappers: - applies: + applies: 'false' note: distrust_input: applies: 'true' @@ -430,22 +430,22 @@ lessons: easily trusted and checks should be put in place to ensure all possible inputs are handled without crashing the system. 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: | From 98b76493a8157102c8a7fe701f8bad2a05aa0d53 Mon Sep 17 00:00:00 2001 From: Patrick Sorensen Date: Fri, 10 Nov 2023 14:26:02 -0500 Subject: [PATCH 6/9] Fixed true/false booleans --- cves/kernel/CVE-2013-0290.yml | 56 +++++++++++++++++------------------ cves/kernel/CVE-2015-8787.yml | 56 +++++++++++++++++------------------ 2 files changed, 56 insertions(+), 56 deletions(-) diff --git a/cves/kernel/CVE-2013-0290.yml b/cves/kernel/CVE-2013-0290.yml index 733f9a74f..1657a85f9 100644 --- a/cves/kernel/CVE-2013-0290.yml +++ b/cves/kernel/CVE-2013-0290.yml @@ -130,9 +130,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: 'false' + code: false code_answer: 'The original code was not unit tested' - fix: 'false' + fix: false fix_answer: 'The fix was not unit tested' discovered: question: | @@ -151,9 +151,9 @@ discovered: answer: | The vulnerability was discovered by a developer, Tommi Rantala , testing the code with a fuzzer - automated: 'false' - contest: 'false' - developer: 'true' + automated: false + contest: false + developer: true autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -174,7 +174,7 @@ autodiscoverable: The vulnerability was caused by the system waiting in an infinite loop on a packet with no payload. The issue was reported by a developer who used a fuzzer and discovered the issue - answer: 'true' + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -194,7 +194,7 @@ specification: TCP specification violation, vulnerability in the socket buffers being passed into the system. When the SKB is of zero-length it should be skipped but the missing check results in a DOS. - answer: 'true' + answer: true subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -262,7 +262,7 @@ 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: 'false' + answer: false note: | The vulnerability had to do with an infinite loop caused by a packet, being sent with no payload, which was not impacted by internationalization @@ -279,7 +279,7 @@ 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: 'false' + answer: false note: | The vulnerability resulted in a denial of service, and was not related to access control @@ -293,7 +293,7 @@ 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' + answer: true note: | The vulnerability affected passing socket buffers within the system, which is an IPC' @@ -322,8 +322,8 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: 'false' - any_discussion: 'false' + discussed_as_security: false + any_discussion: false note: | The issue was a trivial filtering of zero-length data and no discussion was had around it @@ -339,7 +339,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: 'true' + answer: true note: 'The fixed commit was tested, CCed, and signed off on by several developers' stacktrace: question: | @@ -354,8 +354,8 @@ 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: 'true' - stacktrace_with_fix: 'true' + any_stacktraces: true + stacktrace_with_fix: true note: | Within the fix commit is the stacktrace, which includes the file where the fix was made. @@ -377,7 +377,7 @@ 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: 'true' + answer: true note: | A flag check was forgotten to ensure zero-length data was not passed into the system, which caused the vulnerability. @@ -392,7 +392,7 @@ 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: 'false' + answer: false note: 'The fix did not involve a change in the order of operations' lessons: question: | @@ -410,7 +410,7 @@ 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: 'true' + applies: true note: | Even if there is an expectation an error will be caught, it should still be defended against elsewhere in the event those preventative measures fail. In @@ -418,38 +418,38 @@ lessons: the system, and once that data was passed there were no other defense measures in place to stop it from crashing the system. least_privilege: - applies: 'false' + applies: false note: frameworks_are_optional: - applies: 'false' + applies: false note: native_wrappers: - applies: 'false' + applies: false note: distrust_input: - applies: 'true' + applies: true note: | This vulnerability was a result of zero-length data being sent to the system and not properly being handled. The input within a system should not be so easily trusted and checks should be put in place to ensure all possible inputs are handled without crashing the system. security_by_obscurity: - applies: 'false' + applies: false note: serial_killer: - applies: 'false' + applies: false note: environment_variables: - applies: 'false' + applies: false note: secure_by_default: - applies: 'false' + applies: false note: yagni: - applies: 'false' + applies: false note: complex_inputs: - applies: 'false' + applies: false note: mistakes: question: | diff --git a/cves/kernel/CVE-2015-8787.yml b/cves/kernel/CVE-2015-8787.yml index e9e229366..e08038673 100644 --- a/cves/kernel/CVE-2015-8787.yml +++ b/cves/kernel/CVE-2015-8787.yml @@ -132,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: 'false' + code: false code_answer: 'The original code was not unit tested' - fix: 'false' + fix: false fix_answer: 'The fixed code was not unit tested' discovered: question: | @@ -151,9 +151,9 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. answer: 'Vulnerability was found automatically by archeogit' - automated: 'true' - contest: 'false' - developer: 'false' + automated: true + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -173,7 +173,7 @@ autodiscoverable: note: | Yes a fully automated tool could be used to find this vulnerability, as passing a NULL value to be redirected would be accepted by the system - answer: 'true' + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -192,7 +192,7 @@ specification: note: | TCP specification violation, vulnerability in the TCP stack allowed for packets to be redirected to not configured, NULL interface - answer: 'true' + answer: true subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -258,7 +258,7 @@ 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: 'false' + answer: false note: | The vulnerability had to do with TCP connections to a NULL reference, which was not impacted by internationalization @@ -275,7 +275,7 @@ 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: 'false' + answer: false note: | The vulnerability resulted in a denial of service, and was not related to access control' @@ -289,7 +289,7 @@ 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' + answer: true note: | The vulnerability affected the TCP connection within the system, which is an IPC' @@ -318,8 +318,8 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: 'false' - any_discussion: 'false' + discussed_as_security: false + any_discussion: false note: | The issue was a trivial removal of a NULL check and no discussion was had around it @@ -335,7 +335,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: 'true' + answer: true note: | Both the original commit as well as the fix commit had several developers sign off on them' @@ -352,8 +352,8 @@ 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: 'true' - stacktrace_with_fix: 'true' + any_stacktraces: true + stacktrace_with_fix: true note: 'The stack trace was used to find and fix the issue' forgotten_check: question: | @@ -373,7 +373,7 @@ 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: 'true' + answer: true note: | The vulnerability was caused by a removal of a NULL check, which was then updated in the fix @@ -388,7 +388,7 @@ 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: 'false' + answer: false note: 'The fix did not involve a change in the order of operations' lessons: question: | @@ -406,7 +406,7 @@ 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: 'true' + applies: true note: | Even if there is an expectation an error will be caught, it should still be defended against elsewhere in the event those preventative measures @@ -414,38 +414,38 @@ lessons: passed there were no other defense measures in place to stop it from crashing the system. least_privilege: - applies: 'false' + applies: false note: frameworks_are_optional: - applies: 'false' + applies: false note: native_wrappers: - applies: 'false' + applies: false note: distrust_input: - applies: 'true' + applies: true note: | This vulnerability was a result of NULL data being sent to the system and not properly being handled. The input within a system should not be so easily trusted and checks should be put in place to ensure all possible inputs are handled without crashing the system. security_by_obscurity: - applies: 'false' + applies: false note: serial_killer: - applies: 'false' + applies: false note: environment_variables: - applies: 'false' + applies: false note: secure_by_default: - applies: 'false' + applies: false note: yagni: - applies: 'false' + applies: false note: complex_inputs: - applies: 'false' + applies: false note: mistakes: question: | From 4b8f04c0dd1accf8e7f11d628f0980c095f474c9 Mon Sep 17 00:00:00 2001 From: Patrick Sorensen Date: Fri, 10 Nov 2023 14:54:38 -0500 Subject: [PATCH 7/9] removed false commit --- cves/kernel/CVE-2015-8787.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2015-8787.yml b/cves/kernel/CVE-2015-8787.yml index e08038673..3da87e688 100644 --- a/cves/kernel/CVE-2015-8787.yml +++ b/cves/kernel/CVE-2015-8787.yml @@ -242,7 +242,7 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: 'https://marc.info/?l=netfilter-devel&m=106668497403047&w=2' + - commit: note: 'Fixed same issue in 2003' - commit: note: From 1d9beb4faf7f962d968d95cd505c4383df52db07 Mon Sep 17 00:00:00 2001 From: Patrick Sorensen Date: Fri, 10 Nov 2023 16:29:26 -0500 Subject: [PATCH 8/9] Updated interesting_commit section --- cves/kernel/CVE-2015-8787.yml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2015-8787.yml b/cves/kernel/CVE-2015-8787.yml index 3da87e688..20013cdc4 100644 --- a/cves/kernel/CVE-2015-8787.yml +++ b/cves/kernel/CVE-2015-8787.yml @@ -243,7 +243,11 @@ interesting_commits: * Anything else you find interesting. commits: - commit: - note: 'Fixed same issue in 2003' + note: | + The same issue occurred in 2013, and same fix was used again in 2015. + Below is bug report with fix, but due to its age no corresponding commit + hash can be found. + https://marc.info/?l=netfilter-devel&m=106668497403047&w=2 - commit: note: i18n: From ce4f324d385a2463eada854e9f544d4f72c8730f Mon Sep 17 00:00:00 2001 From: Patrick Sorensen Date: Wed, 15 Nov 2023 19:36:05 -0500 Subject: [PATCH 9/9] Updated with review suggestions --- cves/kernel/CVE-2013-0290.yml | 71 ++++++++++++++++++--------------- cves/kernel/CVE-2015-8787.yml | 74 ++++++++++++++++++----------------- 2 files changed, 79 insertions(+), 66 deletions(-) diff --git a/cves/kernel/CVE-2013-0290.yml b/cves/kernel/CVE-2013-0290.yml index 1657a85f9..dca4b980e 100644 --- a/cves/kernel/CVE-2013-0290.yml +++ b/cves/kernel/CVE-2013-0290.yml @@ -56,9 +56,15 @@ description_instructions: | Your target audience is people just like you before you took any course in security description: | - The __skb_recv_datagram function in net/core/datagram.c in the Linux kernel - didn't handle an MSG_PEEK flag with zero-length data. This locked the system - in an infinite loop and could result in a denial of service. + Within the Linux kernel there was a net/core/datagram.c file, which stored + generic datagram handling routines. One of these routines, + The __skb_recv_datagram function, was made to lock a socket if a skb was + returned, requiring it be unlocked later with the use of another call. This + function utilized an MSG_PEEK call to look at incoming data. However this + call didn't properly handle the event if the incoming data was of + zero-length. Since the MSG_PEEK flag was used to end a loop, the zero-length + data caused an infinite loop and could be used maliciously to result in a + 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 @@ -78,12 +84,13 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [911473] +bugs: +- https://bugzilla.redhat.com/show_bug.cgi?id=911473 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/ + hexademical string. Place any notes you would like to make in the notes field. fixes: @@ -92,7 +99,7 @@ fixes: - commit: note: - commit: 77c1090f94d1b0b5186fb13a1b71b47b1343f87f - note: 'Manually confirmed' + note: 'Manually confirmed.' vcc_instructions: | The vulnerability-contributing commits. @@ -107,7 +114,7 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: - commit: 3f518bf745cbd6007d8069100fb9cb09e960c872 - note: Discovered automatically by archeogit. + note: Discovered automatically by archeogit. Manually Confirmed. upvotes_instructions: | For the first round, ignore this upvotes number. @@ -115,7 +122,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? @@ -131,9 +138,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: false - code_answer: 'The original code was not unit tested' + code_answer: 'The original code was not unit tested.' fix: false - fix_answer: 'The fix was not unit tested' + fix_answer: 'The fix was not unit tested.' discovered: question: | How was this vulnerability discovered? @@ -149,8 +156,8 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. answer: | - The vulnerability was discovered by a developer, - Tommi Rantala , testing the code with a fuzzer + The vulnerability was discovered by Tommi Rantala + by testing the code using Trinity, a Linux system call fuzzer. automated: false contest: false developer: true @@ -172,8 +179,10 @@ autodiscoverable: why you come to that conclusion. note: | The vulnerability was caused by the system waiting in an infinite loop on a - packet with no payload. The issue was reported by a developer who used a - fuzzer and discovered the issue + packet with no payload. The issue was discovered by a developer using + Trinity, a Linux system call fuzzer. This demonstrates that it's not only + possible, but proven, that automated tools can be used to uncover this + vulnerability. answer: true specification: instructions: | @@ -246,8 +255,8 @@ interesting_commits: commits: - commit: 3f518bf745cbd6007d8069100fb9cb09e960c872 note: | - Interesting the initial commit which created the issue was made almost - exactly a year before the vulnerability was fixed + The commit that first introduced the issue. It was made approximately one + year prior to the discovery and resolution of the vulnerability. - commit: note: i18n: @@ -265,7 +274,7 @@ i18n: answer: false note: | The vulnerability had to do with an infinite loop caused by a packet, - being sent with no payload, which was not impacted by internationalization + being sent with no payload, which was not impacted by internationalization. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -282,7 +291,7 @@ sandbox: answer: false note: | The vulnerability resulted in a denial of service, and was not related to - access control + access control. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -296,7 +305,7 @@ ipc: answer: true note: | The vulnerability affected passing socket buffers within the system, which - is an IPC' + is a form of IPC. discussion: question: | Was there any discussion surrounding this? @@ -326,7 +335,7 @@ discussion: any_discussion: false note: | The issue was a trivial filtering of zero-length data and no discussion was - had around it + had around it. vouch: question: | Was there any part of the fix that involved one person vouching for @@ -340,7 +349,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: true - note: 'The fixed commit was tested, CCed, and signed off on by several developers' + note: | + The commit fixing the issue was tested, reviewed, CCed, and signed off on + by multiple developers. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -357,7 +368,7 @@ stacktrace: any_stacktraces: true stacktrace_with_fix: true note: | - Within the fix commit is the stacktrace, which includes the file where the + Within the fix commit is a stacktrace, which includes the file where the fix was made. forgotten_check: question: | @@ -379,8 +390,8 @@ forgotten_check: what your answer was. answer: true note: | - A flag check was forgotten to ensure zero-length data was not passed into the system, which - caused the vulnerability. + A flag check was forgotten to ensure zero-length data was not passed into + the system, which caused the vulnerability. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -393,7 +404,7 @@ order_of_operations: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: false - note: 'The fix did not involve a change in the order of operations' + note: 'The fix did not involve a change in the order of operations.' lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -481,9 +492,9 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. answer: | - The initial commit was not tested properly to ensure all input into the - system would be handled properly. It then took a year to find and fix the - issue, again a result of poor testing of the system. + This vulnerability was caused by a lapse, as the incoming data was not + properly considered and the case if that data were of zero-length was + forgotten and not correctly handled. 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 @@ -501,9 +512,7 @@ CWE_instructions: | CWE: 123 # also ok CWE: - 20 -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-2015-8787.yml b/cves/kernel/CVE-2015-8787.yml index 20013cdc4..89e22917b 100644 --- a/cves/kernel/CVE-2015-8787.yml +++ b/cves/kernel/CVE-2015-8787.yml @@ -54,13 +54,14 @@ description_instructions: | keep too. Your target audience is people just like you before you took any course in - security + security. description: | An update to the nf_nat_redirect_ipv4 function in net/netfilter/nf_nat_redirect.c in the Linux kernel removed a NULL check - within a NAT redirect IPv4. If the system were to attempt a redirect to the - NULL pointer, it would cause a crash and could be used in a denial of service - attack. + which caused an error when attempting to redirect IPv4 packets. Some + interfaces within the system had not yet been fully configured, so with the + NULL check removed packets would be redirected to the NULL pointer causing a crash. + This could be used maliciously in a denial of service attack. 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 @@ -80,7 +81,8 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [1300731] +bugs: + - https://bugzilla.redhat.com/show_bug.cgi?id=1300731 fixes_instructions: | Please put the commit hash in "commit" below. @@ -94,7 +96,7 @@ fixes: - commit: note: - commit: 94f9cd81436c85d8c3a318ba92e236ede73752fc - note: 'Manually confirmed' + note: 'Manually confirmed.' vcc_instructions: | The vulnerability-contributing commits. @@ -109,7 +111,7 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: - commit: 8b13eddfdf04cbfa561725cfc42d6868fe896f56 - note: Discovered automatically by archeogit. + note: Discovered automatically by archeogit. Manually Confirmed. upvotes_instructions: | For the first round, ignore this upvotes number. @@ -117,7 +119,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? @@ -133,9 +135,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: false - code_answer: 'The original code was not unit tested' + code_answer: 'The original code was not unit tested.' fix: false - fix_answer: 'The fixed code was not unit tested' + fix_answer: 'The fixed code was not unit tested.' discovered: question: | How was this vulnerability discovered? @@ -150,8 +152,9 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: 'Vulnerability was found automatically by archeogit' - automated: true + answer: | + This vulnerability was discovered by Munehisa Kamata . + automated: false contest: false developer: false autodiscoverable: @@ -172,7 +175,7 @@ autodiscoverable: why you come to that conclusion. note: | Yes a fully automated tool could be used to find this vulnerability, as - passing a NULL value to be redirected would be accepted by the system + passing a NULL value to be redirected would be accepted by the system. answer: true specification: instructions: | @@ -190,8 +193,8 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. note: | - TCP specification violation, vulnerability in the TCP stack allowed for - packets to be redirected to not configured, NULL interface + Violation of TCP specification. The vulnerability in the TCP stack + allowed for packets to be redirected to an unconfigured, NULL interface. answer: true subsystem: question: | @@ -244,9 +247,9 @@ interesting_commits: commits: - commit: note: | - The same issue occurred in 2013, and same fix was used again in 2015. - Below is bug report with fix, but due to its age no corresponding commit - hash can be found. + The same issue occurred in 2003, and same fix was used again in 2015. + Below is the bug report with fix, but due to its age no corresponding + commit hash can be found. https://marc.info/?l=netfilter-devel&m=106668497403047&w=2 - commit: note: @@ -265,7 +268,7 @@ i18n: answer: false note: | The vulnerability had to do with TCP connections to a NULL reference, - which was not impacted by internationalization + which was not impacted by internationalization. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -282,7 +285,7 @@ sandbox: answer: false note: | The vulnerability resulted in a denial of service, and was not related to - access control' + access control. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -295,8 +298,9 @@ ipc: what your answer was. answer: true note: | - The vulnerability affected the TCP connection within the system, which is - an IPC' + The vulnerability affected the TCP connection within the system, a form of + IPC, by allowing IPv4 packets to be sent to an unconfigured, NULL + interface. discussion: question: | Was there any discussion surrounding this? @@ -326,7 +330,7 @@ discussion: any_discussion: false note: | The issue was a trivial removal of a NULL check and no discussion was - had around it + had around it. vouch: question: | Was there any part of the fix that involved one person vouching for @@ -342,7 +346,7 @@ vouch: answer: true note: | Both the original commit as well as the fix commit had several developers - sign off on them' + sign off on them. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -358,7 +362,7 @@ stacktrace: what your answer was. any_stacktraces: true stacktrace_with_fix: true - note: 'The stack trace was used to find and fix the issue' + note: 'The stack trace was used to find and fix the issue.' forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -379,8 +383,9 @@ forgotten_check: what your answer was. answer: true note: | - The vulnerability was caused by a removal of a NULL check, which was then - updated in the fix + The vulnerability was caused by a removal of a NULL check, forgetting it + was required to prevent an infinite loop. This vulnerability was fixed once + the forgotten NULL check was restored. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -393,7 +398,7 @@ order_of_operations: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: false - note: 'The fix did not involve a change in the order of operations' + note: 'The fix did not involve a change in the order of operations.' lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -481,10 +486,11 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. answer: | - A NULL check was removed, - 'if (indev != NULL) {' in favor of 'if (indev && indev->ifa_list) {' - which allowed for a NULL value to be accepted. A similar issue occurred in - 2003 but the 2015 commit was not properly reviewed. + This vulnerability was caused by a slip, a fix for the same issue had + occurred and been fixed in 2003 by adding a NULL check to ensure IPv4 + packets were not redirected to an unconfigured, NULL interface. In 2015 + however the check was accidentally removed, and the vulnerability wasn't + fixed until the missing NULL check was restored. 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 @@ -502,9 +508,7 @@ CWE_instructions: | CWE: 123 # also ok CWE: - 476 -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.