[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AANLkTim88gVkcHjKC++Bd3U=N0jxR=5QcfgpLQxr8A5X@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
