Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 Jul 2014 21:08:46 +0200
From: Florian Weimer <>
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 <> 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/,
> 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:


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.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.