Re: Re: [CVE Request] glibc iconv_open buffer overflow (was: Re: [oss-security] Re: glibc locale issues)

[Tavis Ormandy <taviso () cmpxchg8b com>]

John Haxby <john.haxby () oracle com> wrote:

> On 13/08/14 07:01, cve-assign () mitre 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.