Re: SFTP question
On Fri, 26 Dec 2014 10:42:21 -0500
Jerry Stuckle <email@example.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
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
> 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
> Upgrades in Debian are
> performed by root or someone with root privileges.
Upgrades has nothing in common with what I'm writing about.