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