1

我试图弄清楚 gVisor 如何防止脏牛漏洞 PoC。

所以我在 gVisor 中阅读了哨兵中的代码，并且哨兵中的 madvise() 似乎已锁定，因此哨兵可以避免竞争条件。

在 pkg/sentry/mm/syscalls.go

// Decommit implements the semantics of Linux's madvise(MADV_DONTNEED).
func (mm *MemoryManager) Decommit(addr usermem.Addr, length uint64) error {
...
mm.mappingMu.RLock()
defer mm.mappingMu.RUnlock()
mm.activeMu.Lock()
defer mm.activeMu.Unlock()
...

但我预计 gVisor 避免脏牛漏洞存在结构性原因。

所以我看了几个gVisor的视频和文档，但他们只是证明了gVisor可以防止在只读文件上写入的情况。

可悲的是，我找不到其他原因来说明他们如何保护只读文件免受这些视频中的漏洞利用代码的影响。

如果哨兵在同一点也有竞争条件，这是否意味着会像正常的码头工人一样发生同样的问题？

如果是这样，Sentry 将尝试以 root 身份写入文件，我认为也会出现同样的问题。

还是我错过了更根本的原因？

4

1 回答 1

1

从 gVisor 邮件列表：

gVisor 确实会锁定内存管理器以避免 DirtyCow 竞争条件。然而，除了良好的编码实践和测试之外，gVisor 的 Sentry 并没有什么基本的东西可以保护它免受潜在有害竞争条件的影响。

gVisor 更基本的保护实际上是 Sentry 与主机有两层隔离。它在锁定的 Linux 容器中作为用户空间进程运行。因此，即使攻击者发现了一个允许他们在 Sentry 中执行代码的错误，攻击者也需要在 Linux 容器中可用的小型 Linux 攻击面中存在一个独立的错误。这种保护适用于许多类型的安全问题，而不仅仅是 DirtyCow。

- https://groups.google.com/d/msg/gvisor-users/ze-6LpPoDcQ/Y1jScf32CQAJ

于 2019-10-15T16:59:42.110 回答