From owner-freebsd-bugs@FreeBSD.ORG Thu Jan 30 17:30:00 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BDA35B4 for ; Thu, 30 Jan 2014 17:30:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76C9011F2 for ; Thu, 30 Jan 2014 17:30:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0UHU0ZH083359 for ; Thu, 30 Jan 2014 17:30:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0UHU0ux083358; Thu, 30 Jan 2014 17:30:00 GMT (envelope-from gnats) Resent-Date: Thu, 30 Jan 2014 17:30:00 GMT Resent-Message-Id: <201401301730.s0UHU0ux083358@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Rici Lake Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8139585 for ; Thu, 30 Jan 2014 17:28:45 +0000 (UTC) Received: from oldred.freebsd.org (oldred.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89BBC11D9 for ; Thu, 30 Jan 2014 17:28:45 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id s0UHSjsu023316 for ; Thu, 30 Jan 2014 17:28:45 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id s0UHSjKK023308; Thu, 30 Jan 2014 17:28:45 GMT (envelope-from nobody) Message-Id: <201401301728.s0UHSjKK023308@oldred.freebsd.org> Date: Thu, 30 Jan 2014 17:28:45 GMT From: Rici Lake To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: misc/186282: Buffer overrun in col utility X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 17:30:00 -0000 >Number: 186282 >Category: misc >Synopsis: Buffer overrun in col utility >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 30 17:30:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Rici Lake >Release: n/a (but the bug is present since forever) >Organization: >Environment: >Description: At line 78 of col.c (http://svnweb.freebsd.org/base/head/usr.bin/col/col.c), the c_column member of the CHAR struct is declared as short: short c_column; /* column character is in */ This value is set (for each character) at line 299 from cur_col c->c_column = cur_col; But cur_col is an int. Consequently, if the input has a line of more than 32768 characters, the assignment to c->c_column will produce an integer overflow, producing two errors: first, the value of c->column may become negative, which may cause random memory to be overwritten; second, it may limit the line's output size to 32768 characters, overlaying portions of the line over other portions. The more serious issue, the buffer overrun, will be triggered in the case that l->l_needs_sort is set to true at line 306, which will happen if input characters are out of sequence as a result of backspaces in the input (more than one consecutive backspace is required to trigger this condition). In that case, control flow will eventually reach line 423: count[c->c_column]++; which may use a negative integer from c->c_column to index the malloc'd region count. While this is not likely to be exploitable, since the memory overwrite is an increment rather than a set, it could certainly cause unpredictable behaviour. In addition, the integer overflow will cause other problems for input containing long lines. >How-To-Repeat: Simple demonstration: valgrind col < <(printf 'xx\b\b'; printf z%.0s {1..131072}) | wc -c >Fix: A simple fix would be to change the declaration of c_column to int rather than short. However, this will only defer the integer overflow; it will still occur on lines of length greater than 2^31. In addition to the above, all increments to cur_col in the loop starting at line 174 should have integer overflow checks. >Release-Note: >Audit-Trail: >Unformatted: