Date: Thu, 14 Aug 2014 14:23:27 -0700 From: Tavis Ormandy <taviso@...xchg8b.com> To: oss-security@...ts.openwall.com Subject: Re: Re: [CVE Request] glibc iconv_open buffer overflow (was: Re: Re: glibc locale issues) John Haxby <john.haxby@...cle.com> wrote: > On 13/08/14 07:01, cve-assign@...re.org > wrote: > > > > 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> > > > > Use CVE-2014-5119. A CVE-2005-#### number isn't needed because the > > msg00091.html message (referenced in 17187) does not state any security > > implications. > > That's correct. Neither I nor any of the readers of my original bug > report commented on any possible security implications. (Mind you, in > 2005 I was probably a little more naïve.) > > jch > FWIW, after discussion and debugging with Florian I think everyone is convinced this is exploitable on x64 and x86. Additionally, there's also a trivial root if a directory exists with certain characters restrictions. See here for more information. https://sourceware.org/ml/libc-alpha/2014-07/msg00590.html I believe the current plan is to completely remove the transliteration module support, as it hasn't worked for 10+ years. Tavis.
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