[Question] procps runtime dependency

[mikeantonelli]

While performing a scan of ruby:2.6.3-alpine3.10, we are showing a vulnerability result tied to procps (CVE-2018-1121).

procps-ng, procps is vulnerable to a process hiding through race condition. Since the kernel\'s proc_pid_readdir() returns PID entries in ascending numeric order, a process occupying a high PID can use inotify events to determine when the process list is being scanned, and fork/exec to obtain a lower PID, thus avoiding enumeration. An unprivileged attacker can hide a process from procps-ng\'s utilities by exploiting a race condition in reading /proc/PID entries. This vulnerability affects procps and procps-ng up to version 3.3.15, newer versions might be affected also.

This package is listed as a build dependency and although build dependencies are removed, a run-time dependency exists on procps, and we are unable to remove just procps because it is tied to the .ruby-rundeps virtual group.

After doing some digging, it looks like ruby-build doesn't reference this package as a recommended system requirement, and looking back at #30, the commentary doesn't mention this package but #33 merged it.

This issue has largely been declared wont-fix (ref, ref), and we're hoping to remove the vulnerability from our scan report - can this package be removed?

Thanks!

[wglambert]

See docker-library/postgres#286 (comment) docker-library/openjdk#161, docker-library/openjdk#112, docker-library/postgres#286, docker-library/drupal#84, docker-library/official-images#2740, #117, #94, docker-library/python#152, docker-library/php#242, docker-library/buildpack-deps#46, docker-library/openjdk#185.
And https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-so-many-cves

A CVE doesn't imply having an actual vulnerability, and often is even a false positive (given how most distributions handle versioning/security updates in stable releases). If there are actionable items we can resolve, we're happy to do so (and do so actively). We update all Debian based images to include any updates in apt packages at least monthly (we regenerate the base images and then rebuild all dependent images).

---

This vulnerability is irrelevant in a Docker environment and the CVE is marked CLOSED WONTFIX. Admittedly I don't know why procps is installed in the image, but its installed size in Alpine is 432kB

a process occupying a high PID can use inotify events to determine when the process list is being scanned, and fork/exec to obtain a lower PID, thus avoiding enumeration.

The containers don't have inotify and pid 1 can't "obtain a lower pid". Which is the only process running in the container by default unless for instance you attach a shell to the container.

Also there really shouldn't be anything that could even attempt to exploit this in your custom container (since all the packages installed in an official-image are verified) unless your Dockerfile consists of compiling and running software from random Github repos (which if you're going to do that should have their own individual containers so this is all the more irrelevant)

[yosifkit]

1. It seems like procps was added because of Update Ruby versions and fix installation issues with trying to remove procps and thus init #15 and thus carried forward to slim and alpine variants; we could possibly remove it but that would also likely break a non-trivial number of people that rely on it being installed