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