Very Computer

Just was about to update my shadow programs (compiling the shadow-mk
package by Mohan Kokal, which is the 3.3.2 sources), when before the
install I noticed something funny.

Here's the snippet from the Makefile where login is installed:

        install -m4755 login $(LOGINDIR)/_login
        install -m4711 login.secure $(LOGINDIR)/login

Hm, seems that login in installed as _login, and another binary,
login.secure is installed as login. What's funny is, the package has
no sources for login.secure.  This binary was never in the
shadow-3.n.n packages, and in this package is never referred to in
any README's.
So how secure can it be that there are no sources.
Just asking.

Sagittarius(tty2):/usr/src/shadow-mk> ls -la log*
-rw-r--r--   1 root     staff        2381 Jun 28 04:44 log.c
-rw-------   1 root     staff         793 Sep  1 15:04 log.o
-rwx--x--x   1 root     staff       27792 Sep  1 15:05 login
-rw-r--r--   1 root     staff        3351 Jun 28 04:44 login.1
-rw-r--r--   1 root     staff       14568 Sep 17  1993 login.5
-rw-r--r--   1 root     staff        3264 Sep 17  1993 login.c
-rw-r--r--   1 root     staff        5324 Jul 13 09:12 login.defs
-rw-------   1 root     staff        1555 Sep  1 15:04 login.o
-rws--x--x   1 root     staff        1124 Jul 13 10:36 login.secure <- ?
-rwx--x--x   1 root     staff        3988 Sep  1 15:09 logoutd
-rw-r--r--   1 root     staff        1009 Sep  1 13:36 logoutd.8
-rw-r--r--   1 root     staff        5399 Sep 17  1993 logoutd.c
-rw-------   1 root     staff        2185 Sep  1 15:09 logoutd.o

I would advice anyone that has installed this package to remove it.

I have received an email from someone who also noticed the
installation of the login.secure binary, for which no source is
provided.
In his correspondence with the author of this package, that author,
in his helpfulness, asked for a temporary account on his machine, and
having been denied that, asked for the password file. The emailer
also told me he has observed the author of this package to be
bragging about violating computer security.

Quote:>Ok, I will now follow up on my earlier post about the shadow-mk
>package.
>I would advice anyone that has installed this package to remove it.

Quote:>I have received an email from someone who also noticed the
>installation of the login.secure binary, for which no source is
>provided.

I will also post the version of GCC with which is was compiled, the version
of libc with which it was compiled, and the compilation flags, so that
each person make verify that it is indeed the source from which that
binary was created.  I will also have Mohan Kokal include the source in
future versions of the shadow-mk package.

In the meantime, I will detail how my patch works, and how it closes the
now well known hole:

My patch simply forces all argv[] elements beginning with a - to be no
longer than 2 characters long, by writing a 0 into the third position
after the dash.  Thus, if a user tries login -froot, the "r" in root
would be overwritten, and the remainder, "oot", would be affectively
truncated.

Furthermore, my patch addresses another security issue, the misuse of
the semi-documented -h switch, by disallowing anyone with a real uid greater
than 100 from using it.

Once all paramters have been patched, and the absence of -h is assured if
UID>100, all parameters are passed to an unmodified /bin/_login.

Again, as I said, the source will be posted later this evening, along with
GCC version, libc version, optimization flags, and so on.

Quote:>In his correspondence with the author of this package, that author,
>in his helpfulness, asked for a temporary account on his machine, and
>having been denied that, asked for the password file. The emailer
>also told me he has observed the author of this package to be
>bragging about violating computer security.

Furthermore, "bragging about violating computer security" may be something
as simple as "whoa... on an older Linux box, I noticed a hole in crontab
that allowed such and such..."  or "yeah, I used rlogin to gain root--that
old /bin/login was a joke."

I, as well as some others, I am certain, would like to see a factual basis
for this outright character assassination that you are making.  I have no
reason to doubt that you may be able to support your statements.  However,
I also have NO reason whatsoever to believe any of your closing statements.

--Joseph R. M. Zbiciak
  Systems Administrator & Programmer
  Texas Networking Systems, Inc.

                                                :- - cegt201.bradley.edu - -:
                                                : -  camelot.bradley.edu  - :
           If it works, Don't fix it.           :-Finger for PGP Public Key-:
                                                :======= DISCLAIMER: =======:
                                                :    He flamed me first!    :
                                                +---------------------------+

Quote:>Ok, I will now follow up on my earlier post about the shadow-mk
>package.
>I would advice anyone that has installed this package to remove it.

Quote:>I have received an email from someone who also noticed the
>installation of the login.secure binary, for which no source is
>provided.

I will also post the version of GCC with which is was compiled, the version
of libc with which it was compiled, and the compilation flags, so that
each person make verify that it is indeed the source from which that
binary was created.  I will also have Mohan Kokal include the source in
future versions of the shadow-mk package.

In the meantime, I will detail how my patch works, and how it closes the
now well known hole:

My patch simply forces all argv[] elements beginning with a - to be no
longer than 2 characters long, by writing a 0 into the third position
after the dash.  Thus, if a user tries login -froot, the "r" in root
would be overwritten, and the remainder, "oot", would be affectively
truncated.

Furthermore, my patch addresses another security issue, the misuse of
the semi-documented -h switch, by disallowing anyone with a real uid greater
than 100 from using it.

Once all paramters have been patched, and the absence of -h is assured if
UID>100, all parameters are passed to an unmodified /bin/_login.

The new /bin/login is statically linked, using maximum optimizations,
and is stripped, to make the smallest possible binary.

Again, as I said, the source will be posted later this evening, along with
GCC version, libc version, optimization flags, and so on.

Quote:>In his correspondence with the author of this package, that author,
>in his helpfulness, asked for a temporary account on his machine, and
>having been denied that, asked for the password file. The emailer
>also told me he has observed the author of this package to be
>bragging about violating computer security.

Furthermore, "bragging about violating computer security" may be something
as simple as "whoa... on an older Linux box, I noticed a hole in crontab
that allowed such and such..."  or "yeah, I used rlogin to gain root--that
old /bin/login was a joke."

I, as well as some others, I am certain, would like to see a factual basis
for this outright character assassination that you are making.  I have no
reason to doubt that you may be able to support your statements.  However,
I also have NO reason whatsoever to believe any of your closing statements.

--Joseph R. M. Zbiciak, System Administrator, Texas Networking Systems, Inc.

                                                :- - cegt201.bradley.edu - -:
                                                : -  camelot.bradley.edu  - :
           If it works, Don't fix it.           :-Finger for PGP Public Key-:
                                                :======= DISCLAIMER: =======:
                                                :    He flamed me first!    :
                                                +---------------------------+

-----BEGIN PGP SIGNED MESSAGE-----

This post is in regards to the login.secure program included in
the shadow-mk package authored by Mohan Kokal.  I, Joseph R.M. Zbiciak,
am the sole author of this program, and would like to dispell any
rumors labeling it as the tool of a "cracker."

Included in this post is the source code for my /bin/login replacement.

The binary included in the shadow-mk package distributed by Mohan Kokal
was apparently compiled under GCC 2.4.5, using libc 4.4.4.  I base this
statement on the fact that the binary was indeed compiled by me on my
personal Linux box, "asylum," prior to June 9th.  On June 9th, I upgraded
to GCC 2.5.8, and libc 4.5.26.

Inspection of the login.secure binary will reveal that it was indeed
linked with libc 4.4.4.  

Therefore, I seek corroboration of the following, since I cannot
do this myself (my system has no room to dl libc 4.4.4 and gcc 2.4.5 to
try this):

The login.secure binary was most probably compiled as follows:

gcc -o login.secure -s -N -O6 -fomit-frame-pointer -m386 login1.c

(as I said, under GCC 2.4.5, and libc 4.4.4)

Using GCC 2.5.8 and libc 4.5.26 yeilds an executable of 1328 bytes
with these options.  

Let me remind you that the /bin/login on my system has been and continues
to be the login.secure binary that was included in shadow-mk.  (Size:
1124 bytes.  CRC: a4abbb26)

I have PGP-signed this post to ensure its authenticity.  My public key

Pipe the output to a file and run pgp -ka on the file to add the key
to your keyring.  This key is primarily for private messages.  I do not
yet have a well established key for business use.  One will be forthcoming.

Please:  I urge *ANYONE* that has any questions, problems, etc. relating
this program to CONTACT ME IMMEDIATELY.  My email address is, once again,



instructions to forward the mail to me.

And again:  I do apologize for any inconvenience this may have caused
anyone.  The shadow-mk package is not insecure.  The login.secure is
indeed what it was titled.  I do hope that this post lays to rest any
suspicion about the shadow-mk package, its contents, and its author.
I also apologize to Mohan Kokal for not realizing that such a small piece
of code would cause such a large number of people to label him as a
cheap-and-dirty cracker.  

Here's the source code:

==FILE: login1.c==
/* Preprocessor for /bin/login                    */
/* Corrects /bin/login security hole regarding -f */
/* Also disables -h for non-root users.           */
/* (c) 1994, Joseph R. M. Zbiciak                 */

#include <strings.h>
#include <unistd.h>
#include <stdio.h>

main (int argc, char * argv[], char * envp[])
{
        char **av=argv;
        int ac=argc;

        if (argc>1) {
                while(--ac>0) {
                        if (**(++av)=='-' && strlen(*av)>1) {
                                 *((*av)+2)=0;
                                 if (*((*av)+1)=='h' && getuid()>100) {
                                        fprintf(stderr,"You cannot specify a new host.\n");
                                        exit (1);
                                 }
                        }
                }
        }

        execve("/bin/_login",argv,envp);
        return 0;

Quote:}

- --Joseph R.M. Zbiciak
  Systems Administrator & Programmer
  Texas Networking Systems, Inc.

DISCLAIMER:  Neither this post, nor any other post made by me, reflects
             the opinions of my various employers, unless EXPLICITLY
             stated.  All opinions stated herein are mine unless otherwise
             noted.

                                                :- - cegt201.bradley.edu - -:
           If it works, Don't fix it.           : -  camelot.bradley.edu  - :
                                                :-Finger for PGP Public Key-:
                                                :===========================:

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLmwUH/1glWhKqKRRAQHCAgP6AqTd3G9kzRm12GqiE29aL1VHjkYxb/hU
FW4F0+TEIM7RbUcbfFPilwtnb2n08btgcLW+92YZRGf4FmzteVLEMhecz/+wB9Wd
/Dr8rH5rUrJw2Lclx7ZmiLDLfBVHLahcRNQ/oH/itLg9UJXLzLKq8igEniIpyxgW
LevHNAnbWgM=
=VIIl
-----END PGP SIGNATURE-----

--
************************* Patrick Reijnen *************************
* Department of Computer Science, Catholic University of Nijmegen *

* WWW:    http://{atlas,zeus}.cs.kun.nl:4080/homepage.html        *

--
   O_   ---- Peter Dalgaard
  c/ /'  --- Dept. of Biostatistics
 ( ) \( ) -- University of Copenhagen

Indeed on "asylum," my personal box, /bin/_login has permissions
of 4500.

I will investigate this situation further.

--Joseph R.M. Zbiciak
  Systems Admintrator & Programmer
  Texas Networking Systems, Inc

DISCLAIMER:  Neither this post, nor any other post made by me, reflects
             the opinions of my various employers, unless EXPLICITLY
             stated.  All opinions stated herein are mine unless otherwise
             noted.

                                                :- - cegt201.bradley.edu - -:
           If it works, Don't fix it.           : -  camelot.bradley.edu  - :
                                                :-Finger for PGP Public Key-:
                                                :===========================:

Let me just say something LOUD AND CLEAR: I do *NOT* believe that you have any
reason to apologize to anyone. There was a sad misunderstanding here; with the
ever-present threat of viruses, trojan horses, and what not, people have a
good reason to be concerned; but all YOU did was provide the result of your
labors for all of us to use and enjoy, for which the least that you deserve is
our thanks. There is absolutely no reason for you to feel guilty when you have
contributed good code to the public domain.

I do not believe that the original poster has any reason to feel guilty
either. He did the right thing; posted a warning to all of us when there was
reason to believe that code with ill-intent was circulating and executing
regularly on our machines with root privileges. Unfortunately, no matter how
tactful you are, this is something that's very difficult to do without
implicating the author of the code in question.

So anyways, all I meant to say (since it appears nobody else said it) is that
you should both be thanked by the rest of us.

Viktor

Quote:>>>>>    install -m4755 login $(LOGINDIR)/_login
>>nothing is keeping users from just typing /bin/_login -froot,
>>and exploit the original security hole.... (Permissions should
>>be 744 or something like that)

Quote:>This is indeed a valid question.  The correct permissions for
>/bin/_login should be either 4500 or 0500, not 4755.  I spoke

Quote:>I will investigate this situation further.

The incorrect permissions on /bin/_login were due to a mixup when
updating the shadow-mk package's Makefile to correspond to the
Makefile from the other shadow release.  

** The 4755 perms do not appear present a security risk, however. **

The original /bin/login will deny any logged in user from using
the -f (username) option if they lack sufficient privledge.  Period.
Indeed, the only reason -froot was a problem was that /bin/login
determined that the "active user" calling /bin/login was indeed root
and therefore had permission to use the -f switch.  Any user, once
logged in, cannot use the -f option unless that user is indeed root.

For those persons interested in verifying this statement, log in
as a regular user and type "/bin/login -f root" or "/bin/login -froot"
and see what happens.  You'll not become root.  The problem was in
rlogin and console logins, where /bin/login was being invoked by
root itself, rather than being invoked as suid-root.  Apparently, the
old /bin/login uses getuid() instead of geteuid() to determine the
real user id of the user executing the program.

--Joseph R.M. Zbiciak
  Systems Administrator & Programmer
  Texas Networking Systems, Inc.

DISCLAIMER:  Neither this post, nor any other post made by me, reflects
             the opinions of my various employers, unless EXPLICITLY
             stated.  All opinions stated herein are mine unless otherwise
             noted.

                                          :- - cegt201.bradley.edu - -:
        If it works, Don't fix it.        : -  camelot.bradley.edu  - :
                                          :-Finger for PGP Public Key-:
                                          :===========================:

In fact, I make sure that such binaries are at world-readable.  It makes
it so much easier to make a system snapshot to install on other systems
(truly private files, like the ones that contain login passwords for PPP
uplinks, are unreadable to unprivileged users and as such do not become
part of the snapshot when the snapshot is made by non-root).

(other ravings involving patching a billion Makefiles so that system
binaries are world-readable deleted)

Anyway, owner root/mode 4500 binaries are humorous.  How are you
expected to run the thing unless you're already root to begin with, in
which case, why do you need setuid?  Silly.

Peeves aside, there shouldn't be anything wrong with mode 4755 provided
that login does a few sanity checks based on the real user ID
(getuid()), although I do see problems with having a setuid binary
world-executable (so mode 4744 then).  I'm personally a member of the
camp that only root should be able to run login, so I make it mode 755
(world-readable, no setuid, and if anyone other that root tries to run
it it does nothing useful).