Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 Jul 2014 21:08:46 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
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 <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.

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>

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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ