[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53CD04EB.1040003@redhat.com>
Date: Mon, 21 Jul 2014 14:17:47 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: glibc locale issues
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.
--
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
