Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 2 Sep 2010 13:43:57 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: Tomas Hoger <thoger@...hat.com>
Cc: oss-security@...ts.openwall.com, coley@...us.mitre.org
Subject: Re: CVE id request: libc fortify source information disclosure

I retract my previous statement - you're correct that the backtrace
also can reveal this same information.  Perhaps this is an acceptable
risk, since I can't think of a single real-life case where this would
have actually been useful to an attacker (although it's not too hard
to imagine such a situation).  Or perhaps printing out any of this
information to unprivileged users running suid applications should be
reconsidered.

-Dan

On Thu, Sep 2, 2010 at 1:17 PM, Tomas Hoger <thoger@...hat.com> wrote:
> On Thu, 2 Sep 2010 12:23:23 -0400 Dan Rosenberg wrote:
>
>> > It seems the fix would need to remove all possibly-useful info from
>> > the error message.
>>
>> The backtrace or memory map don't really contain any potentially
>> sensitive information that couldn't be obtained otherwise.  It's just
>> the reference to argv[0] (in glibc/debug/fortify_fail.c) that worries
>> me, because this can be directly influenced to cause a printout of
>> process memory.
>
> In case of stack protector failed check, it's still an attempt to
> print-out info based on what's known to be (partially) corrupted.
>
> --
> Tomas Hoger / Red Hat Security Response Team
>

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