Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.

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