Hacker News new | past | comments | ask | show | jobs | submit login

I would recommend not giving that advice, and recommend that all your customers upgrade. There are a number of ways to exploit this, and as stated elsewhere on this thread Red Hat's advice that SeLinux entirely mitigates this is not correct, it is highly likely that it can be exploited on Cloud Foundry too. I would never advise people to not upgrade software when there is a CVE because someone says there is a mitigation, it is very high risk.

Disclosure: I worked on testing the fixes for this CVE.




Thanks for your comment. We (Garden - Cloud Foundry container project) released with the runc patch yesterday (https://github.com/cloudfoundry/garden-runc-release/releases...).

It was our understanding from the original report that the vulnerability was mitigated by AppArmor disabling ptrace, by no user process running as pid 1 inside the container, and because in CF buildpack apps, user processes run as unprivileged users. This is the stance communicated in the CVE report.

However, with some further consideration and updated information yesterday, we decided it would be prudent to patch and release immediately to be on the safe side. This was communicated to the Cloud Foundry Security team.


User processes running as unprivileged users may be sufficient to mitigate. AppArmor did not always during testing. But upgrade is highly recommended as there were several ways to exploit and different races, including one related kernel bug that was fixed in very recent releases.


> It was our understanding from the original report that the vulnerability was mitigated by AppArmor disabling ptrace, by no user process running as pid 1 inside the container, and because in CF buildpack apps, user processes run as unprivileged users. This is the stance communicated in the CVE report.

I'd have to think about this further, but I'm not convinced that would be sufficient protection (accessing /proc/$pid/fd has a different set of access requirements to ptrace -- it's a dumpability check basically). However, since you've already sent patches around it's all good.

Disclosure: I discovered, wrote patches for and helped with coordination of this vuln.


Agree. This was the initial stance, when the focus (our misunderstanding) appeared to be on ptrace as the only vulnerability rather than ptrace as the means to easily exploit the vulnerability. Once we had a better understanding, we were also not convinced that this provided total protection.


If you'd like to email me, I can connect you to our security triage team to argue the case.

If we're wrong, we'll change it.

Edit: looks like we already did.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: