oss-sec mailing list archives
Re: CVE id request: libc fortify source information disclosure
From: Dan Rosenberg <dan.j.rosenberg () gmail com>
Date: Thu, 2 Sep 2010 12:23:23 -0400
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
Current thread:
- CVE id request: libc fortify source information disclosure Nico Golde (Aug 25)
- Re: CVE id request: libc fortify source information disclosure Josh Bressers (Aug 31)
- Re: CVE id request: libc fortify source information disclosure Steven M. Christey (Aug 31)
- Re: CVE id request: libc fortify source information disclosure Tomas Hoger (Sep 02)
- Re: CVE id request: libc fortify source information disclosure Dan Rosenberg (Sep 02)
- Re: CVE id request: libc fortify source information disclosure Tomas Hoger (Sep 02)
- Re: CVE id request: libc fortify source information disclosure Dan Rosenberg (Sep 02)
- Re: CVE id request: libc fortify source information disclosure Steven M. Christey (Aug 31)
- Re: CVE id request: libc fortify source information disclosure Josh Bressers (Aug 31)