Definitely this attack leveraged places where eyes don't look: distributed tar.gz and blobs.
I put the PoC to flag those two in github[1] Example output: $ ./rpmseclint tests/rpmseclint-test.spec -----Diff----- ~ test.txt + additional.txt + blob.txt.gz -----Blobs---- application/gzip blob.txt.gzNow, against the PoC itself, the diff part can be totally avoided by using generated tars. Not all projects are in github, but those that do... The other way is by using source-git?
Regarding the blobs part, ... an attack could still manage to fool `file` with a crafted binary. However, that would still increase the attack complexity.
[1] https://github.com/carlosrodfern/rpmseclint On 3/31/24 19:02, Carlos Rodriguez-Fernandez wrote:
Regarding downstream defense, prohibiting blobs or differences between tars and git repos may be overkill or difficult at this moment, but a tool to assist maintainers in the identification and analysis of these situations where attacks may be hidden into can be very helpful.Regarding the latter, where you want to find diff between tars and git repo content, someone may say "let's just use the github API to pull the tar", but not all projects use github, or have that feature. So, I still think there is value in these tools.I started working on a PoC personal minitool named rpmseclint that utilizes the "VCS" tag to pull the git repo, and the tar, and compares and flags things for further review. Right now, I'm just focused on blobs, and files/directories differences. The intention is to use it at least right before a rebase. I'm just planning to personally use it to get a "feel" for it (and help myself), but open to anyone wanting to explore this idea.In general, I think the idea of codifying security practices expertise in tools to assist maintainers with detection and analysis has great value; even if it is not enforcing anything at the moment. The maintainer could then explicitly add found problems to an "ignore" list after the analysis, and explain the "why" in the git commit body message, and perpetuate the reasoning in the git history of the downstream project. There is already a lot of best practices codified in the gating pipelines, and I have found them extremely useful myself.Regards, Carlos R.F. On 3/30/24 02:37, Richard W.M. Jones wrote:I'm not pretending these will solve everything, but they should make attacks a little harder in future. (1) We should routinely delete autoconf-generated cruft from upstream projects and regenerate it in %prep. It is easier to study the real source rather than dig through the convoluted, generated shell script in an upstream './configure' looking for back doors. For most projects, just running "autoreconf -fiv" is enough. Yes, there are some projects that depend on a specific or old version of autoconf. We should fix those. But that doesn't need to delay us from using autoreconf on many projects today. In the xz case this wouldn't have been enough, it turns out we would also have to delete m4/build-to-host.m4, which then autoreconf regenerates. I don't fully understand why that is. (2) We should discourage gnulib as much as possible. In libvirt we took the decision a few years ago to remove gnulib. It's extremely convoluted and almost no one understands how it really works. It's written in obscure m4 macros and shell script. It's also not necessary for Linux since gnulib is mainly about porting to non-Linux platforms. There are better ways to do this. In the xz case it was a gnulib-derived script which was modified to do the initial injection (original: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD). (3) We should have a "security path", like "critical path". sshd is linked to a lot of libraries: /lib64/libaudit.so.1 audit-libs /lib64/libc.so.6 glibc /lib64/libcap-ng.so.0 libcap-ng /lib64/libcap.so.2 libcap /lib64/libcom_err.so.2 libcom_err /lib64/libcrypt.so.2 libxcrypt /lib64/libcrypto.so.3 openssl-libs /lib64/libeconf.so.0 libeconf /lib64/libgcc_s.so.1 libgcc /lib64/libgssapi_krb5.so.2 krb5-libs /lib64/libk5crypto.so.3 krb5-libs /lib64/libkeyutils.so.1 keyutils-libs /lib64/libkrb5.so.3 krb5-libs /lib64/libkrb5support.so.0 krb5-libs /lib64/liblz4.so.1 lz4-libs /lib64/liblzma.so.5 xz-libs /lib64/libm.so.6 glibc /lib64/libpam.so.0 pam-libs /lib64/libpcre2-8.so.0 pcre2 /lib64/libresolv.so.2 glibc /lib64/libselinux.so.1 libselinux /lib64/libsystemd.so.0 systemd-libs /lib64/libz.so.1 zlib / zlib-ng /lib64/libzstd.so.1 zstd Should we have a higher level of attention to these packages? We already have "critical path", but that's a broad category now. These seem like they are "security path" packages, an intentionally small subset associated with very secure services which are enabled by default. These are just my thoughts on a Saturday morning. Feedback welcome of course. Rich.
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
