CVE-2013-4513 & CVE-2017-10911

cves/kernel/CVE-2013-4513.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-10-29'
 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,12 @@ description_instructions: |
 
   Your target audience is people just like you before you took any course in
   security
-description:
+description: OZWpan is a technology related to Personal Area Networking, specifically wireless networking. It's designed for 
+  short-range communication, typically used in devices like wireless keyboards, mice, and other peripherals that operate in close
+  proximity to a central device like a computer. The specific file involved in this vulnerability contains code for creating and managing character devices
+  for the OZWpan driver. In Linux, a character device is a type of device file that allows for the input and output of data one 
+  character at a time. The write operation in the wireless device driver file potentially causes a buffer overflow, which can lead to DoS
+  or possibly have unspecified other impact via a crafted write operation.
 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 +80,7 @@ bugs_instructions: |
     * Mentioned in mailing list discussions
     * References from NVD entry
     * Various other places
-bugs: []
+bugs: [492532]
 fixes_instructions: |
   Please put the commit hash in "commit" below.
 
@@ -84,14 +89,8 @@ fixes_instructions: |
 
   Place any notes you would like to make in the notes field.
 fixes:
-- commit:
-  note:
-- commit:
-  note:
 - commit: c2c65cd2e14ada6de44cb527e7f1990bede24e15
-  note: |
-    Taken from NVD references list with Git commit. If you are
-    curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed'
+  note: Manually confirmed.
 vcc_instructions: |
   The vulnerability-contributing commits.
 
@@ -106,15 +105,15 @@ vcc_instructions: |
   Place any notes you would like to make in the notes field.
 vccs:
 - commit: 23af8c2a088fe5ae142103fb32fa03755cda694c
-  note: Discovered automatically by archeogit.
+  note: Discovered automatically by archeogit. Verified by a human.
 upvotes_instructions: |
   For the first round, ignore this upvotes number.
 
   For the second round of reviewing, you will be giving a certain amount of
   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?
@@ -129,10 +128,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: linux kernel doesn't contain any traditional unit tests in the repo or ci/cd pipelines. Developers are responsible for testing their code themselves.
+  fix: false
+  fix_answer: Didn't fine any unit tests or mentions of unit tests.
 discovered:
   question: |
     How was this vulnerability discovered?
@@ -147,10 +146,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 two developers, Nico Golde and Fabian Yamaguchi around 2013-10-29. It 
+    is hard to determine the precise date because the date when the vulnerability was discovered is not actually mentioned anywhere in the
+    kernel mailing list archives, commit messages, or on bugzilla. 
+  automated: false
+  contest: false
+  developer: true
 autodiscoverable:
   instructions: |
     Is it plausible that a fully automated tool could have discovered
@@ -167,8 +168,9 @@ autodiscoverable:
 
     The answer field should be boolean. In answer_note, please explain
     why you come to that conclusion.
-  note:
-  answer:
+  note: A unit test can detect buffer oveflows. However, the testing is not done in the kernel repo itself. Most of the time,
+    each contributor to the kernel repo is responsible for testing their code themselves.
+  answer: true
 specification:
   instructions: |
     Is there mention of a violation of a specification? For example, the POSIX
@@ -184,8 +186,8 @@ specification:
 
     The answer field should be boolean. In answer_note, please explain
     why you come to that conclusion.
-  note:
-  answer:
+  note:  I have not found any mention of specification violation.
+  answer: false
 subsystem:
   question: |
     What subsystems was the mistake in? These are WITHIN linux kernel
@@ -219,8 +221,11 @@ subsystem:
     e.g.
         name: ["subsystemA", "subsystemB"] # ok
         name: subsystemA # also ok
-  name:
-  note:
+  name: drivers
+  note: specifically affects the staging folder in the drivers subsystem. The staging directory is used for drivers that are not yet 
+    fully matured or stable enough to be included in the main kernel tree. These drivers are still under development and testing. 
+    The staging area serves as a place where developers can collaborate to improve these drivers until they are 
+    ready for inclusion in the main part of the kernel.
 interesting_commits:
   question: |
     Are there any interesting commits between your VCC(s) and fix(es)?
@@ -236,9 +241,8 @@ interesting_commits:
       * Anything else you find interesting.
   commits:
   - commit:
-    note:
-  - commit:
-    note:
+    note: The vulnerability was caused by a simple abscence of bounds check to prevent overflow. I did not find
+      any interesting commits relating to that.
 i18n:
   question: |
     Was the feature impacted by this vulnerability about internationalization
@@ -251,8 +255,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 is a buffer overflow error in a wireless devic driver. It does not affect internationalization (unless you consider the whole system going down an internationalization issue).
 sandbox:
   question: |
     Did this vulnerability violate a sandboxing feature that the system
@@ -266,8 +270,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: true
+  note: I read in the mailing list archives that one consequence of a buffer overflow in this vulnerability is that a program which writes to a 
+    device through this driver could potentially elevate its privileges.
 ipc:
   question: |
     Did the feature that this vulnerability affected use inter-process
@@ -278,8 +283,8 @@ 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: Since this is a driver that writes to file, IPC is affected directly.
 discussion:
   question: |
     Was there any discussion surrounding this?
@@ -305,9 +310,9 @@ discussion:
 
     Put any links to disagreements you found in the notes section, or any other
     comment you want to make.
-  discussed_as_security:
-  any_discussion:
-  note:
+  discussed_as_security: false
+  any_discussion: false
+  note: Did not find any discussion except for - bug found - fixing it - merged fix
 vouch:
   question: |
     Was there any part of the fix that involved one person vouching for
@@ -320,8 +325,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 fix's commit message says signed-off-by Linus Torvalds <[email protected]>
 stacktrace:
   question: |
     Are there any stacktraces in the bug reports?
@@ -335,9 +340,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: Did not find any stack traces in commit messages or mailing archives
 forgotten_check:
   question: |
     Does the fix for the vulnerability involve adding a forgotten check?
@@ -356,8 +361,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: quote from the fix commit -- We need to check "count" so we don't overflow the ei->data buffer. It is hard to tell
+    what exactly count refers to, since there aren't many comments in the code. I believe count may be referring to the 
+    number of characters that the wireless device is writing through the driver. 
 order_of_operations:
   question: |
     Does the fix for the vulnerability involve correcting an order of
@@ -369,8 +376,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: Order of operations was not the issue. The fix invloved a forgotten check, and the order of the 
+    things that were checked didn't matter.
 lessons:
   question: |
     Are there any common lessons we have learned from class that apply to this
@@ -387,20 +395,21 @@ 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:
     note:
   distrust_input:
-    applies:
-    note:
+    applies: true
+    note: A carefully crafted program can exploit this vulnerability to provide malicious input that will cause buffer
+      overflow for the driver, potentially causing denial of service on the entire system.
   security_by_obscurity:
     applies:
     note:
@@ -417,8 +426,9 @@ lessons:
     applies:
     note:
   complex_inputs:
-    applies:
-    note:
+    applies: true
+    note: The vulnerability involved input that has to be specifically crafted to cause buffer overflow. Buffer overflow would
+      not happen in normal conditions.
 mistakes:
   question: |
     In your opinion, after all of this research, what mistakes were made that
@@ -448,7 +458,11 @@ mistakes:
 
     Write a thoughtful entry here that people in the software engineering
     industry would find interesting.
-  answer:
+  answer: Since this vulenrability was implemented in the staging directory of the drivers,
+    it is very possible that the authors of the file that contained the vulnerability simply overlooked
+    this buffer overflow. A such, this mistake can be classified as a slip. Probably the developers of the
+    commit didn't pay enough attention, and with the language of implementation being C such mistakes are 
+    very common.
 CWE_instructions: |
   Please go to http://cwe.mitre.org and find the most specific, appropriate CWE
   entry that describes your vulnerability. We recommend going to
@@ -466,9 +480,7 @@ CWE_instructions: |
     CWE: 123            # also ok
 CWE:
 - 119
-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.