Received-SPF: pass (google.com: domain of oss-security-return-30100-linux.lists.archive=gmail.com@lists.openwall.com designates 193.110.157.125 as permitted sender) client-ip=193.110.157.125;
Mailing-List: contact oss-security-help@lists.openwall.com; run by ezmlm
Precedence: bulk
Reply-To: oss-security@lists.openwall.com
Message-ID: <66303BF2.2070502@gmail.com>
Date: Mon, 29 Apr 2024 19:31:46 -0500
From: Jacob Bachmeyer <jcb62281@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: Vegard Nossum <vegard.nossum@oracle.com>
CC: oss-security@lists.openwall.com, Hank Leininger <hlein@korelogic.com>
References: <20240427234834.c0219029-fe37-49ef-a563-4d24eea118c2@korelogic.com> <a0e871ca-468e-4239-89cd-61b35f935c2b@oracle.com>
In-Reply-To: <a0e871ca-468e-4239-89cd-61b35f935c2b@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [oss-security] Update on the distro-backdoor-scanner effort

Vegard Nossum wrote:
> [...]
> 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.

You are correct, but making this a little bit harder for an attacker is 
still an improvement.  Perhaps pkg-config variable values should be 
required to be in quotes if they contain spaces?

The bigger issue is accepting an *-uninstalled.pc in a system directory, 
which means that it actually *has* been installed.  That logic error 
allowed your backdoor to override the real libelf.pc without producing a 
file conflict that the package manager could detect.

> 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.

Agreed, but adding another file to the backdoor increases the chance of 
the attacker getting caught.

> 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.

Also correct, in fact, for a package that actually installs executables, 
a bit of extra code in an otherwise legitimate binary to detect when the 
grandparent is make(1) and drop a backdoor could very likely go 
unnoticed.  (This would be the rogue or compromised distribution 
packager scenario, where the binaries distributed do not match the sources.)


-- Jacob