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

[Florian Weimer]

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