Dailydave mailing list archives

Re: gcc 4.1 security features


From: "Phantasmal Phantasmagoria" <phantasmal () hush ai>
Date: Sun, 19 Feb 2006 16:52:44 +1300

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 17 Feb 2006 07:44:54 +1300 Gadi Evron <ge () linuxbox org>
wrote:
Matt wrote:
In 4.1? I will have to look. I sent this out to a different
mailing list a few weeks ago, maybe people here will have some
answers. This relates to similar changes in gcc/glic instead of
kernel
level prevention.

-----

In version 2.3.4 of glibc...

if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0) ||
__builtin_expect ((uintptr_t) p & MALLOC_ALIGN_MASK, 0))

^^^ This line was added.

There is also a comment on it:

+  /* Little security check which won't hurt performance: the
+     allocator never wrapps around at the end of the address
space.
+     Therefore we can exclude some size values which might appear
+     here by accident or by "design" from some intruder.  */
+  if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0)
+      || __builtin_expect ((uintptr_t) p & MALLOC_ALIGN_MASK, 0))
+    {
+      errstr = "free(): invalid pointer";
+    errout:
+      malloc_printerr (check_action, errstr, mem);
+      return;
+    }

It was mentioned on http://www.securityfocus.com/columnists/359.

Now, my questions if some of you can be so kind as to try and
answer: In your estimation, how many people actually heard about
this
(outside the tight circle of secure coding maniacs)?

In your estimation, how many people actually go through the pain
of upgrading glibc?

This seems effective to me. In retrospect, how effective did it
prove to be over the past year, in your experience? Is it too
early to
tell?

From a purely technical standpoint this particular integrity test
was relatively simple to bypass. Joel Eriksson mentioned Steffan
Esser's unlink patch. I think that patch had a far greater impact
than any of the other security measures that were implemented at
the time.

Not many people are familiar with the results I documented in the
"Malloc Maleficarum", and as of yet the techniques described there
have had little public impact. But nevertheless, I do think it
would be fair to say that these "improvements" haven't been as
effective as some people thought them to be.

The problem is that glibc's malloc implementation is poorly
designed in regards to security. Ulrich Drepper can add integrity
tests... and we can break them. Ad infinitum. The best thing for
everyone involved is to redesign. OpenBSD have. So has Yves Younan.
And so should the glibc maintainers.

We, the adepts, always appreciate a new challenge.

Sincerely,
Phantasmal Phantasmagoria

-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkP366wACgkQImcz/hfgxg2MMACeMwtkEW2TKRanGbHbDYRDDhRPmi4A
njwqUBBk3lm+BYJ7K7luzwCrjSML
=Y/cb
-----END PGP SIGNATURE-----




Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485


Current thread: