Investigating vulnerabilities CVE-2013-0290 and CVE-2015-8787

cves/kernel/CVE-2013-0290.yml

@@ -19,14 +19,14 @@ curated_instructions: |
   This will enable additional editorial checks on this file to make sure you
   fill everything out properly. If you are a student, we cannot accept your work
   as finished unless curated is properly updated.
-curation_level: 0
+curation_level: 2
 reported_instructions: |
   What date was the vulnerability reported to the security team? Look at the
   security bulletins and bug reports. It is not necessarily the same day that
   the CVE was created.  Leave blank if no date is given.
 
   Please enter your date in YYYY-MM-DD format.
-reported_date:
+reported_date: '2013-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 <[email protected]>, 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,38 +409,47 @@ 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:
+    applies: false
     note:
   frameworks_are_optional:
-    applies:
+    applies: false
     note:
   native_wrappers:
-    applies:
+    applies: false
     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:
+    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: |
@@ -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