This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] __gconv_translit_find: Actually append ".so" to module name [BZ #17187]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Tavis Ormandy <taviso at google dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 29 Jul 2014 21:05:26 +0200
- Subject: Re: [PATCH] __gconv_translit_find: Actually append ".so" to module name [BZ #17187]
- Authentication-results: sourceware.org; auth=none
- References: <53CD0F15 dot 3030806 at redhat dot com> <20140728230221 dot 66D7A2C3994 at topped-with-meat dot com> <53D73636 dot 7060207 at redhat dot com> <CAJ_zFkJLdEpJzKSM3HDN6PuVriTd4vKNqq=EubtCR5qqvt1U8g at mail dot gmail dot com>
On 07/29/2014 07:26 PM, Tavis Ormandy wrote:
On Mon, Jul 28, 2014 at 10:50 PM, Florian Weimer <fweimer@redhat.com
<mailto:fweimer@redhat.com>> wrote:
On 07/29/2014 01:02 AM, Roland McGrath wrote:
The original reporter (Tavis) considers this a security issue.
I don't see
anything in bugzilla or in your posting that indicates your
assessment of
the security impact of the bug. I can only surmise from the
fact that you
made the bug and fix public rather than following CVE/embargo
processes
that you don't deem it especially sensitive.
The bug was reported publicly to a security-related mailing list.
At this point, it's difficult to put back the toothpaste into the
tube.
My assessment is "not exploitable" because it's a NUL byte written
into malloc metadata. But Tavis disagrees. He is usually right.
And that's why I'm not really sure.
With some caveats, it is certainly exploitable for privilege escalation.
It is possible to attack malloc metadata and turn that into controlled
memory corruption, pivoting them into more general primitives (such as
writing to an arbitrary address). In this case I believe you're
modifying the adjacent chunk size, and compensating to keep the metadata
consistent is possible and has been demonstrated in similar cases.
Ah, but only on 32-bit architectures, and not with 64-bit architectures
(without writing a couple of NULs), right?
I totally I agree that this can be exploitable on 32-bit architectures.
I don't know why I disregarded them. *sigh*
I'll ask for a CVE assignment on the oss-security list, and we should
treat this as a security vulnerability. Thanks for reporting this, Tavis.
Because this functionality has been broken for so long, it's possible
re-enabling it might have some unintended consequences for security
(i.e. in setuid programs). If you think this transliteration should
certainly be allowed for setuid programs, then it makes sense to give
the converters a quick parse for vulnerabilities (I volunteer to do so).
However, if you're open to leaving the functionality disabled for
AT_SECURE (as it hasn't worked for years any way) that would reduce
attack surface for setuid programs... What do you think?
I need to figure out all this, but I think these gconv modules are
available by other means, so fixing this shouldn't open up totally new
exploit vectors. And the missing file extension doesn't matter for the
dlopen call, eitherâyou still lose with the current code if the
directory is attacker-controlled for some reason.
--
Florian Weimer / Red Hat Product Security