New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CVE-2019-5736 #2401
Comments
|
This blog post has some additional details and seems to indicate that Firejail is not vulnerable, the key part being
Firejail has everything in one binary and in general outlives the sandboxed process. In other words, Firejail's situation is more similar to LXC than to runc, with the added advantage that we don't have an equivalent to the Only killing a master process with a signal other than SIGTERM or SIGINT (e.g. In any case |
|
After playing with publicly available exploit code, I can confirm there is a problem if following conditions are met:
Because this is a sandbox escape, the obligatory read-only mount and So for the time being, if your sandboxes are root and you need to hard kill a sandbox ( |
@smitsohu Is this what happens currently when using |
|
@glitsj16 it sends a SIGTERM and if after 10 seconds it hasn't closed it sends a SIGKILL. |
|
@SkewedZeppelin I noticed the SIGTERM/SIGKILL routine, thanks for explaining. If I read shutdown.c correctly, the SIGKILL goes to the child first. But I'm at best a beginner with C. And I was unsure too if that corresponds with what smithsohu refers to as first/second firejail process. Currently I don't have any firejail sandbox running as root, so I shouldn't have to worry about this. Sorry for the noise here, it's reassuring to see CVE's are getting proper attention/discussion in firejail! |
|
@glitsj16 yes,
Anyway, |
And that was wrong, |
|
|
cf. #2401 increase head start to a full second
For clarification, did profiles with noroot protect against this even if the parent process was killed before the child? |
I would say yes, Edit: |
|
This issue got CVE-2019-12499 assigned. |
|
@netblue30 Can you please update the CVE status page? https://firejail.wordpress.com/download-2/cve-status/ |
|
LTS version also released, CVE status page updated - https://firejail.wordpress.com/download-2/cve-status/ |
Is firejail vulnerable to this? It seems to be a common implementation issue when using privileged namespaces.
runc, docker, k8s, lxc, and flatpak have all had patches issued for it.
See
The text was updated successfully, but these errors were encountered: