On Thu, Sep 27, 2018 at 12:09 PM Matthias Gerstner <mgerstner@suse.de> wrote:
Hello packagers,
the SUSE security team wants to draw your attention to a potential security threat involving the use of `quilt setup ...` on untrusted RPM spec files.
For many of us calling `quilt setup $PACKAGE.spec` is probably a frequent part of our daily workflows. In contrast to building a package on the server in an isolated VM or on the client in a chroot via `osc build`, the `quilt setup` runs without any isolation on the host in the calling user's context. As it turns out this operation easily allows to execute code in the following ways:
- The statements in the `%prep` section of the RPM spec file are unconditionally executed in the context of the calling user. - Arbitrary flags can be passed to `patch` via `%define _default_patch_flags ...` in the spec file. By embedding semicolons into the flags also arbitrary commands can be injected this way. - By combining the available vectors, difficult to spot malicious code can be hidden in RPM spec files. For example patch can be caused to follow symlinks, thereby "patching" files in a user's home directory as demonstrated in [1].
A demonstration works like this:
```sh $ osc co home:mgerstner/surprise $ cd home:mgerstner/surprise $ quilt setup surprise.spec # notice the surprise $ bash ```
We have posted about this on the oss-security mailing list [2] to start a discussion about possible countermeasures. A first aid could be to run the `quilt setup` inside a docker container or in a similar isolated environment. We are currently testing isolation of quilt with nsjail [3]. nsjail RPMs are available for Leap 15 and Tumbleweed from its devel project [4]. It is currently not found in Factory/Leap directly. Via the wrapper "squilt" [5], nsjail is utilized to confine quilt to read only the files it needs and is only able to write in the current directory. According to our initial testing it can be used as a drop in replacement and should reduce the attack surface significantly.
Our foremost intent is to make you aware of this so you don't run `quilt setup` unsuspectingly on untrusted packages that did not go through review. Furthermore to make you aware of how malicious code that targets this can be embedded in spec files and patches. This should be taken into account when reviewing package submissions.
If you have any questions or suggestions then please let's start a discussion.
So for my Fedora and openSUSE packages, I always use Mock[0] for my workflow. Classically, Mock used chroot(), but nowadays it uses systemd-nspawn for secure container environments. Mock provides a feature in which it can run just run the prep stage and then I can install packages into the environment and work from within there. My workflow is often something like the following: $ rpmbuild -bs <package>.spec $ mock -r opensuse-tumbleweed clean $ mock -r opensuse-tumbleweed --short-circuit=prep <package>.src.rpm $ mock -r opensuse-tumbleweed --install nano emacs-nox $ mock -r opensuse-tumbleweed --shell [ ... do stuff in the nspawn container ... ] $ mock -r opensuse-tumbleweed --copyout /builddir/build/SOURCES/* . $ mock -r opensuse-tumbleweed --copyout /builddir/build/SPECS/* . This doesn't appear to be available with "osc", so I ported mock to openSUSE[1] for my use. Unfortunately, the lack of usermode[2] in Factory keeps me from cleaning it up and submitting it to Factory. [0]: https://github.com/rpm-software-management/mock [1]: https://build.opensuse.org/package/show/home:Pharaoh_Atem:SUSE_mock/mock [2]: https://build.opensuse.org/package/show/security:SELinux/usermode -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org