Hi. On Fri, 26 Dec 2014 10:42:21 -0500 Jerry Stuckle <stuckleje...@gmail.com> wrote:
> >>>> It's possible to corrupt ANY program if you replace a .dll or .so with > >>>> your own code. > >>> > >>> Indeed. But the program which can be tricked to use your own library > >>> instead of a system one - is called vulnerable usually. I don't mean > >>> LD_PRELOAD or LD_LIBRARY_PATH tricks but something akin to a braindead > >>> Windows behavior (which looks for libraries in a current dir first). > >>> > >>> Reco > >>> > >>> > >> > >> ANY program is vulnerable if care isn't taken to ensure a download > >> contains the right files. That's why there are checksums. > > > > Ok, I can agree with that. > > > > > >> So according to your definition, any program - including the kernel - is > >> vulnerable to such an attack, and should be classified as such. This is > >> true for ANY operating system - not just Windows or Linux. > > > > I disagree with you. All one needs to do is to put one single RPATH > > entry into the compiled binary by mistake, and … then you have things > > like #754278. > > Putting a malicious library at known user-writable location is one > > thing, loading a kernel module as a root (I presume that's what you've > > meant with your kernel reference) is another thing. > > > > Reco > > > > > > > 754278 has nothing to do with substituting a .so or .dll. It only deals > with where a program looks for binaries. Strace output in the message 13 of bug 754278 clearly shows a java executable looking for the libraries in the unusual place. Not binary executables. Unless, of course, your definitions of 'binary' and 'library' are different from everyone else's. > And it is perfectly possible to corrupt the kernel by substituting a .so > the kernel uses in Linux. Nothing to do with loading a new module. Kernel does not use shared libraries. Userspace does. > The new library will take effect the next reboot. In this way, Windows > is much more secure because, unlike in Linux, you cannot replace an > in-use library. It requires a bunch of gyrations and the replacement is > done on restart. Place a library into program's current working dir. Program will happily use such library. How it's 'more secure'? And to replace a library for the working process you simply rename an original one. > And who said anything about user-writable? I did. The whole point of this 'stray rpath' thing is to trick root-owned process into loading user-supplied library from a world-writable location. > Upgrades in Debian are > performed by root or someone with root privileges. Upgrades has nothing in common with what I'm writing about. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141226204849.3f1115e6e62e8098631d9...@gmail.com