This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]