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. ]]]
> 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.
Are you suggesting fixing GCC to put the specified file into those
linenumbers, or are you suggesting we keep this behavior
to help with analysis?
I am suggesting that we keep this behavior (and document it as an
explicit security feature) to help with detection of any future similar
cracks, and add provisions to the GNU Coding Standards to avoid false
positives by requiring generated sources to appear in the filesystem
instead of being piped to the compiler.
In principle it could be posible to output something different to
describe this stramge situation explicitly. For instance, output "via
stdin" as a comment, or output `stdin/../filename' as the file name.
(Programs that optimize the file name by deleting XXX/.../ are likely
not to check whether XXX is a real directory.)
With the small difference that I believe the special marker should be
'<stdin>' (with the angle brackets, as it is now), this could be another
good idea. Example output: "[working directory]/<stdin>///[specified
filename]" or "[specified filename]///<>/[working directory]/<stdin>".
GDB could be modified to recognize either form and read the specified
file (presumably some form of augmented C) but report that the sources
were transformed prior to compilation. The use of triple-slash ensures
that these combined strings cannot be confused with valid POSIX
filenames, although I suspect that uses of these strings would have to
be a GNU extension to the debugging info format. (If GNU-extended
debugging information is inhibited, I think it is more important to
declare that the input came from a pipe than to carry the specified
filename.) This might actually be a good idea in general if a directive
specifies a filename with the same suffix but not the file being read.
As another layer against similar attacks, distribution packaging tools
could grep the debug symbols for '<stdin>' and raise alarms if matches
are found. Forbidding piping source to the compiler in the GNU Coding
Standards would eliminate false positives.
-- Jacob
