Dirty COW in Sentry

[서창호]

Hi, I'm trying to figure out how gVisor can prevent dirty cow vulnerability PoC.

I have some question that couldn't solved in my own.

so I read code in sentry in gVisor and it seems madvise() in sentry has locking so sentry can avoid race condition.

    

**in 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()

    ...

But I'm expecting there will be a structural reason why the gVisor has avoided a dirty cow vulnerability.

So I watched several videos and documents from gVisor, but they just demonstrated that gVisor can prevent from situation which write on read-only file.

  

And sadly, I couldn't found other reasons that how they can protected Read-only file from exploit code in those videos.

Does it mean same problem will be occurred just like normal docker if sentry also have a race condition in same point?

if so, Sentry will try to write to file as a root, and same problem will occur I think.

Or are there more fundamental reason which I missed?

[Ian Lewis]

Hi,

Good question!

gVisor does do locking on the memory manager in order to avoid the DirtyCow race condition. However, there is nothing fundamental about gVisor's Sentry that protects it from potentially harmful race conditions besides good coding practices and testing.

gVisor's more fundamental protection is in fact that the Sentry has two layers of isolation from the host. It runs as a user-space process in a locked down Linux container. So even IF an attacker finds a bug that allows them to execute code in the Sentry, the attacker would need an independent bug in the small Linux attack surface that is available in the Linux container. This protection applies to many types of security issues and not just DirtyCow.

I hope that answers the question.

Ian

--
You received this message because you are subscribed to the Google Groups "gVisor Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/ea916071-fd6b-42c2-9bad-58353276ea0f%40googlegroups.com.

--

Ian Lewis |

Developer Advocate |

ianl...@google.com |

+81 (03)4540-2465

[서창호]

your answer helps me a lot to understand strategy how gVisor protect system from exploits.

Thank you for your kind and accurate reply!

ChangHo.

2019년 10월 15일 화요일 오후 2시 31분 33초 UTC+9, 서창호 님의 말: