On 12/26/2014 1:51 AM, Reco wrote: > Hi. > > On Thu, Dec 25, 2014 at 09:19:49PM -0500, Jerry Stuckle wrote: >> On 12/25/2014 11:23 AM, Reco wrote: >>> Hi. >>> >>> On Thu, Dec 25, 2014 at 10:18:11AM -0500, Jerry Stuckle wrote: >>>> On 12/25/2014 8:54 AM, Andre N Batista wrote: >>>>> On Wed, Dec 24, 2014 at 11:18:36AM -0500, Jerry Stuckle wrote: >>>>>> On 12/24/2014 2:01 AM, Danny wrote: >>>>>>> Hi Bob, >>>>>>> >>>>>>> You were right, SFTP, FileZilla and Proftp confused the hell out of me >>>>>>> ... lol >>>>>>> ... I must add in my defense though that I was in a state of panic >>>>>>> after syslog >>>>>>> warned me of an attack by someone during the night via ssh ... So I >>>>>>> frantically tried to >>>>>>> make ssh and Proftp work together without reading the online guides >>>>>>> properly ... >>>>>>> >>>>>>> Sometimes one does stupid things ... lol ... >>>>>>> >>>>>>> Thanks for everyone's input ... >>>>>>> >>>>>>> Danny >>>>>>> >>>>>> >>>>>> Danny, >>>>>> >>>>>> As a side note - don't panic over SSH attacks. Instead, use the right >>>>>> tools and techniques to secure your systems and let them do their jobs. >>>>>> Monitor the server to ensure you didn't leave any holes. >>>>>> >>>>>> For instance, Fail2ban blocked over 100 IP's from accessing one of my >>>>>> servers on yesterday alone. The attacks keep coming, but none have ever >>>>>> succeeded. >>>>> >>>>> Not surprisingly, I mostly agree with the advice given here, we all >>>>> learnt from the same sources. >>>>> >>>>> Nonetheless, since you claimed to be using puTTy for your ssh needs on >>>>> windows, I should warn you that recently someone claimed to be able to >>>>> use it as a means to compromise a ssh server: >>>>> >>>>> http://seclists.org/fulldisclosure/2014/Dec/42 >>>>> >>>>> I have not put it's claims to test, but since the last stable version of >>>>> putty dates back one year >>>>> >>>>> http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html >>>>> >>>>> and since there seems to be no mention of this bug on putty bug tracking >>>>> system >>>>> >>>>> http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ >>>>> >>>>> I guess you should deploy it at large, at least until it has been fixed. >>>>> >>>>> Good luck! >>>>> >>>> >>>> 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. 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. 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. And who said anything about user-writable? Upgrades in Debian are performed by root or someone with root privileges. Jerry -- 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/549d81dd.7070...@gmail.com
