This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] __gconv_translit_find: Actually append ".so" to module name [BZ #17187]


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]