Docker Engine 19.03发行说明

15年3月19日

2021-02-01

安全

  • CVE-2021-21285防止无效映像崩溃docker守护程序
  • CVE-2021-21284锁定文件权限以防止重新映射的根访问docker状态
  • 确保在使用BuildKit进行构建时应用了AppArmor和SELinux配置文件

客户

  • 在导入上下文之前检查上下文，以减少提取的文件逃避上下文存储的风险

14.03.14

2020-12-01

安全

建造者

联网

运行

无根

记录中

19.03.13

2020-09-16

建造者

客户

联网

无根

运行

视窗

12.03.12

2020-06-18

客户

  • 修复了使用多个配置文件（例如，使用Docker Desktop时使用Windows vs WSL2）时无法从注册表注销的错误docker / cli＃2592
  • 修复回归问题，防止上下文元数据被读取docker / cli＃2586
  • 凹凸Golang 1.13.12 docker / cli＃2575

联网

运行

11.03.11

2020-06-01

网络

禁用IPv6路由器广告以防止地址欺骗。CVE-2020-13401

描述

在Docker默认配置中，容器网络接口是连接到主机（虚拟接口）的虚拟以太网链接。在此配置中，能够以容器的root用户身份运行进程的攻击者可以使用此CAP_NET_RAW功能（默认配置中存在）向主机发送和接收任意数据包。

如果未在主机上完全禁用IPv6（通过ipv6.disable=1内核cmdline），则将在某些接口上未配置IPv6或对其进行配置，但是很有可能已禁用了ipv6转发，即/proc/sys/net/ipv6/conf//forwarding == 0。也是默认情况下/proc/sys/net/ipv6/conf//accept_ra == 1。这两个系统的组合意味着主机接受路由器通告并使用它们配置IPv6堆栈。

通过从容器发送“恶意”路由器广告，攻击者可以重新配置主机，以将主机的部分或全部IPv6通信重定向到攻击者控制的容器。

即使以前没有IPv6流量，如果DNS返回A（IPv4）和AAAA（IPv6）记录，许多HTTP库将尝试先通过IPv6连接，然后回退到IPv4，这为攻击者提供了响应的机会。如果主机偶然遇到像去年的RCE这样的漏洞（CVE-2019-3462），则攻击者现在可以升级到主机。

正如CAP_NET_ADMINDocker容器默认情况下不存在的那样，攻击者无法将其想要配置为MitM的IP，他们不能使用iptables进行NAT或重定向流量，也不能使用IP_TRANSPARENT。但是，攻击者仍然可以CAP_NET_RAW在用户空间中使用和实现tcp / ip堆栈。

有关相关问题，请参见kubernetes / kubernetes＃91507。

19.03.10

2020-05-29

客户

联网

运行

包装

19.03.9

2020-05-14

建造者

客户

记录中

  • 避免由于关闭已关闭的日志文件而导致容器日志无法旋转的情况。莫比/莫比＃40921

联网

运行

无根

安全

一群

19.03.8

2020-03-10

运行

19.03.7

2020-03-03

建造者

运行

客户

19.03.6

2020-02-12

建造者

联网

运行

19.03.5

2019-11-14

建造者

包装

  • 支持RHEL 8软件包

运行

19.03.4

2019-10-17

联网

已知的问题

现存的

  • 在大型集群的某些情况下，作为Swarm部分的一部分，Docker信息可能包含error code = ResourceExhausted desc = grpc: received message larger than max (5351376 vs. 4194304)。这并不表示用户有任何故障或配置错误，并且不需要响应。
  • 将所有服务重新部署为新服务时，可能会发生Orchestrator端口冲突。由于在短时间内有许多Swarm管理器请求，因此某些服务无法接收流量，并且404 在部署后会导致错误。
    • 解决方法：通过重新启动所有任务docker service update --force。
  • 带有目录遍历的CVE-2018-15664 symlink-exchange攻击。解决方法，直到在即将进行的修补程序发行版中提供适当的修复程序：docker pause容器之前执行文件操作。莫比/莫比＃39252
  • docker cpCVE缓解导致的回归。当的来源docker cp设为时，会产生错误/。

19.03.3

2019-10-08

安全

建造者

客户

运行

已知的问题

新的

  • DOCKER-USERiptables链丢失：docker / for-linux＃810。用户无法在此iptables链上执行其他容器网络流量过滤。如果您不自定义iptable链，则不会受到此问题的影响DOCKER-USER。
    • 解决办法：在docker守护程序启动后插入iptables链。例如： 
      iptables -N DOCKER-USER
iptables -I FORWARD -j DOCKER-USER
iptables -A DOCKER-USER -j RETURN

现存的

  • 在某些集群较大的情况下，作为Swarm部分的一部分，docker信息可能包含error code = ResourceExhausted desc = grpc: received message larger than max (5351376 vs. 4194304)。这并不表示用户有任何故障或配置错误，并且不需要响应。
  • 将所有服务重新部署为新服务时，可能会发生Orchestrator端口冲突。由于短时间内有许多群集管理器请求，因此某些服务无法接收流量，并且404 在部署后会导致错误。
    • 解决方法：通过重新启动所有任务docker service update --force。
  • 带有目录遍历的CVE-2018-15664 symlink-exchange攻击。解决方法，直到在即将进行的修补程序发行版中提供适当的修复程序：docker pause容器之前执行文件操作。莫比/莫比＃39252
  • docker cpCVE缓解导致的回归。当的来源docker cp设为时，会产生错误/。

19.03.2

2019-09-03

建造者

客户

记录中

联网

运行

  • 将Golang升至1.12.8。

  • 当对容器使用XFS磁盘配额时，修复潜在的引擎恐慌。莫比/莫比＃39644

一群

已知的问题

  • 在某些集群较大的情况下，作为Swarm部分的一部分，docker信息可能包含error code = ResourceExhausted desc = grpc: received message larger than max (5351376 vs. 4194304)。这并不表示用户有任何故障或配置错误，并且不需要响应。
  • 将所有服务重新部署为新服务时，可能会发生Orchestrator端口冲突。由于短时间内有许多群集管理器请求，因此某些服务无法接收流量，并且404 在部署后会导致错误。
    • 解决方法：通过重新启动所有任务docker service update --force。
  • 由于缺少FORWARD链中的Iptables规则，流量无法流出HOST。缺少的规则是： 
       /sbin/iptables --wait -C FORWARD -o docker_gwbridge -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
   /sbin/iptables --wait -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    • 解决方法：使用脚本和cron定义重新添加这些规则。该脚本必须包含“ -C”命令以检查规则的存在，以及“ -A”命令以添加规则。定期在cron上运行脚本，例如，每个 分钟。
    • 受影响的版本：18.09.1、19.03.0
  • 带有目录遍历的CVE-2018-15664 symlink-exchange攻击。解决方法，直到在即将进行的修补程序发行版中提供适当的修复程序：docker pause容器之前执行文件操作。莫比/莫比＃39252
  • docker cpCVE缓解导致的回归。当的来源docker cp设为时，会产生错误/。

19.03.1

2019-07-25

安全

  • 修复了在Glibc下将基于nsswitch的配置加载到chroot中的问题。CVE-2019-14271

已知的问题

  • 在某些情况下，在大型集群中，泊坞窗信息可能会作为Swarm部分的一部分包含error code = ResourceExhausted desc = grpc: received message larger than max (5351376 vs. 4194304)。这并不表示用户有任何故障或配置错误，并且不需要响应。
  • 将所有服务重新部署为新服务时，可能会发生Orchestrator端口冲突。由于短时间内有许多群集管理器请求，因此某些服务无法接收流量，并且404 在部署后会导致错误。
    • 解决方法：通过重新启动所有任务docker service update --force。
  • 由于缺少FORWARD链中的Iptables规则，流量无法流出HOST。缺少的规则是： 
      /sbin/iptables --wait -C FORWARD -o docker_gwbridge -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
  /sbin/iptables --wait -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    • 解决方法：使用脚本和cron定义重新添加这些规则。该脚本必须包含“ -C”命令以检查规则的存在，以及“ -A”命令以添加规则。定期在cron上运行脚本，例如，每个 分钟。
    • 受影响的版本：18.09.1、19.03.0
  • 带有目录遍历的CVE-2018-15664 symlink-exchange攻击。解决方法，直到在即将进行的修补程序发行版中提供适当的修复程序：docker pause容器之前执行文件操作。莫比/莫比＃39252
  • docker cpCVE缓解导致的回归。当的来源docker cp设为时，会产生错误/。

19.03.0

2019-07-22

建造者

客户

原料药

实验性

安全

运行

联网

一群

记录中

弃用

有关不推荐使用的标志和API的更多信息，请参阅https://docs.docker.com/engine/deprecated/了解目标删除日期。

已知的问题

  • 在某些集群较大的情况下，作为Swarm部分的一部分，docker信息可能包含error code = ResourceExhausted desc = grpc: received message larger than max (5351376 vs. 4194304)。这并不表示用户有任何故障或配置错误，并且不需要响应。
  • 将所有服务重新部署为新服务时，可能会发生Orchestrator端口冲突。由于短时间内有许多群集管理器请求，因此某些服务无法接收流量，并且404 在部署后会导致错误。
    • 解决方法：通过重新启动所有任务docker service update --force。
  • 由于缺少FORWARD链中的Iptables规则，流量无法流出HOST。缺少的规则是： 
      /sbin/iptables --wait -C FORWARD -o docker_gwbridge -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
  /sbin/iptables --wait -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    • 解决方法：使用脚本和cron定义重新添加这些规则。该脚本必须包含“ -C”命令以检查规则的存在，以及“ -A”命令以添加规则。定期在cron上运行脚本，例如，每个 分钟。
    • 受影响的版本：18.09.1、19.03.0
  • 带有目录遍历的CVE-2018-15664 symlink-exchange攻击。解决方法，直到在即将进行的修补程序发行版中提供适当的修复程序：docker pause容器之前执行文件操作。莫比/莫比＃39252
  • docker cpCVE缓解导致的回归。当的来源docker cp设为时，会产生错误/。