Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

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.