[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SFTP question


On Fri, 26 Dec 2014 10:42:21 -0500
Jerry Stuckle <stucklejerry@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
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.


Reply to: