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 <>
Subject: Re: CVE id request: libc fortify source information disclosure


> 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.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ