oss-sec mailing list archives
Re: Update on the distro-backdoor-scanner effort
From: Gabriel Ravier <gabravier () gmail com>
Date: Mon, 29 Apr 2024 20:57:10 +0100
On 4/29/24 10:46, Vegard Nossum wrote:
On 28/04/2024 08:34, Hank Leininger wrote:On 2024-04-27, Jacob Bachmeyer wrote:- Check for irregular contents in .pc files, inspired by Vegard Nossum's oss-security postMuch easier: look for pkg-config descriptions containing text other than a variable definition. The pkg-config tool itself should probably enforce "cleanliness" on this matter and refuse to process files containing other text. (It also should complain about and reject an *-uninstalled.pc file found in the system directories, which was another logic error exploited in that sample backdoor.)Really, doing this seems a more robust approach anyway, because allowing only known-good > rejecting known-bad. I was mostly driven by "hang on, how many of the things Nossum's example does are actually used by real files?" and the answer from my initial sample size was zero, so it'd be trivial to extend that check to every .pc file shipped by every current distro's packages. I think Sam looked into existing pkg-config verifiers and found they do not complain about things we thought they should complain about (this could just mean we misunderstand their purpose). A strict lint-checker for such files would be better than just checking for specific suspicious patterns. But, I don't yet know how strict a format we could insist on (would it turn out 10% of files in fact break what we initially think are reasonable rules?). Even still, I think you could embed badness in legit variables, although I haven't dug in enough to know that for sure.Hi, Masquerading a shell command as a pkg-config variable definition is trivial (but probably still detectable) since you can just do: foobar=/usr echo hi which AFAIK is a valid pkg-config variable definition but also a valid shell command. Also remember that in my particular example I reused the same file but it would also be trivial to use a different file in the $(...) expansion so that the payload actually lives somewhere else. The payload doesn't even have to be a shell script, it could also be a small ELF binary or something where you wouldn't necessarily be able to tell at a glance that it does something malicious. So probably the real thing to look for would be $(...) in pkg-config files -- Hank, you mentioned in the GitHub issue that you did fine this in one file; out of curiosity, could you share it?
I am not Hank, but having done a search myself, the one example I found appears to be a typo in a GTK pkgconfig package, which I found in my /usr/lib64/pkgconfig folder:
$ grep -r '\$(' /usr/lib64/pkgconfig/usr/lib64/pkgconfig/gtk-sharp-beans-2.0.pc:Cflags: -I:${gapidir}/gtk-api.xml -I:$(gapidir)/gtkbeans-api.xml
I tried this on my system and didn't find anything: $ grep -R '\$(' /usr/share/pkgconfig /usr/lib/x86_64-linux-gnu/pkgconfig It's also worth asking if there are other ways to encode that $() that bypasses the very simple '\$(' pattern -- e.g. something like "$\(" or maybe an expansion of a variable that itself contains the $ character: $ cat test.pc foo=\$ Name: test Version: 0 Description: Cflags: ${foo}(echo hi) $ PKG_CONFIG_PATH=. pkg-config --cflags test $(echo hi) There are also other ways to achieve the same effect. I should also add that I found out-of-bounds memory accesses in both the original pkg-config and pkgconf (used on Debian and RedHat derivatives, respectively, AFAIK) when using long variable names -- it doesn't look exploitable to me but I've submitted some patches for both packages just in case. Thanks, Vegard
Current thread:
- Update on the distro-backdoor-scanner effort Hank Leininger (Apr 26)
- Re: Update on the distro-backdoor-scanner effort Simon McVittie (Apr 26)
- Re: Update on the distro-backdoor-scanner effort Sam James (Apr 26)
- Re: Update on the distro-backdoor-scanner effort Jacob Bachmeyer (Apr 27)
- Re: Update on the distro-backdoor-scanner effort Morten Linderud (Apr 27)
- <Possible follow-ups>
- Re: Update on the distro-backdoor-scanner effort Hank Leininger (Apr 28)
- Re: Update on the distro-backdoor-scanner effort Jacob Bachmeyer (Apr 29)
- Re: Update on the distro-backdoor-scanner effort Vegard Nossum (Apr 29)
- Re: Update on the distro-backdoor-scanner effort Gabriel Ravier (Apr 29)
- Re: Update on the distro-backdoor-scanner effort Jacob Bachmeyer (Apr 30)
- Re: Update on the distro-backdoor-scanner effort Hank Leininger (Apr 28)
- Re: Update on the distro-backdoor-scanner effort Simon McVittie (Apr 26)