[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimpyhKJ7hpj7RY5Xsv9Zmbnzac08vp_wD+QTDC8@mail.gmail.com>
Date: Thu, 2 Sep 2010 12:23:23 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: oss-security@...ts.openwall.com
Cc: coley@...us.mitre.org
Subject: Re: CVE id request: libc fortify source information disclosure
Tomas,
> For the sake of correctness, protective technology that kicks in in the
> Dan's example is stack protector, not FORTIFY_SOURCE. Though it's
> probably still glibc to blame for using the same error-reporting
> function in both cases.
You are correct. Both the __stack_chk_fail(), which is inserted due
to stack protection, and the more general __chk_fail(), which is
inserted due to FORTIFY_SOURCE and may trigger for static buffer
overflows in other segments, call out to the same __fortify_fail()
function to print out the stack trace.
>
> 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.
> --
> 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.
