just wondering about this. i noticed "make install" installs
ssh-keyscan group-writable. is this intentional?
openssh-2.5.2p2/Makefile.in, line 168:
$(INSTALL) -m 0775 -s ssh-keyscan $(DESTDIR)$(bindir)/ssh-keyscan
chris
--
Christopher Linn, <celinn at mtu.edu> | By no means shall either the
CEC
Staff System Administrator | or MTU be held in any way liable
Center for Experimental Computation | for any opinions or conjecture I
Michigan Technological University | hold to or imply to hold herein.
mouring at etoh.eviladmin.org
2001-Mar-23 22:18 UTC
2.5.2p2 ssh-keyscan installed group writable?
On Fri, 23 Mar 2001, Christopher Linn wrote:> just wondering about this. i noticed "make install" installs > ssh-keyscan group-writable. is this intentional? > > openssh-2.5.2p2/Makefile.in, line 168: > > $(INSTALL) -m 0775 -s ssh-keyscan $(DESTDIR)$(bindir)/ssh-keyscan >Hmm.. looks like a fat finger mistake. I'll fix it in both CVS branches when I get home. - Ben
Jason-- SetUID binaries are *not* A Bad Thing. SetUID binaries are A Powerful Tool. Sometimes a power hammer (using .22 shells) can do things that a regular claw hammer can't. That doesn't mean that it's safe to use for the novice. The correct answer for OpenSSH is, IMHO: 1. Continue to support SetUID installation of the ssh client in order to support rsa-rhosts auth--but perhaps the default should transition over to non-SetUID (with a big warning note!) 2. Install *all* executables (not just SetUID) as mode 511 (or 4511 if appropriate). There's no reason why root needs to be able to routinely overwrite them, and there's no reason why non-root users need to be able to routinely copy them or run strings/objdump on them... so why allow it? This will require an additional step during an upgrade, but could also prevent accidental or intentional overwriting which is not desireable. I know of at least one system where when given a user-level account on this supposedly-secure system, it took me less than 20 minutes to find a poorly- written local SetUID binary, run strings against it, discover a call to an external binary *with a relative path*, craft an exploit, and take root. That was an extreme case...but it would have been near impossible if the perms on that poorly-written binary had been more sensible. It doesn't mean that the idea of SetUID binaries is fundamentally flawed, since there are sometimes things which cannot be accomplished in any other feasible way. Comments? Rip Loomis Voice Number: (410) 953-6874 -------------------------------------------------------- Senior Security Engineer Center for Information Security Technology Science Applications International Corporation http://www.cist.saic.com> -----Original Message----- > From: Jason Stone [mailto:jason at dfmm.org] > Sent: Tuesday, March 27, 2001 5:21 PM > To: Kevin Steves > Cc: openssh-unix-dev at mindrot.org > Subject: Re: 2.5.2p2 ssh-keyscan installed group writable? > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > and i also wonder why isn't ssh group, other readable: > > > > no) > > AC_MSG_RESULT(no) > > SSHMODE=0711 > > ;; > > *) AC_MSG_RESULT(yes) > > SSHMODE=04711 > > Because it's (unfortunately) setuid, and you don't want > people to be able > to easily read your setuid binaries. > > For example, a linux exploit was just published today which allows any > setuid binary to be exploited, but in order for the exploit > to work, you > have to run objdump on the binary to find the bss offset. If > the binary > is not readable, then the above attack is frustrated (though not > prevented). > > Yet another reminder that suid binaries are A Bad Thing. > > > -Jason
Rachit-- Agreed in part. The binary shouldn't have been so poorly written...but making the binary non- readable by regular users is in this case part of "defense in depth". Security by obscurity should not be depended on, since it has been and will continue to be a weak security measure. In this case, however, it would have helped the overall security of the system. Bottom line--almost any system is going to be more secure with a "default deny" policy than a "default allow" policy...and this is a simple change which doesn't break anything. Rip Loomis Voice Number: (410) 953-6874 -------------------------------------------------------- Senior Security Engineer Center for Information Security Technology Science Applications International Corporation http://www.cist.saic.com> -----Original Message----- > From: Rachit Siamwalla [mailto:rachit at ensim.com] > Sent: Tuesday, March 27, 2001 6:55 PM > To: Loomis, Rip > Cc: 'Jason Stone'; openssh-unix-dev at mindrot.org > Subject: Re: 2.5.2p2 ssh-keyscan installed group writable? > > > > I totally agree and understand this example, but I can't help thinking > relying on read permissions to "secure" a binary is exactly > the same as > "security through obscurity" :) > > -rchit > > > 2. Install *all* executables (not just SetUID) > > as mode 511 (or 4511 if appropriate). > > There's no reason why root needs to be > > able to routinely overwrite them, > > and there's no reason why non-root > > users need to be able to routinely > > copy them or run strings/objdump on them... > > so why allow it? This will require > > an additional step during an upgrade, > > but could also prevent accidental > > or intentional overwriting which is > > not desireable. >