https://github.com/bigpick/cve-reading-list
https://github.com/bigpick/cve-reading-list
Last synced: 4 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/bigpick/cve-reading-list
- Owner: bigpick
- License: mit
- Created: 2022-03-07T18:35:12.000Z (over 4 years ago)
- Default Branch: main
- Last Pushed: 2022-03-14T19:21:26.000Z (over 4 years ago)
- Last Synced: 2025-11-12T03:22:34.916Z (8 months ago)
- Size: 7.81 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# My CVE, bug bounty, and general cybersec relevant reading list and notes
## Misc Links
* National Vulnerability Database: [here][13].
* NVD CVE search: [here][12].
* NVD data feeds listing: [here][11].
* CVE details CVSS distribution listing: [here][14].
* Mitre CVE search: [here][10].
* Pentesterland list of bug bounty writeups: [here][9].
* JFrog security research blogroll: [here][8].
* vuldb listing: [here][16].
---
## 2022
### March
| Title | Notes | CVE | Key Takeaways | Tags |
| --- | -- | --- | --- | --- |
| [GitLab GraphQL API User Enumeration][17] | | CVE-2021-4191 | Don't expose services to the internet unless you absolutely have to. Ensure all possible endpoints are subject to authentication if required | gitlab, hosting practices, enumeration |
| [Arbitrary command injection in `pipenv`][15] | | CVE-2022-21668 | Comments **weren't** ignored, because they were improperly parsing requirements files; if the thing you are parsing has a spec, parse it according to the spec. If it doesn't, make the people who own the thing you're parsing write one:) | pipenv, python |
| [The Impact of CVE-2022-0185 Linux Kernel Vulnerability on Popular Kubernetes Engines][5] and [CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google's KCTF Containers][6] | [here][7] | CVE-2022-0185 | Once again, `--privileged` and SECCOMP would help save the day. Don't disable them, people! Stay up to date on kernel updates. | containers, escape |
| [Can containers escape?][1] | [here][3] | CVE-2022-0492 | Securing containers with apparmor, selinux, or seccomp is a good idea. Also, up-to-date Linux releases are a good idea. | cgroups, containers, linux |
| [Escaping privileged containers for fun][2] | | | `mount` + `gcc` + `/proc/sys/kernel/core_pattern` + a privileged container --> arbitrary commands on container host | docker, escape, privileges |
### Notes
#### March
##### pwning Ubuntu and escaping Google
* Google's [syzkaller][14] looks interesting:
> syzkaller is an unsupervised coverage-guided kernel fuzzer
##### Can containers escape?
* `cgroups`, controlled by `cgroupfs`, provide means to limit/account/isolate the resource usage of a set of processes.
* further divided into subsystems, each responsible for a specific resource (e.g memory cgroup, device cgroup, etc)
* any further nested are new cgroups under that subsystem
* `cat /proc/self/cgroup` shows cgroup membership
* Arbitrary binaries (run with highest possible, root, permissions) can be ran by the termination of a proc in a cgroup if there has been a binary assigned to the subsystem's `release_agent`, and the child process has `notify_on_release` enabled.
* This is OK, if the system was checking that the child proc had the `CAP_SYS_ADMIN` perms to run it first. _It was not_.
* Writing to `notify_on_release` still requires `root` within the container.
* cgroups are RO mounts inside containers (`mount | grep "cgroup (ro"`)
* Utility helper/checker function: [Palo Alto Networks - can container escape][4]
---
[1]: "Can containers escape"
[2]:
[3]: <#can-containers-escape>
[4]:
[5]:
[6]:
[7]: <#pwning-ubuntu-and-escaping-google>
[8]:
[9]:
[10]:
[11]:
[12]:
[13]:
[14]:
[15]:
[16]:
[17]: