What is login.secure from shadow-mk package?

What is login.secure from shadow-mk package?

Post by bjdou » Sat, 03 Sep 1994 10:43:57



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


 
 
 

What is login.secure from shadow-mk package?

Post by Bauke Jan Dou » Sun, 04 Sep 1994 23:19:51



>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



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.

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.



 
 
 

What is login.secure from shadow-mk package?

Post by Joe Zbici » Wed, 07 Sep 1994 13:22:34




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

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

>>So how secure can it be that there are no sources.
>>Just asking.

I apologize.  I am the author of the /bin/login replacement that is included
in the shadow-mk package.  Mohan Kokal, the author of the shadow-mk package,
is not to blame.  I had asked him not to distribute my (ugly) source.  :-)

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.

This is not necessary.  The source for the binary in question will be
posted later this evening.  I need to return to my linux box in order
to upload it.  I do not have it readily available at the moment.

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 post the source to the /bin/login replacement that I wrote, and trust
on my own system.  I did not realize that the net would grow so suspicious.
I should have known better.  :-)  After all, it could be snake oil, for
all the net knows.  I realize now, especially after reading the files
focusing on security issues that were included with PGP, that it is *very*
important to make the source available to public scrutiny.  Indeed, for
similar reasons, I do not trust Clipper encryption (aside from the gov't
back-door).

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.

To whom are you referring?  Mohan Kokal may have a number of accounts on
various Linux boxes, for various reasons.  If you are referring to one
of these accounts, please make known the people involved, as well as
circumstances in greater detail than you have.  This is an accusatory
statement based on heresay and circumstantial evidence.

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!    :
                                                +---------------------------+

 
 
 

What is login.secure from shadow-mk package?

Post by Joe Zbici » Wed, 07 Sep 1994 14:08:56




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

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

>>So how secure can it be that there are no sources.
>>Just asking.

I apologize.  I am the author of the /bin/login replacement that is included
in the shadow-mk package.  Mohan Kokal, the author of the shadow-mk package,
is not to blame.  I had asked him not to distribute my (ugly) source.  :-)

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.

This is not necessary.  The source for the binary in question will be
posted later this evening.  I need to return to my linux box in order
to upload it.  I do not have it readily available at the moment.

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 post the source to the /bin/login replacement that I wrote, and trust
on my own system.  I did not realize that the net would grow so suspicious.
I should have known better.  :-)  After all, it could be snake oil, for
all the net knows.  I realize now, especially after reading the files
focusing on security issues that were included with PGP, that it is *very*
important to make the source available to public scrutiny.  Indeed, for
similar reasons, I do not trust Clipper encryption (aside from the gov't
back-door).

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.

To whom are you referring?  Mohan Kokal may have a number of accounts on
various Linux boxes, for various reasons.  If you are referring to one
of these accounts, please make known the circumstances in greater detail
than you have.  This is an accusatory statement based on heresay and
circumstantial evidence.

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!    :
                                                +---------------------------+

 
 
 

What is login.secure from shadow-mk package?

Post by Joe Zbici » Wed, 07 Sep 1994 16:10:30


-----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:}

==END OF FILE==

- --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-----

 
 
 

What is login.secure from shadow-mk package?

Post by Patrick Reijn » Wed, 07 Sep 1994 20:29:27



>-----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.  

Hmm, some people just over react a bit every now and then. Don't bother..

- Show quoted text -

>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;
>}
>==END OF FILE==
>- --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

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

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

 
 
 

What is login.secure from shadow-mk package?

Post by Peter Dalgaard S » Thu, 08 Sep 1994 01:24:09





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

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

>>>So how secure can it be that there are no sources.
>>>Just asking.
>I apologize.  I am the author of the /bin/login replacement that is included
>in the shadow-mk package.  Mohan Kokal, the author of the shadow-mk package,
>is not to blame.  I had asked him not to distribute my (ugly) source.  :-)

This seem to settle that login.secure is indeed completely
innocent. HOWEVER: May I ask a stupid question? Why is the
original login being installed setuid? As far as I can see,
nothing is keeping users from just typing /bin/_login -froot,
and exploit the original security hole.... (Permissions should
be 744 or something like that)

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

 
 
 

What is login.secure from shadow-mk package?

Post by Joe Zbici » Thu, 08 Sep 1994 02:25:17






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

>>>>        install -m4755 login $(LOGINDIR)/_login
>This seem to settle that login.secure is indeed completely
>innocent. HOWEVER: May I ask a stupid question? Why is the
>original login being installed setuid? As far as I can see,
>nothing is keeping users from just typing /bin/_login -froot,
>and exploit the original security hole.... (Permissions should
>be 744 or something like that)

This is indeed a valid question.  The correct permissions for
/bin/_login should be either 4500 or 0500, not 4755.  I spoke
with Mohan just now, and he seems to think that later in the
install, the permissions on /bin/_login get fixed.  The reason
for having them set 4755 at the start is that in case /bin/login
goes caputz, one is still able to rescue the original /bin/login
to rectify the situation.

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-:
                                                :===========================:

 
 
 

What is login.secure from shadow-mk package?

Post by Viktor T. To » Wed, 07 Sep 1994 21:31:08



>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.  

I have been reading this thread with great interest; first, I became (as did
many others) concerned about the possibility that code was distributed with
ill intent (even though I am not presently a user of the shadow-mk package);
later, I was simply curious as to the resolution of this.

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

 
 
 

What is login.secure from shadow-mk package?

Post by Joe Zbici » Thu, 08 Sep 1994 07:26:40



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)

[snip]

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

[snip]

Quote:>I will investigate this situation further.

Here are the results of my investigation:  

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-:
                                          :===========================:

 
 
 

What is login.secure from shadow-mk package?

Post by Zygo Blaxe » Fri, 09 Sep 1994 13:28:16




>This is indeed a valid question.  The correct permissions for
>/bin/_login should be either 4500 or 0500, not 4755.  I spoke
>with Mohan just now, and he seems to think that later in the
>install, the permissions on /bin/_login get fixed.  The reason
>for having them set 4755 at the start is that in case /bin/login
>goes caputz, one is still able to rescue the original /bin/login
>to rectify the situation.

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

Ummm...why?  What difference does it make that users other than root can
read the login binary?  Is security somehow compromised?  If so, then as
a hacker I would just download the sources and figure out where the hole
is.

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).

 
 
 

1. WARNING about shadow-mk package

If you are about to update you shadow programs with the shadow-mk
package by Mohan Kokal, think again.

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

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

It appears that login is installed as _login, and another binary,
login.secure is installed as login.
This package has no sources for login.secure!
Login.secure was never in the original shadow-3.n.n packages by John
F. Haugh, and in this package is nowhere referred to.

Sagittarius(tty2):/usr/src/shadow-mk> ls -la login*
-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 <- ?

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

Of those that have already emailed me on this, one person told me in
his correspondence with the author of this package (Mohan Kokal) 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 this author to be bragging
about violating computer security.


2. Sr. UNIX sys. admin. (Permanent-San Diego)

3. ATI Radeon 9000

4. HZ variable in shadow-mk login.defs

5. shUnit (and request for help)

6. Where to get shadow-mk??

7. 'unknown host' error after install of Ximian Desktop

8. Shadow-mk, cfingerd & lastlog :'-(

9. xdm and shadow-mk

10. Shadow-mk: wu.ftpd no longer works

11. Shadow package 'login' and backspace...

12. Shadow package from sunsite (shadow'd passwords)