stack protector guard value does not lead with a NULL byte

Bug #413278 reported by Kees Cook on 2009-08-13
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GLibC
Fix Released
Medium
eglibc (Ubuntu)
Medium
Kees Cook
Jaunty
Medium
Unassigned
Karmic
Medium
Kees Cook
glibc (Ubuntu)
Undecided
Unassigned
Jaunty
Medium
Kees Cook
Karmic
Undecided
Unassigned

Bug Description

IMPACT: stack protections are weakened due to strcpy function being able to write the stack guard (since it does not start with a zero byte).
ADDRESSED: correctly implement leading zero, as done in Karmic.
DISCUSSION: regression potential is low, since the patch is isolated and well tested.

TEST CASE:
$ bzr branch lp:~ubuntu-bugcontrol/qa-regression-testing/master qa-regression-testing
$ cd qa-regression-testing/scripts
$ ./test-glibc-security.py -v
Build helper tools ... (9.10) ok
glibc heap protection ... ok
sprintf not pre-truncated with -D_FORTIFY_SOURCE=2 ... ok
glibc pointer obfuscation ... ok
Password hashes ... (sha512) ok
Stack guard exists ... ok
Stack guard leads with zero byte ... FAIL
Stack guard is randomized ... ok

======================================================================
FAIL: Stack guard leads with zero byte
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test-glibc-security.py", line 170, in test_81_stack_guard_leads_zero
    self.assertEqual(one.startswith('00 '), expected, one)
AssertionError: 62 55 59 69 cd 20 39 80

----------------------------------------------------------------------
Ran 8 tests in 0.145s

FAILED (failures=1)

expected outcome: 0 failures.

ProblemType: Bug
Architecture: amd64
Date: Thu Aug 13 13:59:02 2009
Dependencies:
 findutils 4.4.2-1
 gcc-4.4-base 4.4.1-1ubuntu3
 libc6 2.10.1-0ubuntu6
 libgcc1 1:4.4.1-1ubuntu3
DistroRelease: Ubuntu 9.10
Package: libc6 2.10.1-0ubuntu6
ProcEnviron:
 LANGUAGE=en_US.UTF-8
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-5.24-generic
SourcePackage: eglibc
Uname: Linux 2.6.31-5-generic x86_64

When building the stack guard, it has been traditionally important to have the
value start (in memory) with a zero byte to protect the guard value (and the
rest of the stack past it) from being read via strcpy, etc.

This patch reduces the number of random bytes by one, leaving the leading zero byte.

Created attachment 3933
keep leading zero

I should clarify -- the read-blocking is nice, but the more common reason the
leading zero is important is to avoid the guard being written as part of a
larger overflow being written out by a str* function, if its value were leaked
to an attacker in some other way.

Kees Cook (kees) on 2009-08-13
Changed in eglibc (Ubuntu Karmic):
assignee: nobody → Kees Cook (kees)
importance: Undecided → Medium
milestone: none → karmic-alpha-5
Changed in eglibc (Ubuntu Jaunty):
assignee: nobody → Kees Cook (kees)
importance: Undecided → Medium
status: New → Invalid
Changed in glibc (Ubuntu Karmic):
status: New → Invalid
Changed in eglibc (Ubuntu Jaunty):
assignee: Kees Cook (kees) → nobody
Kees Cook (kees) on 2009-08-13
Changed in glibc (Ubuntu Jaunty):
assignee: nobody → Kees Cook (kees)
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eglibc - 2.10.1-0ubuntu7

---------------
eglibc (2.10.1-0ubuntu7) karmic; urgency=low

  * patches/ubuntu/submitted-leading-zero-stack-guard.diff: require that
    the stack guard start with a zero-byte to protect against str*
    function more completely (LP: #413278).

 -- Kees Cook <email address hidden> Wed, 12 Aug 2009 16:35:43 -0700

Changed in eglibc (Ubuntu Karmic):
status: New → Fix Released
Changed in glibc:
status: Unknown → Confirmed
Kees Cook (kees) wrote :

Uploaded to -proposed...

description: updated
Martin Pitt (pitti) wrote :

Is that a regression from intrepid, or cause serious bugs? In particular, would this have helped to mitigate vulnerabilities which were discovered/fixed in jaunty?

This does not match the SRU criteria at first sight, so please elaborate about the impact a bit. The regression potential on this one seems to be excessively high to me, since it could potentially affect all programs (and some might do weird tricks with the stack, and got fixed later on for karmic).

Changed in glibc (Ubuntu Jaunty):
status: New → Incomplete
Kees Cook (kees) wrote :

This is a regression from Intrepid, yes. Upstream glibc changed how they constructed the random value, losing this protection from strcpy-style overflows. While I do not have any active examples of exploits that have read-access to stack memory and also a strcpy, I do feel the regression potential is low given that this patch does not change the locations of the stack protector, it just limits the first byte to 0.

Changed in glibc (Ubuntu Jaunty):
status: Incomplete → New
Martin Pitt (pitti) wrote :

Accepted glibc into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: regression-release
Changed in glibc (Ubuntu Jaunty):
status: New → Fix Committed
tags: added: verification-needed
Steve Beattie (sbeattie) wrote :

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
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package glibc - 2.9-4ubuntu6.1

---------------
glibc (2.9-4ubuntu6.1) jaunty-proposed; urgency=low

  * patches/ubuntu/submitted-leading-zero-stack-guard.diff: require that
    the stack guard start with a zero-byte to protect against str*
    function more completely (LP: #413278).

 -- Kees Cook <email address hidden> Tue, 25 Aug 2009 00:06:51 -0700

Changed in glibc (Ubuntu Jaunty):
status: Fix Committed → Fix Released

I've applied a cleaner and more efficient patch.

Changed in glibc:
importance: Unknown → Medium
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.