On Sat, Feb 17, 2007 at 09:39:58AM -0500, Mike Frysinger wrote: > On Saturday 17 February 2007, Brian Harring wrote: > > Security impact is from a pkg potentially dragging along old libs; if > > you've got a stable pkg that gets an update once every blue moon, it > > can hold onto the lib for a *long* time while still using the lib; > > thus if a vuln. in the lib, said pkg still is screwed. > > umm, no ... the package itself is updated against the new copy while the old > copy exists for other packages that have already been built
Suspect you're ignoring soname changes, which is about all this patch would address- for example, ssl's old form of breakage. In that case, *yes* the package gets updated, anything recompiled should get the correct lib (assuming the code knows the appropriate linker args), but the old vuln. lib still will hang around as long as anything refs it. > > Other angle is someone intentionally forcing usage of a known bad > > library that is still dangling. Corner case, but doable. > > as i said, this is the "invalid" syntax: > ... /usr/lib/libfoo.so.3 ... Not to LD_PRELOAD :) Haven't tried anything crazy, but suspect it can be abused to override to the old. > > Bit curious how this is going to behave if via linked in libs, new loc > > and old get loaded alongside... > > this would require multiple libraries to be involved in the equation and the > answer is undefined behavior which most certainly result in runtime > failures ... Point there was that instead of just bailing with "lib is missing", suspect it'll manage to run, then segfault at potentially crappy times. ~harring
pgpTux6lyn48U.pgp
Description: PGP signature
