stack protector guard value uses a static sentinel
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
glibc (Ubuntu) |
Fix Released
|
High
|
Kees Cook | ||
Dapper |
Won't Fix
|
Undecided
|
Unassigned | ||
Hardy |
Fix Released
|
Medium
|
Kees Cook |
Bug Description
glibc's SSP implementation is using only the static 0xff0a0000 guard value. Fedora has been carrying an unupstreamed glibc patch for 3 years to make this relatively random.
(see _dl_setup_
http://
statement explaining the impact: stack overflow attacks are easier to launch when the stack guard is a known value.
how the bug has been addressed: Fedora patch ported in Intrepid, Jaunty. Karmic uses AT_RANDOM.
regression potential: comparing build log output shows no differences -- all tests seem to pass:
https:/
TEST CASE:
bzr branch lp:~ubuntu-bugcontrol/qa-regression-testing/master qa-regression-
cd qa-regression-
sudo apt-get install lsb-release build-essential
./test-
EXPECTED:
Build helper tools ... (8.04) ok
glibc heap protection ... ok
sprintf not pre-truncated with -D_FORTIFY_SOURCE=2 ... (skipped: Hardy known broken) ok
glibc pointer obfuscation ... ok
Password hashes ... (md5) ok
Stack guard exists ... ok
Stack guard leads with zero byte ... ok
Stack guard is randomized ... ok
CURRENTLY:
Stack guard is randomized ... FAIL
=======
FAIL: Stack guard is randomized
-------
Traceback (most recent call last):
File "./test-
self.
AssertionError: 0xff0a0000
0xff0a0000
0xff0a0000
Changed in glibc (Ubuntu Dapper): | |
status: | New → Triaged |
Changed in glibc (Ubuntu Hardy): | |
status: | New → Triaged |
Changed in glibc (Ubuntu Dapper): | |
status: | Triaged → Won't Fix |
description: | updated |
description: | updated |
This bug was fixed in the package glibc - 2.8~20080505- 0ubuntu7
--------------- 0ubuntu7) intrepid; urgency=low
glibc (2.8~20080505-
* Add debian/ patches/ ubuntu/ stack-guard- quick-randomiza tion.diff: do
light-weight randomization of the stack guard value instead of using
a static sentinel (LP: #275493).
-- Kees Cook <email address hidden> Sun, 28 Sep 2008 09:30:01 -0700