Hello, Am Donnerstag, 27. September 2018, 18:09:12 CEST schrieb Matthias Gerstner:
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. [...] - 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].
I'd like to add that code can also be executed via %define, for example %define apache_module_path %(/usr/sbin/apxs2 -q LIBEXECDIR) This %define will also run as part of quilt setup.
A demonstration works like this:
```sh $ osc co home:mgerstner/surprise $ cd home:mgerstner/surprise $ quilt setup surprise.spec # notice the surprise $ bash ```
My latest test doesn't show any surprise when starting bash. Maybe the reason is that I just created an AppArmor profile for quilt? ;-) I'll paste it below - if you want to use it, save it as /etc/apparmor.d/usr.bin.quilt Then adjust @{packages_dir} and run rcapparmor reload Notes: - you'll HAVE TO adjust @{packages_dir} to your needs - it has to be set to the directory where you run osc co - write access is restricted to - *.diff, *.diff~, *.patch, *.patch~ - the directory with the extracted tarball - tempfiles in /tmp/ and /var/tmp/ Note that quilt could modify files of another package in @{packages_dir} matching the above patterns, so there's no perfect protection. - I only tested the quilt commands I typically use - setup, push, pop, edit, refresh - all tests were done using the apparmor package (which includes the %define quoted above - that's also the reason why the profile allows reading a file in /usr/share/apache2/) - other packages might need other / more permissions - you can update the profile with aa-logprof Questions and feedback welcome - maybe we can even come up with a profile that is good enough for everybody, and ship that as part of the quilt rpm ;-) That all said - here's my AppArmor profile for quilt: # --------------------------------------------------------------------- # packages directory # expected layout is @{packages_dir}/$project/$package/ # so set it to the directory where you run osc co @{packages_dir} = /home/cb/packages/ #include <tunables/global> /usr/bin/quilt { #include <abstractions/base> #include <abstractions/bash> #include <abstractions/consoles> #include <abstractions/perl> /bin/bash mrix, /etc/host.conf r, /etc/magic r, /etc/resolv.conf r, /etc/rpm/ r, /etc/rpm/* r, /etc/vimrc r, /proc/filesystems r, /run/nscd/db* r, /usr/bin/* mrix, # [1] /usr/lib*/python*/**.so mr, /usr/lib*/ruby/**.so mr, /usr/lib/sysimage/rpm/Packages rk, /usr/share/apache2/build/config_vars.mk r, /usr/share/misc/magic.mgc r, /usr/share/quilt/ r, /usr/share/quilt/** r, /usr/share/quilt/scripts/* mrix, /usr/share/vim/** r, /var/lib/nscd/group r, /var/lib/nscd/passwd r, owner /home/*/.exrc r, owner /home/*/.quiltrc r, owner /home/*/.vim/** r, owner /home/*/.viminfo rw, owner /home/*/.viminfx.tmp rw, owner /home/*/.vimrc r, owner /proc/*/fd/ r, owner /proc/*/maps r, owner /tmp/* rw, owner /var/tmp/quilt??????/ rw, owner /var/tmp/quilt??????/* rw, owner /var/tmp/quilt??????/bin/ rw, owner /var/tmp/quilt??????/bin/* w, owner /var/tmp/quilt??????/build/ rw, owner /var/tmp/quilt??????/build/** rw, owner /var/tmp/rpm-tmp.?????? rw, owner @{packages_dir}/** r, owner @{packages_dir}/*/*/*.diff rw, owner @{packages_dir}/*/*/*.diff~ rw, owner @{packages_dir}/*/*/*.patch rw, owner @{packages_dir}/*/*/*.patch~ rw, owner @{packages_dir}/*/*/*/ rw, owner @{packages_dir}/*/*/*/** rwl, } # --------------------------------------------------------------------- Regards, Christian Boltz [1] in case you wonder why I allow /usr/bin/* mrix - the first reason is that the profile is restrictive enough to do that, and the second reason is that there's a very big (and never-ending) list of binaries that need to be executed. I stopped at # /usr/bin/apr-1-config mrix, # /usr/bin/apu-1-config mrix, # /usr/bin/apxs mrix, # /usr/bin/cat mrix, # /usr/bin/chmod mrix, # /usr/bin/cmp mrix, # /usr/bin/column mrix, # /usr/bin/cp mrix, # /usr/bin/date mrix, # /usr/bin/diff mrix, # /usr/bin/file mrix, # /usr/bin/find mrix, # /usr/bin/gawk mrix, # /usr/bin/getopt mrix, # /usr/bin/grep mrix, # /usr/bin/gzip mrix, # /usr/bin/head mrix, # /usr/bin/ln mrix, # /usr/bin/md5sum mrix, # /usr/bin/mkdir mrix, # /usr/bin/mktemp mrix, # /usr/bin/mv mrix, # /usr/bin/patch mrix, # /usr/bin/python3.[0-9] mrix, # /usr/bin/quilt r, # /usr/bin/rm mrix, # /usr/bin/rpm mrix, # /usr/bin/rpmbuild mrix, # /usr/bin/ruby mrix, # /usr/bin/sed mrix, # /usr/bin/sort mrix, # /usr/bin/stat mrix, # /usr/bin/tail mrix, # /usr/bin/tar mrix, # /usr/bin/touch mrix, # /usr/bin/tr mrix, # /usr/bin/vim-nox11 mrix, # /usr/bin/xargs mrix, --
good luck, Usually "good luck" is going together with "as I told you before" :) [> Greg KH and Johannes Nohl in opensuse-project]
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org