[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 27 Sep 2018 17:59:34 +0200
From: Matthias Gerstner <mgerstner@...e.de>
To: oss-security@...ts.openwall.com
Subject: Using quilt on untrusted RPM spec files
Hello list,
in the SUSE security team we have been recently looking into the security of
using quilt on untrusted RPM spec files and patches. The openSUSE distribution
is RPM based and uses the open build service (OBS) [1] for collaboration with
the community. Packagers, contributors and interested people can host their
packages in personal home projects and can become maintainers of development
packages that are targeted for inclusion in SUSE distributions.
Once packages are submitted into an actual SUSE distribution like openSUSE
Tumbleweed human and automated reviews of the package contents will take
place for quality assurance and security. One of the typical workflows for
many people concerned with managing the openSUSE distribution is to checkout
a (possible not yet reviewed) OBS package and run `quilt setup` on the RPM
spec file for extracting the package sources and applying any specified
patches. When building an RPM package on server or client side then this
happens in an isolated environment (e.g. a chroot [2] or in a virtual
machine). The `quilt setup` invocation, however, typically happens
interactively on client machines without special security measures.
It turns out that running `quilt setup` on untrusted sources is not a good
idea:
- The statements in the `%prep` section of the RPM spec file are
plainly 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 [3].
Now we would be interested in discussing this topic with the community. Do
other distributions have similar workflows and therefore similar attack
surface as we do? What would be viable countermeasures?
Our current assessment is that most people that use quilt this way are
probably not aware of the potential dangers involved. Furthermore we think
that in order to fix this a simple to use default protection mechanism
would be required. While running `quilt setup` e.g. in a docker
container would provide fair security against such scenarios it would
introduce quite some dependencies and complexities that make it not well
suited for a default approach.
We are currently testing isolation of quilt with nsjail [4]. A first result,
the wrapper "squilt" [5], can confine quilt's execution to a package
directory, thereby reducing the attack surface significantly.
[1]: https://openbuildservice.org
[2]: https://build.opensuse.org/package/show/openSUSE:Tools/build
[3]: https://build.opensuse.org/package/show/home:mgerstner/surprise
[4]: http://nsjail.com
[5]: https://github.com/jsegitz/squilt
--
Matthias Gerstner <matthias.gerstner@...e.de>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
