On Thu, Sep 27, 2018 at 12:09 PM Matthias Gerstner <mgerstner(a)suse.de> wrote:
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
A demonstration works like this:
$ osc co home:mgerstner/surprise
$ cd home:mgerstner/surprise
$ quilt setup surprise.spec
# notice the surprise
We have posted about this on the oss-security mailing list  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 . nsjail RPMs are
available for Leap 15 and Tumbleweed from its devel project . It is
currently not found in Factory/Leap directly. Via the wrapper "squilt" ,
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
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 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
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 for my use. Unfortunately, the lack of usermode in Factory
keeps me from cleaning it up and submitting it to Factory.
真実はいつも一つ！/ Always, there's only one truth!
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org