Re: Re: glibc locale issues

[Tavis Ormandy <taviso () cmpxchg8b com>]

Florian Weimer <fweimer () redhat com> wrote:

> On 07/14/2014 04:15 AM, Tavis Ormandy wrote:
> > Tavis Ormandy <taviso () cmpxchg8b 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?

No, it's nothing to do with glib.

> 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.

Is it possible you're thinking of the LC_ALL thing? (the questionable
ForceCommand bypass with path traversal if you're forcecommand'd to an
application that does something odd with localized strings and you can
create a file and your sshd has been configured with AcceptEnv LC_*). This
is an unrelated heap overflow - not a path traversal.

> > 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.

No, it's quite definitely possible, I'm really close but was busy this week.

Tavis.