Date: Sat, 27 May 2006 19:25:12 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: Garance A Drosehn <gad@FreeBSD.org> Cc: Jeremie Le Hen <jeremie@le-hen.org>, freebsd-security@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, Kris Kennaway <kris@obsecurity.org> Subject: Re: [fbsd] Re: Integrating ProPolice/SSP into FreeBSD Message-ID: <20060527172512.GD25953@obiwan.tataz.chchile.org> In-Reply-To: <p06230901c09d0033296c@[128.113.24.47]> References: <20060526153422.GB25953@obiwan.tataz.chchile.org> <20060526193048.Y77521@fledge.watson.org> <20060526184919.GA69830@xor.obsecurity.org> <p06230901c09d0033296c@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
HI, Robert, Kris, Garance, On Fri, May 26, 2006 at 03:08:03PM -0400, Garance A Drosehn wrote: > At 2:49 PM -0400 5/26/06, Kris Kennaway wrote: > >On Fri, May 26, 2006, Robert Watson wrote: > > > > >> On Fri, 26 May 2006, Jeremie Le Hen wrote: > >> > > > > > first sorry for cross-posting but I thought this patch > > > > might interest -CURRENT users as well as people concerned > > > > by security. > > This makes the assumption that people running -current are > not interested in security... I expressed myself clumsily and I didn't intend to mean this. BTW, I use a SSP'ified -CURRENT :-). > > > > I wrote a patch that integrates ProPolice/SSP into FreeBSD, > > > > one step further than it has been realized so far. > > > > > > This looks very neat. > > Certainly I'd like to see this available to FreeBSD users. > Thanks very much for working on it. > > > > Could you remind me what, if any, ABI issues might exist? > > > I'm familiar with the ideas behind ProPolice, but not the > > > implementation. Can I use SSP-compied libraries with > > > pre-SSP applications? Can I use post-SSP applications > > > with pre-SSP binaries? > > > >Last time I tried it (several years ago, when I maintained > >my own local patch for world integration), backwards binary > >compatibility was an issue, i.e. it was possible to hose > >your system when trying to revert the changes (since all > >rebuilt binaries all depend on symbols no longer provided > >in libc). Kris is right here. The SSP functionality requires two symbols: __guard, the canary pushed on the stack in the function's prologue and checked during the function's epilogue, and __stack_smash_handler() which is called when a stack-based buffer overflow has been detected. There is also a contructor called __guard_setup() used to fill the canary with a random value at startup time, but the latter is declared as static in the file. For the sake of simplicity, I decided to pull them in libc, though GCC 4.1 provides them in libssp (*). You can indeed use SSP'ed libraries along with pre-SSP applications, as long as the latter is linked against the newest libc. If, by chance(?), a pre-SSP application is linked against an older libc that doesn't provide the necessary symbols and in the same time against the lastest SSP'ed libz, the runtime loader will complain about missing symbols. In order to workaround these cases, that I may have wrongly considered as edge cases, I have provided libssp.so as well, so that one can plug in the missing symbols using LD_PRELOAD whenever it's required. It is perfectly possible to use SSP'ed applications with older libraries, as long as we are not speaking of an older libc, of course. The pre-SSP library won't have reference to SSP symbols anyway, and a collision in the symbol namespace is not very likely. I agree with Kris that reverting from a SSP world to a non-SSP one is painful without any help. However, the LD_PRELOAD trick to load libssp.so will bring a lot of ease, and installworld from a pre-SSP source won't break. By the way, this procedure is documented in the FAQ on my web page. OTOH, if the patch is to be merged in the source tree, the SSP -> non-SSP transition has but a few chances to occur. (*) Although having SSP symbols in libssp rather than in libc seems more relevant given the fact that this is the way GCC 4.1 works, this leads to a more intrusive patch (modifying LIBGCC_SPEC). Furthermore, in spite this would indeed allow to make all shared objects depend on libssp, this also leads to the following dead-end problem: In order to avoid linking libssp unconditionally, I modified LIBGCC_SPEC to add "-lssp" on the ld(1) command-line solely when "-fstack-protector" compile-time option is used. This leads to a problem when one want to produce a statically-linked non-SSP binary that uses a library which does require SSP symbols. In that case the ld(1) command issued by gcc won't hold "-lssp" and there will be a link-time error. IMHO, this is a strong POLA breakage. I found no easy way to circumvent this, but hacking gcc to catch this. This is the main reason I gave up using libssp. Note that the problem doesn't arise with dynamic objects since those that require SSP symbols can have a dependency on libssp.so. > Could we do something to ease in the transition? First add > some kind of stubs for those routines, and then later do > the switch to bring in ProPolice? Or something else like > that? Yes, it is perferctly possible to only apply the ProPolice patch, the user will then be able to use -fstack-protector. The original patch puts SSP symbols in libgcc, which only exists as a static library on FreeBSD. Nevertheless, I don't think it is worthwhile. The glue I have written is fairly little intrusive: a user applying the patch on his source tree without specifying WITH_SSP=yes, wouldn't notice anything at all, except the existence of a new GCC option and two new symbols in libc. I hope these informations will help. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060527172512.GD25953>