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] New: Error messages contain raw file name; malicious #line directives can do bad things Date: Wed, 27 May 2015 23:01:00 -0000 [thread overview] Message-ID: <bug-66318-4@http.gcc.gnu.org/bugzilla/> (raw) 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).
next reply other threads:[~2015-05-27 23:01 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-27 23:01 Keith.S.Thompson at gmail dot com [this message] 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 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@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).