CVE-2017-7487|CVE-2016-3137

.vs/VSWorkspaceState.json

@@ -0,0 +1,7 @@
+{
+  "ExpandedNodes": [
+    ""
+  ],
+  "SelectedNode": "\\C:\\Users\\trevo\\Downloads\\SWEN 331\\History Project",
+  "PreviewInSolutionExplorer": false
+}

cves/kernel/CVE-2016-3137.yml

@@ -12,21 +12,21 @@ yaml_instructions: |
   For readability, we hard-wrap multi-line strings at 80 characters. This is
   not required, but appreciated.
 curated_instructions: |
-  If you are manually editing this file, then you are "curating" it.
+  If you are manually editing this file, then you are 'curating' it.
 
   Set the version number that you were given in your 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: '2016-03-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.
@@ -38,7 +38,7 @@ announced_date: '2016-05-02'
 published_instructions: |
   Is there a published fix or patch date for this vulnerability?
   Please enter your date in YYYY-MM-DD format.
-published_date: '2016-05-02'
+published_date: '2016-03-31'
 description_instructions: |
   You can get an initial description from the CVE entry on cve.mitre.org. These
   descriptions are a fine start, but they can be kind of jargony.
@@ -49,13 +49,13 @@ description_instructions: |
 
   Try to still be specific in your description, but remove project-specific
   stuff. Remove references to versions, specific filenames, and other jargon
-  that outsiders to this project would not understand. Technology like "regular
-  expressions" is fine, and security phrases like "invalid write" are fine to
+  that outsiders to this project would not understand. Technology like 'regular
+  expressions' is fine, and security phrases like 'invalid write' are fine to
   keep too.
 
   Your target audience is people just like you before you took any course in
   security
-description:
+description: 'This vulnerability was caused because of the failure to include a check for the existance/non-existance of an interupt-out value. This allowed physically present attackers to insert a properly formatted USB that requires cypress_m8 drivers. Once the USB is inserted the kernel, would then dereference a null pointer causing a crash.'
 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,9 +75,9 @@ bugs_instructions: |
     * Mentioned in mailing list discussions
     * References from NVD entry
     * Various other places
-bugs: []
+bugs: [1283368, 1317010]
 fixes_instructions: |
-  Please put the commit hash in "commit" below.
+  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/
@@ -90,8 +90,7 @@ fixes:
   note:
 - commit: c55aee1bf0e6b6feec8b2927b43f7a09a6d5f754
   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'
+    'Manually confirmed'
 vcc_instructions: |
   The vulnerability-contributing commits.
 
@@ -105,24 +104,24 @@ vcc_instructions: |
 
   Place any notes you would like to make in the notes field.
 vccs:
-- commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
-  note: Discovered automatically by archeogit.
+- commit:
+  note: 
 - commit: 194343d9364ea07c9f27c4505380a15a905e8a24
-  note: Discovered automatically by archeogit.
+  note: 'Did not directly alter vulnerable code but did major changes to other tangentally related features.'
 - commit: 5c1a0f418d8d985f3a62849bcac43fc5404cc592
-  note: Discovered automatically by archeogit.
+  note: 'Changes made directly to function of vulnerable code.'
 - commit: 80b6ca48321974a6566a1c9048ba34f60420bca6
-  note: Discovered automatically by archeogit.
+  note: 'System wide alterations from kmalloc to kzalloc.'
 - commit: 813a224fa5bff3e34309a6494e231d5ebfa0fb4e
-  note: Discovered automatically by archeogit.
+  note: 'Major changes to cypress systems.'
 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: 9
 unit_tested:
   question: |
     Were automated unit tests involved in this vulnerability?
@@ -137,16 +136,16 @@ unit_tested:
 
     For the fix_answer below, check if the fix for the vulnerability involves
     adding or improving an automated test to ensure this doesn't happen again.
-  code:
-  code_answer:
-  fix:
-  fix_answer:
+  code: false
+  code_answer: 'It would be impossible to unit test this issue because it requires physical interaction from the attacker.'
+  fix: false
+  fix_answer: 'No testing was added for this issue.'
 discovered:
   question: |
     How was this vulnerability discovered?
 
     Go to the bug report and read the conversation to find out how this was
-    originally found. Answer in longform below in "answer", fill in the date in
+    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.
@@ -155,10 +154,10 @@ 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 vulnerability was found on accident through meeting the physical requirements for it to occur. No other explanation was found.'
+  automated: false
+  contest: false
+  developer: true
 autodiscoverable:
   instructions: |
     Is it plausible that a fully automated tool could have discovered
@@ -170,13 +169,13 @@ autodiscoverable:
     In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here.
 
     Examples for false: RFC violations, permissions issues, anything
-    that requires the tool to be "aware" of the project's
+    that requires the tool to be 'aware' of the project's
     domain-specific requirements.
 
     The answer field should be boolean. In answer_note, please explain
     why you come to that conclusion.
-  note:
-  answer:
+  note: 'This vulnerability requires physical interaction from attackers to complete.'
+  answer: false
 specification:
   instructions: |
     Is there mention of a violation of a specification? For example, the POSIX
@@ -192,8 +191,8 @@ specification:
 
     The answer field should be boolean. In answer_note, please explain
     why you come to that conclusion.
-  note:
-  answer:
+  note: 'No mention of specifications being violated in any bugzilla reports, red hat forums, or git history.'
+  answer: false
 subsystem:
   question: |
     What subsystems was the mistake in? These are WITHIN linux kernel
@@ -225,10 +224,10 @@ subsystem:
 
     Can be multiple subsystems involved, in which case you can make it an array
     e.g.
-        name: ["subsystemA", "subsystemB"] # ok
+        name: ['subsystemA', 'subsystemB'] # ok
         name: subsystemA # also ok
-  name:
-  note:
+  name: 'serial'
+  note: 'This vulnerability has to do with serial connections involving the cypress m8 driver.'
 interesting_commits:
   question: |
     Are there any interesting commits between your VCC(s) and fix(es)?
@@ -238,13 +237,13 @@ interesting_commits:
 
     Example interesting commits:
       * Mentioned as a problematic commit in the past
-        e.g. "This fixes regression in commit xys"
+        e.g. 'This fixes regression in commit xys'
       * A significant rewrite in the git history
       * Other commits that fixed a similar issue as this vulnerability
       * Anything else you find interesting.
   commits:
-  - commit:
-    note:
+  - commit: 5c1a0f418d8d985f3a62849bcac43fc5404cc592
+    note: 'This commit fixed another vulnerability within this system.'
   - commit:
     note:
 i18n:
@@ -259,8 +258,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 has nothing to do with i18n.'
 sandbox:
   question: |
     Did this vulnerability violate a sandboxing feature that the system
@@ -274,8 +273,8 @@ sandbox:
     Answer should be true or false
     Write a note about how you came to the conclusions you did, regardless of
     what your answer was.
-  answer:
-  note:
+  answer: false
+  note: 'This vulnerability does not involve elevating access for users.'
 ipc:
   question: |
     Did the feature that this vulnerability affected use inter-process
@@ -286,8 +285,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: 'This vulnerability involves serial communication which is a form of inter-process communication.'
 discussion:
   question: |
     Was there any discussion surrounding this?
@@ -302,8 +301,8 @@ discussion:
 
     Just because you see multiple comments doesn't mean it's a discussion.
     For example:
-      * "Fix line 10". "Ok" is not what we call a discussion
-      * "Ping" (reminding people)
+      * 'Fix line 10'. 'Ok' is not what we call a discussion
+      * 'Ping' (reminding people)
 
     Check the bugs reports, pull requests, and mailing lists archives.
 
@@ -313,9 +312,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: true
+  any_discussion: true
+  note: 'This vulnerability is two-fold as it involves the issue pertaining to the cypress_m8 drivers as well as cdc_acm. Thus, there was deliberation as to which issues pertained to which segment of this vulnerability. Other discussion involved which other systems were impacted by this issue.'
 vouch:
   question: |
     Was there any part of the fix that involved one person vouching for
@@ -328,8 +327,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: false
+  note: "No instances of developers vouching for any other person's work. No commit messages or anything in the bugzilla post referanced anything of that sort."
 stacktrace:
   question: |
     Are there any stacktraces in the bug reports?
@@ -343,14 +342,14 @@ stacktrace:
     Answer must be true or false.
     Write a note about how you came to the conclusions you did, regardless of
     what your answer was.
-  any_stacktraces:
-  stacktrace_with_fix:
-  note:
+  any_stacktraces: false
+  stacktrace_with_fix: false
+  note: 'No provided stacktraces.'
 forgotten_check:
   question: |
     Does the fix for the vulnerability involve adding a forgotten check?
 
-    A "forgotten check" can mean many things. It often manifests as the fix
+    A 'forgotten check' can mean many things. It often manifests as the fix
     inserting an entire if-statement or a conditional to an existing
     if-statement. Or a call to a method that checks something.
 
@@ -364,8 +363,8 @@ 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 previous version of this code failed to check if the interrupt out was set. This created the opportunity to provide no interrupt out and crash the system.'
 order_of_operations:
   question: |
     Does the fix for the vulnerability involve correcting an order of
@@ -377,16 +376,16 @@ 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:
-lessons:
+  answer: true
+  note: 'Part of the fix involved moving the check for the existance of the interrupt in and interrupt out to another portion of the code so the check happened sooner.'
+lessons: 
   question: |
     Are there any common lessons we have learned from class that apply to this
     vulnerability? In other words, could this vulnerability serve as an example
     of one of those lessons?
 
-    Leave "applies" blank or put false if you did not see that lesson (you do
-    not need to put a reason). Put "true" if you feel the lesson applies and put
+    Leave 'applies' blank or put false if you did not see that lesson (you do
+    not need to put a reason). Put 'true' if you feel the lesson applies and put
     a quick explanation of how it applies.
 
     Don't feel the need to claim that ALL of these apply, but it's pretty likely
@@ -425,8 +424,8 @@ lessons:
     applies:
     note:
   complex_inputs:
-    applies:
-    note:
+    applies: true
+    note: 'This vulnerability is due to complex inputs. The provided serial device is the input in this case and the complexity of the inputs available on such a device is astronomical. This vulnerability is due to improper handling of this input.'
 mistakes:
   question: |
     In your opinion, after all of this research, what mistakes were made that
@@ -456,7 +455,7 @@ mistakes:
 
     Write a thoughtful entry here that people in the software engineering
     industry would find interesting.
-  answer:
+  answer: 'This issue was a lapse as it was simply a matter of forgetting to check both the interrupt in and interrupt out'
 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
@@ -469,14 +468,14 @@ CWE_instructions: |
 
   Just the number here is fine. No need for name or CWE prefix. If more than one
   apply here, then place them in an array like this
-    CWE: ["123", "456"] # this is ok
+    CWE: ['123', '456'] # this is ok
     CWE: [123, 456]     # also ok
     CWE: 123            # also ok
-CWE:
-CWE_note:
+CWE: 476
+CWE_note: 'CWE 476 is a null pointer dereference which is what is caused the crash.'
 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: 'Nullpointer Dereference'
 CVSS: