[Bug preprocessor/66318] New: Error messages contain raw file name; malicious #line directives can do bad things

[Bug preprocessor/66318] New: Error messages contain raw file name; malicious #line directives can do bad things

[Keith.S.Thompson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318

            Bug ID: 66318
           Summary: Error messages contain raw file name; malicious #line
                    directives can do bad things
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Keith.S.Thompson at gmail dot com
  Target Milestone: ---

Error messages include the (presumed) name of the source file in which
the error was detected. The #line directive can set the presumed file name
to nearly any arbitrary string, possibly including control characters.

A directive like:

#line __LINE__ "beep\a.c"

can cause every printed error message to beep.  More malicious #line
directives can cause even more obnoxious behavior.

The sample file shown below, when fed through the preprocessor (either
directly or via the "gcc" command), will change the screen foreground
to green and the background to red if the command is run under xterm.

Depending on which terminal emulator is being used and how it's
configured, it might even be possible to trigger arbitrary code execution
just by compiling a source file.

System: Linux Mint 17.
gcc version 5.1.0, built from source with:
gcc-5.1.0/configure --prefix=/usr/local/apps/gcc-5.1.0 --disable-multilib

Test case (a 2 line source file named "red_green.c"):
#line __LINE__ "'\x1b]10;green\a\x1b]11;red\a'"
#error "Argh! My eyes!"

Output of "cpp red_green.c 2>&1 | cat -A":
'^[]10;green^G^[]11;red^G':1:2: error: #error "Argh! My eyes!"$
# 1 "red_green.c"$
# 1 "<built-in>"$
# 1 "<command-line>"$
# 1 "/usr/include/stdc-predef.h" 1 3 4$
# 1 "<command-line>" 2$
# 1 "red_green.c"$
# 1 "'^[]10;green^G^[]11;red^G'"$

See the "xtermcontrol" command for other possibilities. Even if
arbitrary command execution isn't possible, maximizing the current
window and rapidly alternating between red and green would be at least
seriously annoying, and at worst potentially dangerous to epileptics
(the latter is speculation on my part).

Suggested fix: Sanitize the displayed file name for error messages so
only printable characters are displayed (presumably affected by the
current locale).

[Bug preprocessor/66318] Error messages contain raw file name; malicious #line directives can do bad things

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
The set of valid characters in a #line directive includes escape sequences. 
Unconditionally filtering some of them out from the preprocessor output would
violate the requirements of the C standard and could cause it to break other
tools that depend on it when such sequences were present in the name of a
source file being preprocessed.

[Bug preprocessor/66318] Error messages contain raw file name; malicious #line directives can do bad things

[Keith.S.Thompson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318

--- Comment #2 from Keith Thompson <Keith.S.Thompson at gmail dot com> ---
Martin:

Good point.  I don't suggest altering the string to which the __FILE__
macro expands, merely sanitizing file names to be displayed in error
messages.

I see my original description wasn't 100% clear.

If you execute

    cpp red_green.c

or

    gcc -E red_green.c

the preprocessed output goes to stdout. If it includes ugly garbage,
well, that's what you asked for. The error message goes to stderr;
I'm suggesting sanitizing that.

If you execute

    gcc -c red_green.c

the preprocessed output is passed to the next phase of the compiler and
is not seen by the user.  I suggest that any diagnostic messages should
be sanitized. There's no requirement for a compiler's diagnostic output
to include any particular content.

I suppose some tools could parse that diagnostic output, and misbehave if
it includes something other than the literal file name.  But I suggest
that if either an actual file name or the value of __FILE__ contains
control characters, the risk of writing those control characters to the
user's terminal exceeds the cost of breaking such tools.

Perhaps an option could be added to print raw file names unconditionally
in diagnostic messages.  It should be turned off by default; otherwise
there's not much point in making a change from the current behavior.
The idea is to protect users who compile possibly malicious source files.

[Bug preprocessor/66318] Error messages contain raw file name; malicious #line directives can do bad things

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
You're right that the text of diagnostics is outside the scope of the C
standard.  But as you note, even diagnostics are relied on by tools to
manipulate the referenced files, and changing the file names in the compiler
output would break such tools.

For example, in Emacs Compilation Mode
(http://www.gnu.org/software/emacs/manual/html_node/emacs/Compilation-Mode.html)
if diagnostics in a file named "beep\a.c" were introduced by the string
"beep<BEL>.c:" instead, Emacs would no longer be able to open the file.

On the other hand, "beep\a.c" seems like a corner case not worth worrying
about, and since most multibyte encodings (with the exception of ISO 10646)
seem to take care to avoid using control characters for the second and
subsequent bytes, maybe the impact of such filtering wouldn't be as bad as
might at first seem, especially if an option were provided to disable the
filtering.  David Wheeler presents some good arguments in favor of restricting
the set of valid file name characters in his paper on Fixing Unix/Linux/POSIX
Filenames:
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html

[Bug preprocessor/66318] Error messages contain raw file name; malicious #line directives can do bad things

[miyuki at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318

Mikhail Maltsev <miyuki at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |miyuki at gcc dot gnu.org

--- Comment #4 from Mikhail Maltsev <miyuki at gcc dot gnu.org> ---
I think those tools will not like a newline character in the filename either.
And I doubt that there is a reliable way to parse output of GCC if newlines are
not escaped:

$ cat ./test.cc
void foo();

#line 1 "test1.cc:3:1 error: something wrong!\ntest2.cc"
void bar()
{
    foo("abc");
}

$ /opt/gcc-6.0.0/bin/g++ -c ./test.cc
test1.cc:3:1 error: something wrong!
test2.cc: In function 'void bar()':
test1.cc:3:1 error: something wrong!
test2.cc:3:14: error: too many arguments to function 'void foo()'
./test.cc:1:6: note: declared here
 void foo();

Anyway, GCC already suppresses color diagnostics when stderr is not a TTY
(implemented in should_colorize function). Probably the same logic could be
applied to hypothetical "should_escape".

[Bug preprocessor/66318] Error messages contain raw file name; malicious #line directives can do bad things

[Keith.S.Thompson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66318

--- Comment #5 from Keith Thompson <Keith.S.Thompson at gmail dot com> ---
Mikhail: Newlines in file names (either the actual file name or via a
#line directive) cause problems with __FILE__, though that particular
problem occurs only if there's an explicit reference to __FILE__.

See Bugzilla ticket #66317.