diff --git a/cves/kernel/CVE-2015-5366.yml b/cves/kernel/CVE-2015-5366.yml
index 4e5512136..4d7511b34 100644
--- a/cves/kernel/CVE-2015-5366.yml
+++ b/cves/kernel/CVE-2015-5366.yml
@@ -55,7 +55,10 @@ description_instructions: |
Your target audience is people just like you before you took any course in
security
-description:
+description:
+ The udp_revmsg and udpv6_recvmsg functions in the linux kernel that provide
+ inappropriate EAGAIN return values. This allows attackers to perform a DOS via
+ incorrect checksum in a UDP packet
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: ["1478843", "1479369", "1479370"]
fixes_instructions: |
Please put the commit hash in "commit" below.
@@ -136,9 +139,11 @@ 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_answer:
+ Returns -EAGAIN to the application even if recieve queue is not empty.
+ This breaks the application using edge trigger epoll()
+ fix: false
+ fix_answer: remove the code that was causing the incorrect return statement
discovered:
question: |
How was this vulnerability discovered?
@@ -153,10 +158,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 found in a twitter message where the security team was
+ contacted to create the CVE,
+ automated: false
+ contest: nil
+ developer: nil
autodiscoverable:
instructions: |
Is it plausible that a fully automated tool could have discovered
@@ -173,8 +180,12 @@ autodiscoverable:
The answer field should be boolean. In answer_note, please explain
why you come to that conclusion.
- note:
- answer:
+ note:
+ The reason why this bug can be discovered automatically is because the
+ bug causes a DOS attack because it causes an infinite loop making it so
+ that users can't get acces to the data. This can be tested automatically
+ by tesitng edge cases for return values.
+ answer: true
specification:
instructions: |
Is there mention of a violation of a specification? For example, the POSIX
@@ -190,8 +201,10 @@ specification:
The answer field should be boolean. In answer_note, please explain
why you come to that conclusion.
- note:
- answer:
+ note:
+ there was no violation of a specification as the bug appeared from not
+ properly checking and validating the result before returning it.
+ answer: false
subsystem:
question: |
What subsystems was the mistake in? These are WITHIN linux kernel
@@ -225,7 +238,7 @@ subsystem:
e.g.
name: ["subsystemA", "subsystemB"] # ok
name: subsystemA # also ok
- name:
+ name: This bug affect the net subsystem
note:
interesting_commits:
question: |
@@ -240,9 +253,15 @@ interesting_commits:
* A significant rewrite in the git history
* Other commits that fixed a similar issue as this vulnerability
* Anything else you find interesting.
- commits:
- - commit:
+ commits:
+ - commit:
+ beb39db59d14990e401e235faf66a6b9b31240b0
note:
+ The reason that I found this commit interesting is because the
+ developer mentions that it could only be tempory solution and
+ says that they might return to it later. This makes it seem that
+ the developer was not sure if the fix would work and thought it
+ would just be a band-aid on the problem.
- commit:
note:
i18n:
@@ -257,8 +276,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 main thing that was impacted this was the accesibiliy to the public becaue
+ the DOS would make it so that people would not be able to access the application
sandbox:
question: |
Did this vulnerability violate a sandboxing feature that the system
@@ -272,8 +293,11 @@ 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:
+ answer: true
note:
+ Since the attacker is able to cause a DOS attack because this vulnerability
+ it affects the accesibility of the application which interferes with
+ internationalization
ipc:
question: |
Did the feature that this vulnerability affected use inter-process
@@ -284,8 +308,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:
+ answer: true
note:
+ This vulnerability directly affected UDP connection as it was interrupting the
+ UDP stack causing trouble with communication.
discussion:
question: |
Was there any discussion surrounding this?
@@ -312,8 +338,11 @@ discussion:
Put any links to disagreements you found in the notes section, or any other
comment you want to make.
discussed_as_security:
+ The discussion is talking about the security risk of the invalid checksum and
+ what threat it is to the system
any_discussion:
note:
+ https://seclists.org/oss-sec/2015/q3/10
vouch:
question: |
Was there any part of the fix that involved one person vouching for
@@ -326,8 +355,10 @@ vouch:
Answer must be true or false.
Write a note about how you came to the conclusions you did, regardless of what your answer was.
- answer:
+ answer: true
note:
+ This is because the on the commit message fixing the bug it was signed off by both Eric Dumazet and
+ David S. Miller. https://github.com/torvalds/linux/commit/beb39db59d14990e401e235faf66a6b9b31240b0
stacktrace:
question: |
Are there any stacktraces in the bug reports?
@@ -341,9 +372,12 @@ stacktrace:
Answer must be true or false.
Write a note about how you came to the conclusions you did, regardless of
what your answer was.
- any_stacktraces:
- stacktrace_with_fix:
- note:
+ any_stacktraces: false
+ stacktrace_with_fix: false
+ note:
+ The main reason why there are no stacktraces is that the error
+ causes an infinite loop causing the program to hang instead of a
+ stack trace.
forgotten_check:
question: |
Does the fix for the vulnerability involve adding a forgotten check?
@@ -362,8 +396,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:
+ answer: true
note:
+ The fix involved having to check if the return value for the udp was valid
+ befoe returning the value.
order_of_operations:
question: |
Does the fix for the vulnerability involve correcting an order of
@@ -375,8 +411,10 @@ 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:
+ This is because the only thing that needed to be change was to add a
+ check to make sure the return value is valid before returning.
lessons:
question: |
Are there any common lessons we have learned from class that apply to this
@@ -396,22 +434,22 @@ lessons:
applies:
note:
least_privilege:
- applies:
+ applies: false
note:
frameworks_are_optional:
- applies:
+ applies: false
note:
native_wrappers:
- applies:
+ applies: false
note:
distrust_input:
applies:
note:
security_by_obscurity:
- applies:
+ applies: false
note:
serial_killer:
- applies:
+ applies: false
note:
environment_variables:
applies:
@@ -420,8 +458,11 @@ lessons:
applies:
note:
yagni:
- applies:
- note:
+ applies: true
+ note:
+ This is because the check for valid return value
+ was not added until the developers realized that threat
+ actors could exploit it.
complex_inputs:
applies:
note:
@@ -454,7 +495,9 @@ mistakes:
Write a thoughtful entry here that people in the software engineering
industry would find interesting.
- answer:
+ answer:
+ There was a lapse in judgment in that the developers forgot to
+ check if the return value was valid.
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
diff --git a/cves/kernel/CVE-2016-2184.yml b/cves/kernel/CVE-2016-2184.yml
index 5899d0467..89ca5ce8c 100644
--- a/cves/kernel/CVE-2016-2184.yml
+++ b/cves/kernel/CVE-2016-2184.yml
@@ -56,6 +56,9 @@ description_instructions: |
Your target audience is people just like you before you took any course in
security
description:
+ This is a bug that causes a null-pointer error when there are no USB devices
+ connected. This allows a threat actor to crash the system and cause a denial
+ of service in the system.
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: [1317012]
fixes_instructions: |
Please put the commit hash in "commit" below.
@@ -84,14 +87,16 @@ fixes_instructions: |
Place any notes you would like to make in the notes field.
fixes:
-- commit:
+- commit: '0f886ca12765d20124bd06291c82951fd49a33be'
note:
+ This bug causes a NULL-pointer dereference by
+ accessing the non-existing endpoint when a USB device with a malformed USB
+ descriptor is used. This patch avoids it simply by adding a sanity check of
+ bNumEndpoints before the accesses.
- commit:
note:
-- commit: 0f886ca12765d20124bd06291c82951fd49a33be
+- commit:
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'
vcc_instructions: |
The vulnerability-contributing commits.
@@ -118,8 +123,11 @@ 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:
-unit_tested:
+ upvotes: 7
+ unit_tested:
+ false
question: |
Were automated unit tests involved in this vulnerability?
Was the original code unit tested, or not unit tested? Did the fix involve
@@ -133,10 +141,14 @@ 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:
+ code: false
+ code_answer:
+ added a check to make sure that the number of endpoints is greater than 1
+ then taking action based on that
+ fix: true
fix_answer:
+ The fix was adding a check to make sure that the number of endpoints was
+ greater than 1
discovered:
question: |
How was this vulnerability discovered?
@@ -151,11 +163,13 @@ discovered:
If there is no evidence as to how this vulnerability was found, then please
explain where you looked.
- answer:
- automated:
- contest:
- developer:
-autodiscoverable:
+ answer:
+ The bug was found using the USB-fuzzing framework from SergeJ Shumilo. This
+ found out that the crash was caused by a zero value for the number of endpoints.
+ automated: true
+ contest: nil
+ developer: nil
+autodiscoverable:
instructions: |
Is it plausible that a fully automated tool could have discovered
this? These are tools that require little knowledge of the domain,
@@ -171,8 +185,11 @@ autodiscoverable:
The answer field should be boolean. In answer_note, please explain
why you come to that conclusion.
- note:
+ note:
+ https://seclists.org/bugtraq/2016/Mar/89 The developers used a
+ USB-fuzzing framework to discover the bug.
answer:
+ true
specification:
instructions: |
Is there mention of a violation of a specification? For example, the POSIX
@@ -189,7 +206,9 @@ specification:
The answer field should be boolean. In answer_note, please explain
why you come to that conclusion.
note:
- answer:
+ This is because the application did not check the number of endpoints
+ when they should have.
+ answer: true
subsystem:
question: |
What subsystems was the mistake in? These are WITHIN linux kernel
@@ -223,7 +242,7 @@ subsystem:
e.g.
name: ["subsystemA", "subsystemB"] # ok
name: subsystemA # also ok
- name:
+ name: Sound
note:
interesting_commits:
question: |
@@ -255,8 +274,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:
+ This bug does not affect internationalization as it only impacts
+ being able to connect to USB devices.
sandbox:
question: |
Did this vulnerability violate a sandboxing feature that the system
@@ -270,8 +291,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:
+ answer: true
note:
+ This is because the user might not be able to connect to the application
+ via USB and be able to use the audio.
ipc:
question: |
Did the feature that this vulnerability affected use inter-process
@@ -282,8 +305,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:
+ answer: true
note:
+ This is because the bug impacts the USB connection which transfers data using packets.
discussion:
question: |
Was there any discussion surrounding this?
@@ -309,8 +333,8 @@ 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:
+ discussed_as_security: false
+ any_discussion: false
note:
vouch:
question: |
@@ -324,8 +348,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:
+ answer: true
note:
+ Takashi Iwai signed off the commit that fixed the error in github.
stacktrace:
question: |
Are there any stacktraces in the bug reports?
@@ -339,9 +364,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:
+ any_stacktraces: true
+ stacktrace_with_fix: false
note:
+ There was a message sent explaning the details of the bug that included a
+ stacktrace. https://seclists.org/bugtraq/2016/Mar/88
forgotten_check:
question: |
Does the fix for the vulnerability involve adding a forgotten check?
@@ -360,8 +387,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:
+ answer: true
note:
+ This is because there was a forgotten check if the number of endpoints is
+ greater than 0.
order_of_operations:
question: |
Does the fix for the vulnerability involve correcting an order of
@@ -373,8 +402,10 @@ 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 only fix that was needed was to make sure that there were more than
+ one endpoints.
lessons:
question: |
Are there any common lessons we have learned from class that apply to this
@@ -390,38 +421,40 @@ 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:
+ defense_in_depth:
+ applies: false
note:
least_privilege:
- applies:
+ applies: false
note:
frameworks_are_optional:
- applies:
+ applies: false
note:
native_wrappers:
- applies:
+ applies: false
note:
distrust_input:
- applies:
- note:
+ applies: true
+ note: The reason the error was happening was because of an unsanitized input
security_by_obscurity:
- applies:
+ applies: false
note:
serial_killer:
- applies:
+ applies: false
note:
environment_variables:
- applies:
- note:
+ applies: true
+ note:
+ The reason the error was happening was because there was nothing checking
+ the endpoint value
secure_by_default:
- applies:
+ applies: false
note:
yagni:
- applies:
+ applies: false
note:
complex_inputs:
- applies:
+ applies: false
note:
mistakes:
question: |
@@ -453,6 +486,9 @@ mistakes:
Write a thoughtful entry here that people in the software engineering
industry would find interesting.
answer:
+ The main mistake that was made in this application was not sanitizing
+ the inputs to check and see if there was moe than one endpoint connected
+ via USB.
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