From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <glibc-bugs-return-11542-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Received: (qmail 15806 invoked by alias); 5 Aug 2010 05:05:00 -0000
Received: (qmail 14059 invoked by uid 48); 5 Aug 2010 05:04:40 -0000
Date: Thu, 05 Aug 2010 05:05:00 -0000
From: "scarybeasts at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Message-ID: <20100805050439.11883.scarybeasts@gmail.com>
Reply-To: sourceware-bugzilla@sourceware.org
Subject: [Bug libc/11883] New: fnmatch() alloca() abuse, with security consequence
X-Bugzilla-Reason: CC
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
X-SW-Source: 2010-08/txt/msg00031.txt.bz2

Demo:

#include <err.h>
#include <fnmatch.h>
#include <locale.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, const char* argv[]) {
  size_t num_as;
  char* p;
  setlocale(LC_ALL, "en_US.UTF8");
  if (argc < 2) {
    errx(1, "Missing argument.");
  }
  num_as = atoi(argv[1]);
  if (num_as < 5) {
    errx(1, "Need 5.");
  }
  p = malloc(num_as);
  if (!p) {
    errx(1, "malloc() failed.");
  }
  memset(p, 'A', num_as);
  p[num_as - 1] = '\0';
  p[0] = 'f';
  p[1] = 'o';
  p[2] = 'o';
  p[3] = '.';
  fnmatch("*.anim[1-9j]", p, 0);
  return 0;
}

./a.out 3000000
Segmentation fault

(If your default max stack size is greater than the default 8MB then you may 
need a larger number)

I chatted to some people and they suggested that there's probably a missing 
__libc_use_alloca() somewhere.

This was the source of a nasty Chromium bug which was worked around for now.

[Random aside: I can't seem to find the default value for __libc_alloca_cutoff 
but if it is > PAGE_SIZE then that in of itself would cause serious issues since 
most people don't compile glibc with -fstack-check, combined with the fact that 
pthread stacks by default are separated with a single guard page]

-- 
           Summary: fnmatch() alloca() abuse, with security consequence
           Product: glibc
           Version: 2.9
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: scarybeasts at gmail dot com
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11883

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.