[Mod: This message is a reason *why* linux-security is moderated list. This
is also a reason why Rogier, myself, Alan Cox and others really do not want
to have completely open lists that deal with security related aspects of
running a system as way too many people just jump to conclusions and give
suggestions without doing any reasearch on a subject. -- alex (co-moderator
of linux-{security|alert}@redhat.com)]
Your message dated: Tue, 16 Sep 97 15:06:58 GMT> On Tue, 16 Sep 1997 09:50:08 -0400, pstewart
<pstewart@ONCOMDIS.ON.CA> wrote:
>
> Well, first of all, as a general rule chmod -s all files except those that
> *really* need it... And you really need in your system.
>
> >-rwsr-x--- 1 root floppy 18300 Jul 5 1996 /usr/bin/fdmount
> Do you use fd a lot ?
Huh? It can be only executed frmo a group floppy.
>
> >-rwxr-sr-x 1 root uucp 117101 Dec 11 1995 /usr/bin/minicom
> you can chmod -s it most of the times
This is sgid executable, not suid. In order to create a lock file you better
have it.
> >-rwsr-xr-x 1 root bin 17196 May 22 1996 /usr/bin/a
/usr/bin/a
> t
> there are some exploits for it. I suggest you chmod -s it.
Silly advice. There were some exploits of atrun about 2 *years* ago.
>
> >-rws--x--x 1 root bin 9236 May 22 1996 /usr/bin/crontab
> same as above
And lose all functionality? Nice comment.
>
> >-rws--x--x 1 root bin 39416 May 22 1996 /usr/bin/splitvt
> Uh, I don''t know what''s that for. Chmod -s it and see if
you have any adverse
> reaction.
>
> >-rwsr-xr-x 1 root root 12224 Oct 9 1996
/usr/bin/chsh/usr/bin
> /chsh
> chmod -s this too.
and lose ability to change shells... silly.
> >-rwsr-xr-x 1 root root 13292 Oct 9 1996 /usr/bin/chfn
> Why not ? Let''s be on the safe side. chmod -s
same as above.
>
> >-rwsr-xr-x 1 root root 20460 Oct 9 1996 /usr/bin/chage
> I also don''t have this one. What''s that for ?
changes age info in shadow file
>
> >-r-xr-sr-x 1 root tty 7140 Jun 2 1996 /usr/bin/write
> There are some ways to screw other users connection w/ write. For example,
im
> age
> someone does: cat /dev/urandom|write <someone> ... Or instead of
/dev/urandom
> he
> uses /dev/zero or even some huge file... The other user HAS to disconnect.
wrong answer - this is sgid program i.e. mesg n will fix it
>
> >-rws--x--x 1 root bin 405148 Jun 28 1996
/usr/bin/sperl5.003
> Easily exploitable. chmod -s ASAP.
wrong again. depends on which version it is.
> >-rwsr-sr-x 1 root mail 51448 Jun 15 01:14
/usr/bin/procmail
> my procmail is -s.
If it is used as a local mail delivery agent, it should be suid
>
> >-rwxr-sr-x 1 root mail 8552 Jun 15 01:14
/usr/bin/lockfile
> I also chmoded -s this one
why>
>
> >-rwsr-xr-x 1 root bin 13937 Dec 5 1995 /usr/bin/rcp
> and also this one
losing rcp functionality.
>
> >-rwsr-xr-x 1 root bin 9516 Dec 5 1995 /usr/bin/rlogin
> I chmoded 700 it. There are some dangers.
That breaks the protocol. It was fixed long time ago
> >-r-sr-xr-x 1 root bin 6856 Dec 5 1995 /usr/bin/rsh
> This one''s also chmoded 700.
Breaks the protocol.
> >-r-sr-xr-x 1 root bin 8980 Dec 5 1995
/usr/bin/traceroute
> Leave this this way, otherwise it doesn''t work
First reasonable comment
>
> >-rwsr-xr-x 1 root bin 31304 Jun 2 1996 /bin/mount
> >-rwsr-xr-x 1 root bin 17168 Jun 2 1996 /bin/umount
> Easily explotable. chmod 700.
Incorrect. Install fixes.
> >-rws--x--x 1 root root 54428 Oct 9 1996 /bin/diplogin
> >-rws--x--x 1 root bin 54428 Aug 14 1996 /sbin/dip-3.3.7o
> Dip has some bugs... chmod -s it.
Install fixes.
Alex
-----------------------------------------------------------------------------
Alex "Mr. Worf" Yuriev Nationwide ISP Bandwidth:
[www.netaxs.net ]
Net Access Outsourced News Reading: [www.newsread.com ]
alex@{netaxs.com|yuriev.com} Outsourced Shell Accounts: [shellaccounts.com]
RIP is irrelevant. Spoofing is futile. Your routes will be aggregated.
-----------------------------------------------------------------------------
In article <199709161652.MAA31468@ding.mailhub.com> you write:>[Mod: This message is a reason *why* linux-security is moderated list. This >is also a reason why Rogier, myself, Alan Cox and others really do not want >to have completely open lists that deal with security related aspects of >running a system as way too many people just jump to conclusions and give >suggestions without doing any reasearch on a subject. -- alex (co-moderator >of linux-{security|alert}@redhat.com)]Keeping the BS to a minimum is the first and last job of any moderator. Unfortunately, we need contributors to contribute better content...>> >-rwsr-xr-x 1 root bin 17196 May 22 1996 /usr/bin/at >> there are some exploits for it. I suggest you chmod -s it. >Silly advice. There were some exploits of atrun about 2 *years* ago.I object to the term "silly." Security vulnerabilties are not silly at all when you''ve got them and someone else knows about it! You can''t just dismiss problems by saying "it was a problem two years ago" and assume that it has been fixed and has *stayed* fixed. ''at'' was a problem six years ago on SunOS too, but that didn''t automatically mean it was fixed four years later on Linux, and some vendors with low computer expertise (can you say "bookstores"?) are still selling circa-1994 Linux Slackware distributions. Either *verify* that your system has a recent version of ''at'', one that has been fixed, or admit that you''re not taking all of the simple and effective security measures possible and that you''re happy with that. An administrator whose primary concern is security can just turn off all privileged executables and services, then turn them back on if and when they are needed. This is the first and easiest way to get a lot of security in a hurry. *Don''t* do this on any active machine where productivity is more important than security, because you *will* disable something important unless you know what you''re doing and make no mistakes. Don''t do this unless you *intend to learn* what components you need and which ones you can remove or replace. *Do* do this on a new machine when you are configuring it for later production use, because it''s notoriously difficult to fix problems once the system is in the field. Always allow for error--both yours and someone else''s. Two unrelated "minor" security problems can add up to a root-compromising vulnerability. You might change your system configuration in some apparently harmless way, but in fact set up preconditions for a security hole in software on your system that you''ve never heard of. New "merely theoretical" attacks become practical and effective exploit scripts in about three months. Pay attention and you can have solutions in place weeks or even years before they even become problems. What we need from resources like this mailing list is *information* that can be used to make these decisions. What was the ''at'' exploit, how do we test for it, which distributions have been fixed, and exactly what impact does disabling the ''at'' service have, anyway? We have several users who don''t even know that ''at'' exists, and wouldn''t miss it even if they did, so why is it such a big deal to disable it? Heck, why did we install it in the first place? It''s taking up 0.000089 gigs of disk space! ;-) In the case of ''crontab'', removing the setuid bit makes cron reconfiguration only available to root, but doesn''t actually disable cron for any user. This means that users can''t change their crontabs, but root can, and in any case cron continues to work. This isn''t a problem for me, my users, or my software, but it might be a problem for you, your users, or your software. Please keep that in mind and keep the biased editorial commentary to a minimum. Of course most of this information should be on web sites with references to it in the list, because nobody on this list has time to read messages nearly as long as this one. ;-) Finally, one technical error:>> >-rwsr-xr-x 1 root bin 13937 Dec 5 1995 /usr/bin/rcp >> and also this one > >losing rcp functionality.Nope. ''rcp'' calls the privileged ''rsh'' to perform the actual protocol. ''rcp'' itself doesn''t need privileges at all, and IIRC it tries to throw them away if it discovers that it has them.
Zygo Blaxell wrote:> > An administrator whose primary concern is security can just turn off all > privileged executables and services, then turn them back on if and when > they are needed. This is the first and easiest way to get a lot of > security in a hurry. *Don''t* do this on any active machine where > productivity is more important than security, because you *will* > disable something important unless you know what you''re doing and make > no mistakes. Don''t do this unless you *intend to learn* what components > you need and which ones you can remove or replace. *Do* do this on a new > machine when you are configuring it for later production use, because it''s > notoriously difficult to fix problems once the system is in the field. >Great input... As an investigator, many of the compromises I see involve systems which are 2 to 3 years old. An old slackware box sitting on a .mil domain, which some airman set up as a test machine. The airman gets trasferred, and the system is left up and running. Additionally, in the government, and in many commercial organizations as well, System Administration is more or less considered an "additional duty." The individuals know how to set up accounts, change passwords, mount filesystems, backups, etc... They know nothing about security, mailing lists, news servers, advisories, patches, etc...Unfortunately, management typically hasn''t got a clue either, and therefore holes get left unplugged. It''s good to see an occasional re-iteraton of previously reported exploits. Not everyone has been a subscriber to the linux security mailing list since its inception, and not everyone know about archives. I guess that''s why speed limit signs are posted at regular intervals. To "remind" us to obey the law. [Mod: Please qote with care. I''ve removed about 80% of the quoted text and added an atribution. -- REW] -------------------------------- Brian Koref, Special Agent, USAF Computer Crime Investigations Air Force Office of Special Investigations 4864 Virginia Ave Andrews AFB, MD 20762 (301) 981-5469 DSN: 858-5469 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzIKLx0AAAEEAJXc8Qz9I6IgQwOfO4qks+qv2AYIAZ6GJFDAEwcH2AsAPboI qQkIJm8sE6sNS9Jn39E9ucaL9WaSBvA0fL4j8RQYCoDhy5r+jriKHlhLuTGz1WmI VJmBTha9nok4TN+9wvp536Gl4nfxPjUOdW6z0dLm0X1/oP9o9YzS6wJc0rjlAAUR tCZCcmlhbiBLb3JlZiA8YmtvcmVmQHBhZm9zdTIuaHEuYWYubWlsPg==eVUD -----END PGP PUBLIC KEY BLOCK-----
> >> >-rwsr-xr-x 1 root bin 13937 Dec 5 1995 /usr/bin/rcp> >> and also this one > > > >losing rcp functionality. > > Nope. ''rcp'' calls the privileged ''rsh'' to perform the actual protocol. > ''rcp'' itself doesn''t need privileges at all, and IIRC it tries to throw > them away if it discovers that it has them. I wish. It uses rcmd(). The long term solution to this problem is to change rcmd() to call "/usr/bin/rsh" (which can easily be made a symlink to some more useful equivalent like ssh) and compile the actual rcmd() functionality into rsh itself. This is probably easier than modifying a bunch of silly programs that like to use rcmd() [rexec() should probably be treated similarly...] I''m willing to tackle this if the libc maintainers are. Alternatively, I''d be more than happy to take patches to fix rcp to call rsh. -- - David A. Holland | VINO project home page: dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino
Craig H. Rowland
1997-Sep-18 20:21 UTC
Re: [linux-security] Re: Re: Re: Security Concern..
On Thu, 18 Sep 1997, David Holland wrote:> > >> >-rwsr-xr-x 1 root bin 13937 Dec 5 1995 /usr/bin/rcp > > >> and also this one > > > > > >losing rcp functionality. > > > > Nope. ''rcp'' calls the privileged ''rsh'' to perform the actual protocol. > > ''rcp'' itself doesn''t need privileges at all, and IIRC it tries to throw > > them away if it discovers that it has them. > > I wish. It uses rcmd(). > > The long term solution to this problem is to change rcmd() to callUnfortunately this is true. I think there really are few long term solutions. The ones that come to me offhand include: - Banish all the Berkely-style r-commands altogether as they are antiques and continuous security problems. I''ve basically seen three *primary* uses for rsh, rlogin, rcp, etc. over the years of doing security audits: 1) System admins too lazy to type in their passwords between systems. 2) Users too lazy to type in their passwords between systems. 3) Hackers abusing the above to ride transitive trusts throughout a network. I think that products like SSH are a very acceptable alternative to most all of the r-commands. What amazes me the most about these commands is the frequency they are linked to system intrusion, yet virtually all OS vendors ship with them enabled. Some even go a step further and put the ''+'' in /etc/hosts.equiv for you. I would personally take my chances with a sniffer on the network grabbing my password than to have a large number of transitive trusts between hosts. It certainly is the lesser of two evils. (For the truly paranoid, you can hold down your enter key at the login: prompt for a second or two as many [not all] password sniffers drop the session after 120 or so bytes collected). - The reason rcmd() needs root privs is to make a call to rresvport() which binds the process to a privileged port before making a connection. This is to allow the antique r-commands to do part of their "authentication" based on the fact that the user is coming from reserved port number ( from BSD 4.4 source for in.rshd ): if (fromp->sin_port >= IPPORT_RESERVED || fromp->sin_port < IPPORT_RESERVED/2) { syslog(LOG_NOTICE|LOG_AUTH, "Connection from %s on illegal port %u", inet_ntoa(fromp->sin_addr), fromp->sin_port); exit(1); } Naturally, if I''m coming from a reserved port I must be an OK guy according to this check. I must be missing the point here as to why this service *needs* to have the client come from a reserved port. There certainly are no security reasons that I can think of, especially since all these commands run SUID. [ As a side note, if you see the string "Connection from <hostname> on illegal port <un-reserved port>" in your logs then you can probably bet that a person just hit your box with a port scan. All of you hackers should know by now that to do a proper port scan you should originate from a *reserved* port number, preferably port 20 (FTP-DATA channel) so you can hop many incorrectly configured packet filters ] Assuming we want to keep this poor security check in place we could change the kernel to allow the rresvport() call to bind to a port in the range of 1000-1024 without root privileges. Of course this opens up a whole new can of worms (although not as big as giving these commands SUID). Anyway...just a rant sorry for the intrusion.. -- Craig> > -- > - David A. Holland | VINO project home page: > dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino >
David Holland
1997-Sep-18 22:39 UTC
Re: [linux-security] Re: Re: Re: Re: Security Concern..
> Unfortunately this is true. I think there really are few long term> solutions. The ones that come to me offhand include: > > - Banish all the Berkely-style r-commands altogether as they are antiques > and continuous security problems. I''ve basically seen three *primary* uses > for rsh, rlogin, rcp, etc. over the years of doing security audits: Yeah, basically. Unfortunately, ssh isn''t really an adequate universal alternative until the legal problems get resolved. If they ever do. Now, I think the next release of (linux) netkit-rsh is going to have the default behavior of rlogind to ignore .rhosts and hosts_equiv entries; you''ll have to give it an option in inetd.conf to allow them. I may hack rshd so it refuses to do anything at all unless the same option is used. And, if I get time, I''m going to fix rsh so it drops to the rexec protocol (so it can ask for a password) if rcmd() doesn''t work. rexec isn''t any worse than unencrypted rlogin to my knowledge; if I''m wrong please let me know. > I would personally take my chances with a sniffer on the network grabbing > my password than to have a large number of transitive trusts between > hosts. Worse, if you can have a sniffer on your network, you can probably also have someone performing active spoofing/hijacking attacks. > Assuming we want to keep this poor security check in place we could > change the kernel to allow the rresvport() call to bind to a port in the > range of 1000-1024 without root privileges. Of course this opens up a > whole new can of worms (although not as big as giving these commands > SUID). The purpose of having the commands setuid is that since only root can bind a privileged port, the information sent by the rsh client must have been sent by root, and therefore wasn''t supplied by some random malicious user. Since rshd has no mechanism for authentication besides this, if you let anyone bind the privileged ports, anyone can pretend to be any remote user as far as rshd is concerned. This is not a good thing, because it means that ordinary users on the box who haven''t hacked root yet and don''t have physical access to the network can spoof rshd, making it even more insecure than it already is. -- - David A. Holland | VINO project home page: dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino
On Thu, 18 Sep 1997, Craig H. Rowland wrote:> I''ve basically seen three *primary* uses for rsh, rlogin, rcp, etc. over > the years of doing security audits: > > 1) System admins too lazy to type in their passwords between > systems. > 2) Users too lazy to type in their passwords between systems. > 3) Hackers abusing the above to ride transitive trusts > throughout a network.[stuff deleted]> I would personally take my chances with a sniffer on the network grabbing > my password than to have a large number of transitive trusts between > hosts. It certainly is the lesser of two evils.....and not-so-lazy sysadmins trying to make management of big networks at least partially automated. How would you apply your regular security patch to some several dozens workstations without some form of transitive trust? Apart from sysadmin tasks (software updates, backups, accounting, logins managament) there''re few other things that depend on r-commands. Good example would be various message-passing libraries (e.g. PVP, MPI, etc.) that simply won''t work without a working equivalent of rsh (such a library, or a summplimentary tool, starts several instances of a parallel job, typically on a massively parallel (super)computer or a workstation cluster. It happens non-interactively, there''s no chance for user to type in anything). Sure, with enough effort one can probably come up with a better way to do all of the above, but life is much too short to fix everything. Note, I''m arguing about the concept of trunsitive trust, not the fact that r-cmds should be used for anything. While some installations may not require any form of transitive trust some certainly do. Not to say that there''s any good reason to keep rlogind/rshd enabled when ssh can be installed. If only ssh could emulate rsh, so that one doesn''t have to keep rsh binary around to talk to less fortunate boxes... but I guess it''s a political, rather than technical, question. If not, patching ssh would be rather simple. [mod: Please people, lets put this to rest. There is no ONE way to configure a site. You get to choose between the "two evils". Some sites require protection against sniffing, others feel unhappy about the transitive trust. My experience shows that those sysops who have been able to spoof a host themselves are more afraid for transitive trust, while those that have experience sniffing are afraid for packet sniffers. Take this as a warning that for others it can be "easy" to do the thing you''re not good at. -- REW]> Naturally, if I''m coming from a reserved port I must be an OK guy > according to this check. I must be missing the point here as to why this > service *needs* to have the client come from a reserved port. There > certainly are no security reasons that I can think of, especially since > all these commands run SUID.While a connection coming from a reserved port says nothing about the originator''s good or bad intentions, it certainly says that uid=0 was involved there somewhere. Which means the guy was using r-cmd which authentificated him, and there''s a reason to believe that he''s really the one who he''s pretending to be (unless that r-cmd is buggy or guy has root anyway). If rlogind was to accept connections from any port, what''s stopping me from logging in to a remote machine as any user on the system, by compiling and using an improved version of rsh that accepts my username from the command line, rather than doing getuid()? You have to have a way to keep users honest, at least you should try. cheers, yuri
-----BEGIN PGP SIGNED MESSAGE----- On Thu, 18 Sep 1997, David Holland wrote:> > >> >-rwsr-xr-x 1 root bin 13937 Dec 5 1995 /usr/bin/rcp > > >> and also this one > > > > > >losing rcp functionality. > > > > Nope. ''rcp'' calls the privileged ''rsh'' to perform the actual protocol. > > ''rcp'' itself doesn''t need privileges at all, and IIRC it tries to throw > > them away if it discovers that it has them. > > I wish. It uses rcmd(). > > The long term solution to this problem is to change rcmd() to call > "/usr/bin/rsh" (which can easily be made a symlink to some more useful > equivalent like ssh) and compile the actual rcmd() functionality intoSalve, There is an SSLrsh build from SSLeay. Though I''ven''t tried it by now. They announce that it is validating hosts w/ certs. IMHO this seems like it would be a noticably more secure improvement over port validation and SSH as certs include more information about the host attempting to connect than public keys. Have a look at: http://www.quik.com.au/sjg/SSLrsh.html Yours Pluto /*------------------------------------------------------------------*\ Free information! Freedom through knowledge. Wisdom for all!! =:-) Key fingerprint: 1F 3F EA 94 D0 56 A6 86 4D 19 C4 56 6C F9 43 44 ----- Your todays fortune cookie ------ TAILFINS!! ... click ... ----- End of furtune ------ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAgUBNCSZdMSyBNtyYarNAQHAKQP/ZTZ/CI+6LmXxSG/O1AaTcrwCUnCZtt5R sBR5LfqxjLHxft/x9t7nvUec+zzjLuoog+kAbzZOH1JHXEGRRdG889tRFad2q6To lADdmEvlB6c5eNmm7TzOKbFUotxL/8sRgsjifl+UuCL1Zi05OgElApTqT5lfbueI +xHaQQp2zvE=jkJG -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- On Sun, 21 Sep 1997, Pluto wrote:> Have a look at: http://www.quik.com.au/sjg/SSLrsh.htmlSorry, it has to read: www.quick.com.au. Pluto /*------------------------------------------------------------------*\ Free information! Freedom through knowledge. Wisdom for all!! =:-) Key fingerprint: 1F 3F EA 94 D0 56 A6 86 4D 19 C4 56 6C F9 43 44 -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAgUBNCT/bMSyBNtyYarNAQFXmAP9Eiw6qG4OF8fJJC1X+zwc6q4izotDnDHk VyTbBRrbmNWP5d6v4cHLI3mDzTdfV/EDzASbAVE39QWTf3Uu7g3yXaEr4amqtiK2 KHq7QrGjnR8Ua4UAP5NV+CWZZeRoFurzRZ2zUi+NrQGEEPPy6fCH6tvVChb5PvhL HGxW4DwyxuU=wW0j -----END PGP SIGNATURE-----