diff --git a/CVE-2013-7348.yml b/CVE-2013-7348.yml new file mode 100644 index 000000000..aaa233697 --- /dev/null +++ b/CVE-2013-7348.yml @@ -0,0 +1,375 @@ +CVE: CVE-2013-7348 +CWE: + - 399 +ipc: + note: There are no commands within that function that utilizes signals, pipes, message passing, or standard input/output + answer: False + question: | + Did the feature that this vulnerability affected use inter-process + communication? IPC includes OS signals, pipes, stdin/stdout, message + passing, and clipboard. Writing to files that another program in this + software system reads is another form of 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. +CVSS: 4.6 +bugs: [] +i18n: + note: Internationalization pertains to user interfaces and input with different languages and characters. This function does not process user input. However, it does perform i/o functions on files. + answer: False + question: | + Was the feature impacted by this vulnerability about internationalization + (i18n)? + + An internationalization feature is one that enables people from all + over the world to use the system. This includes translations, locales, + typography, unicode, or various other features. + + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +vccs: + - note: Discovered automatically by archeogit. + commit: e23754f880f10124f0a2848f9d17e361a295378e +fixes: + - note: Add locking of q->sysfs_lock into elevator_change() (an exported function) to ensure it is held to protect q->elevator from elevator_init(), even if elevator_change() is called from non-sysfs paths. sysfs path (elv_iosched_store) uses __elevator_change(), non-locking version, as the lock is already taken by elv_iosched_store(). + commit: 7c8a3679e3d8e9d92d58f282161760a0e247df97 + - note: This fixes Report Descriptor for Logitech MOMO Force. By default the Logitech MOMO Force (Black) presents a combined accel/brake axis ('Y'). This patch modifies the HID descriptor to present seperate accel/brake axes ('Y' and 'Z'). + commit: 348cbaa800f8161168b20f85f72abb541c145132 + - note: Manually confirmed + commit: d558023207e008a4476a3b7bb8706b2a2bf5d84f +vouch: + note: While scrolling through kernel.org, there are many commits that consist of upstreams commits with members signing off on, and acknowledging other commits. + answer: True + question: > + Was there any part of the fix that involved one person vouching for another's work? + + + This can include: + * signing off on a commit message + * mentioning a discussion with a colleague checking the work + * upvoting a solution on a pull request + + Answer must be true or false. + + Write a note about how you came to the conclusions you did, regardless of what your answer was. +bounty: + amt: + url: + announced: +lessons: + yagni: + note: Input sanitization and error handling apply to this vulnerability, because with these practices, the risk posed by this vulnerability could be mitigated. + applies: True + 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 + a quick explanation of how it applies. + + Don't feel the need to claim that ALL of these apply, but it's pretty likely + that one or two of them apply. + + 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. + serial_killer: + note: + applies: False + complex_inputs: + note: + applies: True + distrust_input: + note: + applies: True + least_privilege: + note: + applies: False + native_wrappers: + note: + applies: False + defense_in_depth: + note: + applies: False + secure_by_default: + note: + applies: False + environment_variables: + note: + applies: False + security_by_obscurity: + note: + applies: False + frameworks_are_optional: + note: + applies: False +reviews: [] +sandbox: + note: If a threat actor gained control over the kernel, the vulnerability could be exploited to escape a sandbox. This could allow privilege escalation, resource access, and path traversal. + answer: True + question: | + Did this vulnerability violate a sandboxing feature that the system + provides? + + A sandboxing feature is one that allows files, users, or other features + limited access. Vulnerabilities that violate sandboxes are usually based on + access control, checking privileges incorrectly, path traversal, and the + like. + + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +upvotes: 0 +CWE_note: | + CWE as registered in the NVD. If you are curating, check that this + is correct and replace this comment with "Manually confirmed". +mistakes: + answer: The vulnerability described in CVE-2013-7348 may have arisen from a combination of coding mistakes, design flaws, and shortcomings in error handling. In this case, the code related to asynchronous I/O (AIO) operations within the Linux kernel may have lacked robust resource management, leading to memory corruption and potential privilege escalation. Coding mistakes, such as improper memory allocation and deallocation, could have played a role, as well as complex code that made it harder to identify vulnerabilities. Additionally, design flaws in the implementation of AIO and resource allocation might have contributed to the issue. Testing gaps and a potential lack of comprehensive security testing could have allowed the vulnerability to go undetected. Adequate documentation, clear security requirements, and heightened security awareness among developers and reviewers are essential in mitigating such vulnerabilities and maintaining robust security in software systems. + + question: | + In your opinion, after all of this research, what mistakes were made that + led to this vulnerability? Coding mistakes? Design mistakes? + Maintainability? Requirements? Miscommunications? + + There can, and usually are, many mistakes behind a vulnerability. + + Remember that mistakes can come in many forms: + * slip: failing to complete a properly planned step due to inattention + e.g. wrong key in the ignition + e.g. using < instead of <= + * lapse: failing to complete a properly planned step due to memory failure + e.g. forgetting to put car in reverse before backing up + e.g. forgetting to check null + * planning error: error that occurs when the plan is inadequate + e.g. getting stuck in traffic because you didn't consider the + impact of the bridge closing + e.g. calling the wrong method + e.g. using a poor design + + These are grey areas, of course. But do your best to analyze the mistakes + according to this framework. + + Look at the CWE entry for this vulnerability and examine the mitigations + they have written there. Are they doing those? Does the fix look proper? + + Write a thoughtful entry here that people in the software engineering + industry would find interesting. +nickname: +subsystem: + name: fs + note: This vulnerability involves asynchronous I/O (AIO) implementation, which deals with file I/O operations and resource management. Issues related to file I/O, memory allocation, and resource management are typically associated with the "fs" subsystem, as it deals with the file system operations and related kernel functionality. + question: > + What subsystems was the mistake in? These are WITHIN linux kernel + + + Determining the subsystem is a subjective task. This is to help us group + similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y + + Some areas to look for pertinent information: + - Bug labels + - Directory names + - How developers refer to an area of the system in comments, + commit messages, etc. + + Look at the path of the source code files code that were fixed to get + + directory names. Look at comments in the code. Look at the bug reports how + + the bug report was tagged. + + + Example linux kernel subsystems are: + * drivers + * crypto + * fs + * net + * lib + + Name should be: + * all lowercase English letters + * NOT a specific file + * can have digits, and _-@/ + + Can be multiple subsystems involved, in which case you can make it an array + + e.g. + name: ["subsystemA", "subsystemB"] # ok + name: subsystemA # also ok +discovered: + answer: After looking through kernel.org, openwall.com, and github, I wasn't able to find any evidence as to how this vulnerability was found. + contest: nil + 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 + 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. + + 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. + automated: nil + developer: nil +discussion: + note: https://mirrors.edge.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.0.10 + 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 + 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. + + + Example include: + * Is this out of our scope? + * Is this a security? + * How should we fix this? + + 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) + + Check the bugs reports, pull requests, and mailing lists archives. + + These answers should be boolean. + discussed_as_security: true or false + any_discussion: true or false + + Put any links to disagreements you found in the notes section, or any other + comment you want to make. + any_discussion: True + discussed_as_security: True +stacktrace: + note: + question: | + Are there any stacktraces in the bug reports? + + Secondly, if there is a stacktrace, is the fix in the same file that the + stacktrace points to? + + If there are no stacktraces, then both of these are false - but be sure to + mention where you checked in the note. + + 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: +description: +unit_tested: + fix: + code: + question: | + Were automated unit tests involved in this vulnerability? + Was the original code unit tested, or not unit tested? Did the fix involve + improving the automated tests? + + For code: and fix: - your answer should be boolean. + + For the code_answer below, look not only at the fix but the surrounding + code near the fix in related directories and determine if and was there were + unit tests involved for this subsystem. + + 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. + fix_answer: + code_answer: +reported_date: +specification: + note: + answer: + instructions: | + Is there mention of a violation of a specification? For example, the POSIX + spec, an RFC spec, a network protocol spec, or some other requirements + specification. + + Be sure to check the following artifacts for this: + * bug reports + * security advisories + * commit message + * mailing lists + * anything else + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. +announced_date: 2014-04-01 +curation_level: 2 +published_date: 2014-04-01 +forgotten_check: + note: + answer: + 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 + inserting an entire if-statement or a conditional to an existing + if-statement. Or a call to a method that checks something. + + Example of checks can include: + * null pointer checks + * check the current role, e.g. root + * boundary checks for a number + * consult file permissions + * check a return value + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +autodiscoverable: + note: + answer: + instructions: | + Is it plausible that a fully automated tool could have discovered + this? These are tools that require little knowledge of the domain, + e.g. automatic static analysis, compiler warnings, fuzzers. + + Examples for true answers: SQL injection, XSS, buffer overflow + + 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 + domain-specific requirements. + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. +interesting_commits: + commits: + - note: + commit: + - note: + commit: + question: | + Are there any interesting commits between your VCC(s) and fix(es)? + + Use this to specify any commits you think are notable in some way, and + explain why in the note. + + Example interesting commits: + * Mentioned as a problematic commit in the past + 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. +order_of_operations: + note: The fix involves error handling. It does not include include moving the code. + answer: False + question: | + Does the fix for the vulnerability involve correcting an order of + operations? + + This means the fix involves moving code around or changing the order of + how things are done. + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. diff --git a/CVE-2022-3105.yml b/CVE-2022-3105.yml new file mode 100644 index 000000000..d6158e195 --- /dev/null +++ b/CVE-2022-3105.yml @@ -0,0 +1,371 @@ +CVE: CVE-2022-3105 +CWE: + - 476 +ipc: + note: This is primarily used for communication between user-space applications and kernel-space InfiniBand (IB) and Remote Direct Memory Access (RDMA) drivers. It doesn't directly deal with inter-process communication (IPC) mechanisms such as OS signals, pipes, stdin/stdout, message passing, clipboard, or file-based IPC. + answer: False + question: | + Did the feature that this vulnerability affected use inter-process + communication? IPC includes OS signals, pipes, stdin/stdout, message + passing, and clipboard. Writing to files that another program in this + software system reads is another form of 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. +CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H +bugs: [2153067] +i18n: + note: It is unlikely that the vulnerabilities or issues related to this code have a direct impact on internationalization (i18n) features. Internationalization features in software are generally concerned with providing support for different languages, character encodings, locales, and user interface translations, among other aspects. + answer: False + question: | + Was the feature impacted by this vulnerability about internationalization + (i18n)? + + An internationalization feature is one that enables people from all + over the world to use the system. This includes translations, locales, + typography, unicode, or various other features. + + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +vccs: + - note: Discovered automatically by archeogit. + commit: 6884c6c4bd09fb35b79a3967d15821cdfcbe77a3 +fixes: + - note: + commit: + - note: + commit: + - note: Manually confirmed + commit: 7694a7de22c53a312ea98960fcafc6ec62046531 +vouch: + note: I checked the kernel.org hyperlink in the references section of nvd + answer: True + question: > + Was there any part of the fix that involved one person vouching for + + another's work? + + + This can include: + * signing off on a commit message + * mentioning a discussion with a colleague checking the work + * upvoting a solution on a pull request + + Answer must be true or false. + + Write a note about how you came to the conclusions you did, regardless of what your answer was. +bounty: + amt: + url: + announced: +lessons: + yagni: + note: + applies: [distrust_input, complex_input] + 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 + a quick explanation of how it applies. + + Don't feel the need to claim that ALL of these apply, but it's pretty likely + that one or two of them apply. + + 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. + serial_killer: + note: + applies: False + complex_inputs: + note: error handling can have errors smoothly handled if a null pointer is dereferenced + applies: True + distrust_input: + note: input validation can be used to avoid a null pointer dereference + applies: True + least_privilege: + note: + applies: False + native_wrappers: + note: + applies: False + defense_in_depth: + note: + applies: False + secure_by_default: + note: + applies: False + environment_variables: + note: + applies: False + security_by_obscurity: + note: + applies: False + frameworks_are_optional: + note: + applies: False +reviews: [] +sandbox: + note: This vulnerability relates more to memory allocation and error handling as opposed to sandboxing violations or access control issues. + answer: False + question: | + Did this vulnerability violate a sandboxing feature that the system + provides? + + A sandboxing feature is one that allows files, users, or other features + limited access. Vulnerabilities that violate sandboxes are usually based on + access control, checking privileges incorrectly, path traversal, and the + like. + + Answer should be true or false + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +upvotes: 0 +CWE_note: Manually confirmed +mistakes: + answer: The vulnerability stems from coding mistakes and design flaws. The critical coding mistake lies in the failure to check the result of a memory allocation operation, specifically, the use of kmalloc_array. This error handling oversight can be attributed to a lack of attention to the return value of the allocation function. Design mistakes may also be relevant if there are patterns of a lack of error handling and memory management throughout the code. Miscommunications could have contributed improper error handling practices in the code but there is no evidence that miscommunication is the direct cause. + + question: | + In your opinion, after all of this research, what mistakes were made that + led to this vulnerability? Coding mistakes? Design mistakes? + Maintainability? Requirements? Miscommunications? + + There can, and usually are, many mistakes behind a vulnerability. + + Remember that mistakes can come in many forms: + * slip: failing to complete a properly planned step due to inattention + e.g. wrong key in the ignition + e.g. using < instead of <= + * lapse: failing to complete a properly planned step due to memory failure + e.g. forgetting to put car in reverse before backing up + e.g. forgetting to check null + * planning error: error that occurs when the plan is inadequate + e.g. getting stuck in traffic because you didn't consider the + impact of the bridge closing + e.g. calling the wrong method + e.g. using a poor design + + These are grey areas, of course. But do your best to analyze the mistakes + according to this framework. + + Look at the CWE entry for this vulnerability and examine the mitigations + they have written there. Are they doing those? Does the fix look proper? + + Write a thoughtful entry here that people in the software engineering + industry would find interesting. +nickname: NULL Pointer Dereference +subsystem: + name: RDMA + note: this is known because of the headers directly referencing rdma, the function names, and the subsystem references. + question: > + What subsystems was the mistake in? These are WITHIN linux kernel + + + Determining the subsystem is a subjective task. This is to help us group + similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y + + Some areas to look for pertinent information: + - Bug labels + - Directory names + - How developers refer to an area of the system in comments, + commit messages, etc. + + Look at the path of the source code files code that were fixed to get + + directory names. Look at comments in the code. Look at the bug reports how + + the bug report was tagged. + + + Example linux kernel subsystems are: + * drivers + * crypto + * fs + * net + * lib + + Name should be: + * all lowercase English letters + * NOT a specific file + * can have digits, and _-@/ + + Can be multiple subsystems involved, in which case you can make it an array + + e.g. + name: ["subsystemA", "subsystemB"] # ok + name: subsystemA # also ok +discovered: + answer: 2022-12-13 + contest: False + 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 + 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. + + 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. + automated: False + developer: True +discussion: + note: I was not able to find any disagreements + question: | + Was there any discussion surrounding this? + + A discussion can include debates, disputes, or polite talk about how to + resolve uncertainty. + + Example include: + * Is this out of our scope? + * Is this a security? + * How should we fix this? + + 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) + + Check the bugs reports, pull requests, and mailing lists archives. + + These answers should be boolean. + discussed_as_security: true or false + any_discussion: true or false + + Put any links to disagreements you found in the notes section, or any other + comment you want to make. + any_discussion: True + discussed_as_security: True +stacktrace: + note: + question: | + Are there any stacktraces in the bug reports? + + Secondly, if there is a stacktrace, is the fix in the same file that the + stacktrace points to? + + If there are no stacktraces, then both of these are false - but be sure to + mention where you checked in the note. + + 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: +description: +unit_tested: + fix: + code: True + question: | + Were automated unit tests involved in this vulnerability? + Was the original code unit tested, or not unit tested? Did the fix involve + improving the automated tests? + + For code: and fix: - your answer should be boolean. + + For the code_answer below, look not only at the fix but the surrounding + code near the fix in related directories and determine if and was there were + unit tests involved for this subsystem. + + 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. + fix_answer: + code_answer: +reported_date: 2022-12-13 +specification: + note: POSIX may be violated by failing to handle memory allocation errors. + answer: True + instructions: | + Is there mention of a violation of a specification? For example, the POSIX + spec, an RFC spec, a network protocol spec, or some other requirements + specification. + + Be sure to check the following artifacts for this: + * bug reports + * security advisories + * commit message + * mailing lists + * anything else + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. +announced_date: 2022-12-14 +curation_level: 2 +published_date: 2022-12-14 +forgotten_check: + note: This is shown in the kernel.org fix demonstrated by jiasheng jiang. According to the log, the author inserted code to check the data variable. + answer: True + 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 + inserting an entire if-statement or a conditional to an existing + if-statement. Or a call to a method that checks something. + + Example of checks can include: + * null pointer checks + * check the current role, e.g. root + * boundary checks for a number + * consult file permissions + * check a return value + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was. +autodiscoverable: + note: An empty dataset would trigger this vulnerability + answer: True + instructions: | + Is it plausible that a fully automated tool could have discovered + this? These are tools that require little knowledge of the domain, + e.g. automatic static analysis, compiler warnings, fuzzers. + + Examples for true answers: SQL injection, XSS, buffer overflow + + 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 + domain-specific requirements. + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. +interesting_commits: + commits: + - note: + commit: + - note: + commit: + question: | + Are there any interesting commits between your VCC(s) and fix(es)? + + Use this to specify any commits you think are notable in some way, and + explain why in the note. + + Example interesting commits: + * Mentioned as a problematic commit in the past + 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. +order_of_operations: + note: The fix requires adding a check for memory allocation prior to dereferencing + answer: False + question: | + Does the fix for the vulnerability involve correcting an order of + operations? + + This means the fix involves moving code around or changing the order of + how things are done. + + Answer must be true or false. + Write a note about how you came to the conclusions you did, regardless of + what your answer was.