Re: GCC reporting piped input as a security feature

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