[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bcf98949-17b2-4260-9471-5a312e82aa0e@gmail.com>
Date: Mon, 29 Apr 2024 20:57:10 +0100
From: Gabriel Ravier <gabravier@...il.com>
To: oss-security@...ts.openwall.com, Vegard Nossum <vegard.nossum@...cle.com>
Cc: Hank Leininger <hlein@...elogic.com>, Jacob Bachmeyer <jcb62281@...il.com>
Subject: Re: Update on the distro-backdoor-scanner effort
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 post
>>
>>> Much 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
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.
