I have reproduced the issue with glibc from jaunty, 2.9-4ubuntu6, and can confirm that the version of glibc in jaunty-proposed, 2.9-4ubuntu6.1, has a stack canary value that contains a leading NULL byte. I've verified that the the glibc-security regression tests all pass on both i386 and amd64 with the version of glibc in proposed, as well ensuring that i386, amd64, and lpia systems successfully reboot and bring up a gnome desktop sessions, and have also ran through a few of the other qa-regression-tests to verify that the libc update didn't break anything with them.
The one downside to using a leading NULL byte is this reduces the search space that an attacker would to go through to brute-force an attempted overflow while guessing at the canary value; for 64 bit platforms, this only reduces the space to 56 bits which is tolerable, but on a 32 bit platform, the possible canary value space is reduced to 24 bits, which makes it possibly easier to successfully brute-force before the attack is noticed. (Note that one of the published weaknesses against ASLR is that on 32 bit platforms, the effective randomness is around 20-21 bits,and thus easily brute-forcible.) OTOH, given that a large percentage of such vulnerabilities are due to poor C string handling, this fix is a reasonable tradeoff given that it makes exploitation harder for those vulnerabilities. In an ideal world, the stack canary would be 64 or 128 bits wide on all platforms, but that has the potential to introduce noticable performance issues. Marking verification-done. ** Tags added: verification-done ** Tags removed: verification-needed -- stack protector guard value does not lead with a NULL byte https://bugs.launchpad.net/bugs/413278 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
