From owner-freebsd-bugs@FreeBSD.ORG Wed Jan 1 19:40:00 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org 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 8E11DAA1 for ; Wed, 1 Jan 2014 19:40: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 696E91EE5 for ; Wed, 1 Jan 2014 19:40: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 s01Je0Ub097773 for ; Wed, 1 Jan 2014 19:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s01Je0KY097772; Wed, 1 Jan 2014 19:40:00 GMT (envelope-from gnats) Resent-Date: Wed, 1 Jan 2014 19:40:00 GMT Resent-Message-Id: <201401011940.s01Je0KY097772@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, Ben Reser 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 3E0B1801 for ; Wed, 1 Jan 2014 19:32:30 +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 2A0BC1EA6 for ; Wed, 1 Jan 2014 19:32:30 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id s01JWT0O088043 for ; Wed, 1 Jan 2014 19:32:29 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id s01JWTSj088033; Wed, 1 Jan 2014 19:32:29 GMT (envelope-from nobody) Message-Id: <201401011932.s01JWTSj088033@oldred.freebsd.org> Date: Wed, 1 Jan 2014 19:32:29 GMT From: Ben Reser To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: bin/185393: find -lname buffer read overflow bug 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: Wed, 01 Jan 2014 19:40:00 -0000 >Number: 185393 >Category: bin >Synopsis: find -lname buffer read overflow bug >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: Wed Jan 01 19:40:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Ben Reser >Release: 9.1 >Organization: >Environment: FreeBSD freebsd9.1 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: The implementation of -lname and -ilname improperly use readlink() by not setting a null character before using the string. readlink() is documented as not doing this for you and returns the length of the link string, requiring the caller to set the null character. In particular this is implemented in the usr.bin/find/function.c in the f_name() function. The function uses an automatic buffer which gets reused through multiple calls, resulting in link names that are shorter than the preceding values stored in the buffer to fail to match properly. This could cause the program to read past the end of the buffer. In practice this doesn't seem to happen because the buffer seems to always end up in zeroed memory the first time it is used (though there's no requirement for it to do so). This would result in a crash of the find command. You can force reading past the end of the buffer by creating a link that points at a path of PATH_MAX length on the path being searched. Presumably it's not possible to create a link that points at a path longer than that but if possible that would also allow reading past the end of the buffer. I haven't bothered to exercise this. It might be possible to view this as a minor security issue if someone is using find to try and find link with -lname for auditing purposes, since they might not reliably find what they are looking for. The read past the end of the buffer doesn't seem particularly useful. For one it'd only ever be a read, which isn't particularly useful and for another find doesn't run with escalated privileges. So all in all I think it'd be a stretch to call this anything other than an ordinary bug. This bug was introduced in r176497 (committed 5 years 10 months ago), so any releases of FreeBSD that contain this change would contain the same issue. I actually happened to find the issue in OS X's fork of your find command. But successfully duplicated the issue in a VM of 9.1 that I had laying around. >How-To-Repeat: The following shell script should demonstrate the issue: #!/usr/bin/env bash set -e # Demonstration of -lname bug with FreeBSD and OS X find. # find stops output matching links as soon as it passes a link # that points at a path that is longer than the path we are trying # to match. Note that file system ordering of results may change # when this happens. OS X seems to return readdir results in # alphabetical sorted order (HFS+) and FreeBSD (UFS) seems to return # them in creation order (though there does seem to be some variation # on this). So the below example has both the creation # order and the alphabetical sort order such that it should reliably # reproduce the issue. However, I've not tested this with other # supported file systems so they may have different behavior, possibly # even non-deterministic behavior that makes this harder to demonstrate. # Expected behavior will have no output and a zero exit value. test_dir=`mktemp -d find-test.XXXXXXX` cd "$test_dir" > /dev/null ln -s /usr/bin/gcc a ln -s /usr/bin/touch b ln -s /usr/bin/gcc c ln -s /usr/bin/gcc d ln -s /usr/bin/gcc e echo './a' > expected echo './c' >> expected echo './d' >> expected echo './e' >> expected "${FIND:-find}" . -lname /usr/bin/gcc | sort > received set +e diff -u expected received rv=$? set -e cd - > /dev/null rm -rf "$test_dir" exit $rv >Fix: Set a null character at fn[len] (where len is the return of the readlink() call) as implemented in the attached patch. Patch attached with submission follows: Index: usr.bin/find/function.c =================================================================== --- usr.bin/find/function.c (revision 260159) +++ usr.bin/find/function.c (working copy) @@ -1124,9 +1124,11 @@ f_name(PLAN *plan, FTSENT *entry) const char *name; if (plan->flags & F_LINK) { + int len = readlink(entry->fts_path, fn, sizeof(fn)); + if (len == -1) + return 0; + fn[len] = '\0'; name = fn; - if (readlink(entry->fts_path, fn, sizeof(fn)) == -1) - return 0; } else name = entry->fts_name; return !fnmatch(plan->c_data, name, >Release-Note: >Audit-Trail: >Unformatted: