automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GCC reporting piped input as a security feature (was: GNU Coding Sta


From: Jacob Bachmeyer
Subject: Re: GCC reporting piped input as a security feature (was: GNU Coding Standards, automake, and the recent xz-utils backdoor)
Date: Fri, 05 Apr 2024 23:49:02 -0500
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

Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

[...]

When considering any such change, we still should consider the question:
will this actually prevent cracks, or will it rather give crackers
an additional way to check that their activities can't be detected.

While it does not /prevent/ cracks, there is something we can ensure that we *keep* doing: GCC, when reading from a pipe, records the input file as "<stdin>" in debug info *even* if a "#" directive to set the filename has been included. This was noticed by Adrien Nader (who posted it to oss-security; <URL:https://www.openwall.com/lists/oss-security/2024/04/03/2> and <URL:https://marc.info/?l=oss-security&m=171214932201156&w=2>; those are the same post at different public archives) and should provide a "smoking gun" test to detect this type of backdoor dropping technique in the future. This GCC behavior should be documented as a security feature, because most program sources are not read from pipes.

The xz backdoor dropper took great pains to minimize its use of the filesystem; only the binary blob ever touches the disk, and that presumably because there is no other way to feed it into the linker. If debug info is regularly checked for symbols obtained from "<stdin>" and the presence of such symbols reliably indicates funny business, then we force crackers to risk leaving more direct traces in the filesystem, instead of being able to patch the code "in memory" and feed an ephemeral stream to the compiler. The "Jia Tan" crackers seem to have put a lot of work into minimizing the "footprint" of their dropper, so we can assume that this must have been important to them.

To avoid false positives if this test is used, we might want to add a rule to the GNU Coding Standards (probably in the "Makefile Conventions" section) that code generated with other utilities MUST always be materialized in the filesystem and MUST NOT be piped into the compiler.


-- Jacob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]