oss-security - Re: CVE id request: libc fortify source information disclosure

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
>

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.