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:
- gcc 4.1 security features Matt (Feb 16)
- Re: gcc 4.1 security features Gadi Evron (Feb 16)
- Re: gcc 4.1 security features Halvar Flake (Feb 16)
- Re: gcc 4.1 security features Joel Eriksson (Feb 16)
- Re: gcc 4.1 security features Hikaru Gosun (Feb 17)
- Re: gcc 4.1 security features Angelo Dell'Aera (Feb 17)
- RE: gcc 4.1 security features Dave Korn (Feb 18)
- Re: gcc 4.1 security features Matt Conover (Feb 21)
- Re: gcc 4.1 security features Gadi Evron (Feb 16)
- Re: gcc 4.1 security features Eduardo Tongson (Feb 17)
- <Possible follow-ups>
- Re: gcc 4.1 security features Phantasmal Phantasmagoria (Feb 21)