Re: SFTP question
On 12/26/2014 12:48 PM, Reco wrote:
> Hi.
>
> 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
> executables.
> Unless, of course, your definitions of 'binary' and 'library' are
> different from everyone else's.
>
I didn't say specifically binary executables. I just used .dll and .so
as an example. You're the one who brought up java libraries.
>
>> 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.
>
I never said the kernel used shared libraries. But the kernel has
modules, device drivers, file systems, and more. And those modules can
be replaced by ones with bad code, if one isn't careful.
>
>> 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.
>
You can't do either while the library is in use. And whether it uses
the library in the same directory or not depends entirely on the
environment settings - just like in Linux.
>
>> 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.
>
That's one vulnerability. But it is by far not the only one. There are
many ways to insert bad code into a system.
>
>> Upgrades in Debian are
>> performed by root or someone with root privileges.
>
> Upgrades has nothing in common with what I'm writing about.
>
> Reco
>
>
It does with what I'm talking about.
Jerry
Reply to: