public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "Keith.S.Thompson at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/66318] Error messages contain raw file name; malicious #line directives can do bad things Date: Thu, 28 May 2015 00:06:00 -0000 [thread overview] Message-ID: <bug-66318-4-X1qoTwhhKO@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-66318-4@http.gcc.gnu.org/bugzilla/> 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.
next prev parent reply other threads:[~2015-05-28 0:06 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-27 23:01 [Bug preprocessor/66318] New: " Keith.S.Thompson at gmail dot com 2015-05-27 23:42 ` [Bug preprocessor/66318] " msebor at gcc dot gnu.org 2015-05-28 0:06 ` Keith.S.Thompson at gmail dot com [this message] 2015-05-28 3:20 ` msebor at gcc dot gnu.org 2015-05-28 23:38 ` miyuki at gcc dot gnu.org 2015-05-29 19:47 ` Keith.S.Thompson at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-66318-4-X1qoTwhhKO@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).