On Mon, Mar 27, 2006 at 09:31:08PM -0600, Peter Samuelson wrote: > > Could somebody kick a buildd to binNMU subversion 1.3.0-4 on i386 only? > A well-known bug where we don't cleanse quite all the rpaths suddenly > became a security issue because the last version uploaded on i386 was > built in /tmp, so the two apache modules have built-in rpaths that > would let an attacker inject code by putting it in a specific hierarchy > under /tmp before apache2 is started / restarted.
Note that the binNMU will change that rpath to /build/buildd/subversion-1.3.0/BUILD/subversion/libsvn_repos/.libs:/build/buildd/subversion-1.3.0/BUILD/subversion/libsvn_fs/.libs:/build/buildd/subversion-1.3.0/BUILD/subversion/libsvn_delta/.libs:/build/buildd/subversion-1.3.0/BUILD/subversion/libsvn_subr/.libs > The actual fix is to nuke the rpaths, and that's what I'll do next, but > I'm not certain how long it will take to figure out how to do it > properly. You can build-depend on chrpath and use 'chrpath -d' on the libs in the rules file, at least as a temporary solution. > The interim fix would be a binNMU which is not built under a > directory that will be world-readable on Debian systems. This is only > needed on i386 because the other architectures auto-built it already, > in their usual locations. The assumption that /build is not world-readable on any Debian systems does not seem entirely warranted since Debian is not assigning any meaning to it so it is a local decision. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
