From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BZisC-0001OT-Jn for qemu-devel@nongnu.org; Mon, 14 Jun 2004 00:15:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BZisA-0001Nc-UD for qemu-devel@nongnu.org; Mon, 14 Jun 2004 00:15:04 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BZisA-0001NL-RH for qemu-devel@nongnu.org; Mon, 14 Jun 2004 00:15:02 -0400 Received: from [206.72.67.39] (helo=claudius.sentinelchicken.org) by monty-python.gnu.org with smtp (Exim 4.34) id 1BZiqr-0001Pl-Ej for qemu-devel@nongnu.org; Mon, 14 Jun 2004 00:13:41 -0400 Date: Sun, 13 Jun 2004 21:13:37 -0700 From: Tim Message-ID: <20040614041337.GA2193@sentinelchicken.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline Subject: [Qemu-devel] String format vulnerability discovered in monitor.c Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This evening, I grepped the codebase for tell-tale signs of string format vulnerabilities. I found only one instance of the printf family of functions which appears to have the problem. Which if you ask me, is pretty good. There may be others I missed, but I figured I would submit this patch before I look further. The problem exists at the (qemu) prompt when a user uses the arrow keys to retrieve commands typed previously. The code, annotated: --SNIP-- static void term_print_cmdline (const char *cmdline) { term_show_prompt(); term_printf(cmdline); /* <---- problem here */ term_flush(); } --SNIP-- The term_printf() function eventually calls vprintf(). This wrapper function has a similar parameter syntax, which means the first parameter passed to it is treated as the formatting string. The problem can be demostrated trivially at the (qemu) prompt: --SNIP-- QEMU 0.5.5 monitor - type 'help' for more information (qemu) foo %x unknown command: 'foo' (qemu) (qemu) foo 80b860c --SNIP-- The last line you see is where I hit up arrow. Instead of printing the proper 'foo %x', it printed the hexadecimal representation of the next chunk of memory (what it expect to be in the vprintf() parameter list, but isn't). This bug can be exploited to execute arbitrary code: http://www.hackerscenter.com/articles/Article.asp?id=52 This of course has little impact on a default install, but I wouldn't be surprised if users (or if later on, *ix distributions) granted additional privileges to the qemu binary via sudo or suid/sgid bits, in order to have direct access to hardware devices. A bug like this would then allow privilege escalation locally. Once again, not a big deal, but something to keep an eye out for. Trivial patch is attached. cheers, tim --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="monitor.patch" --- monitor.c 2004-06-13 21:08:13.000000000 -0700 +++ monitor-new.c 2004-06-13 21:07:43.000000000 -0700 @@ -1437,7 +1437,7 @@ static void term_print_cmdline (const char *cmdline) { term_show_prompt(); - term_printf(cmdline); + term_printf("%s", cmdline); term_flush(); } --M9NhX3UHpAaciwkO--