Date: Tue, 29 Jul 2014 21:08:46 +0200 From: Florian Weimer <fweimer@...hat.com> To: oss-security@...ts.openwall.com Subject: [CVE Request] glibc iconv_open buffer overflow (was: Re: Re: glibc locale issues) On 07/21/2014 02:17 PM, Florian Weimer wrote: > On 07/14/2014 04:15 AM, Tavis Ormandy wrote: >> Tavis Ormandy <taviso@...xchg8b.com> wrote: >> >>> I just remembered another charset issues I had looked into but >>> abandoned. >>> >>> First of all, I think the need_so logic in gconv_trans is broken, but >>> even >>> if it worked there is an off by one error in __gconv_translit_find() (it >>> does + 3 instead of + 3 + 1 in the allocation. >> >> To be clear, I suspect this is exploitable. It would be nice if you could >> modify the buffer such that gconv will open a path with a string you've >> appended it (e.g. CHARSET=//. pkexec ./../../../../tmp/foo.so), > > This is about the glib part and the alias processing, right? > > iconv/gconv_charset.h:strip() normalizes the transliteration argument to > iconv_open, so the resulting file names follow a particular pattern, and > there cannot be enough slashes to ascend to a writable directory. > >> if not maybe the one byte overflow is still exploitable. > > Hmm. How likely is that? It overflows in to malloc metadata, and the > glibc malloc hardening should catch that these days. Not necessarily on 32-bit architectures, so I agree with Tavis now, and we need a CVE. The upstream bug is: <https://sourceware.org/bugzilla/show_bug.cgi?id=17187> The discussion on the libc-alpha mailing list about the fix is still ongoing, and nothing has been committed yet. -- Florian Weimer / Red Hat Product Security
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ