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 #7 1989-02-08 (1 file, 2687 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/107.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Wed, 8 Feb 89 12:20:56 PST
Subject: Security Digest V1 #7

Security Digest Volume 1 Issue 7

subject(s):

            security alert AIX/RT 2.2.1
            lock(1) nonsense
            security idea: make lost+found drwx------
            Re: your mail
            end of digest marker

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

Date: Tue, 7 Feb 89 21:24:19 CST
From: uunet!texbell!moray!siswat!buck
Subject: security alert AIX/RT 2.2.1

Summary:

        The distribution disks for IBM's AIX/RT 2.2.1 implement
        a new shadow password file, but leave the newly
        generated password file, /etc/security/passwd,
        with -rw-rw-rw- permission.

Background:

AIX 2.2.0 had some interesting security aspects.  Root could login
at any terminal, instead of just the console, so anyone can mount
an attack at any terminal.  There is a record made of failed logins,
but since it records every failure on any account, it spits out the
same message every time root logs in, so I end up ignoring it.
Also, most of the system accounts (su, sys, adm) were delivered with
a "*" password field.  Under other System V's I have worked with,
this was an impossible password, but under AIX this means use the
same password as root.  So break one, you've broken them all.

The AIX 2.2.1 distribution automatically converts to the new shadow
password scheme, with all password fields in /etc/passwd becoming "!"
and the real passwords in /etc/security/passwd.  Running the password
command leaves the open permissions on /etc/security/passwd, but
generates /etc/security/opasswd with -rw-------.  Also, the /etc/security
directory is completely unprotected.  Why would a security directory
be delivered as anything other than drwx------?  And root can still
login from any terminal.

Don't hold your breath for IBM to correct this, if their normal
update policy is any guide.  IBM does not supply ANY updates for
AIX/RT.  We beat our heads against the wall for some time with
something that obviously violated the manual.  When we finally
called for support, we found out we were 22 minor revisions back
from the latest update to 2.2.0, but IBM does not notify customers
of bug fixes.  Everyone gets to rediscover these bugs for themselves
until 2.2.1 comes out.  And now that 2.2.1 has shipped, who knows
when they will send out unsolicited updates?  Of course, IBM only
distributes on floppies (34 1.2M floppies are what we received for
the full 2.2.1 release, with a slow floppy drive, on a $30K (list)
workstation), so updates are a major hassle at both ends.
I can hardly wait for X windows...

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

Date: Wed, 8 Feb 89 03:12:26 -0500
From: vsi!friedl
Subject: lock(1) nonsense

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

Back in school, our lock program would always take the root
password to unlock it, and if the user said "lock me", his/her
account's password was used rather than prompting for a new one.
This seems like a much more reasonable approach...

I'll see if I can track down our old lock and post it.

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

Date: Wed, 8 Feb 89 03:12:28 -0500
From: vsi!friedl
Subject: security idea: make lost+found drwx------

Hi folks,

     I'd like to bounce this off the rest of the list.  I suggest
that all lost+found directories should be readable only by root
as a security precaution.  It seems to me that if I have a
readable file under a secure directory and it gets detached from
the directory entry, it will be readable to everybody if fsck
picks it off the floor.  Certainly, protecting the file itself is
a good idea, but some people could be in for a surprise if their
love.letters directory gets skrunched :-).

     Any feedback on this?

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

Date: Wed, 8 Feb 89 0:23:29 EST
From: felix!wb3ffv.ampr.org!howardl (Howard Leadmon - WB3FFV)
Subject: Re: your mail

 In a recent posting to the list somebody mentioned that they were disturbed
with everybody saying they have found a bug (security problem) but were not
going to mention it. I can kind of agree with the sender, as this is suposed
to be a list restricted to certified administrators, and we NEED to know of
problems (and how they can be exploited) so we can avoid them, or atleast
take action to reduce the probability of damage to our systems. If they feel
sending somthing like this through Email is too easily intercepted, then we
should probably have this information released but send using some encription
method (like DES) so the common Email peekers do have a chance to read the
passing mail. Just a though for what it is worth, as I am sure this bothers
many...

[ It seems to me that a number of "sensitive" postings have gone out in
the previous digests.  I am checking to see if there is a mail problem
with material sent to howardl.  Do people want material sent out
encrypted?  Send your votes to security-request and I will tabulate them.
I doubt that it is practical, though, since some recipients are outside
of the US, and most recipients would not want to bother with it. - neil ]

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

Date: Wed Feb  8 11:28:23 PST 1989
From: security-request
Subject: end of digest marker

[ Someone pointed out that mail is sometimes truncated, so I am putting
and end of digest marker in every digest.  That is also the reason that
I am putting another digest out so soon after the last one (so that I
can test the change now). - neil ]

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

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

END OF DOCUMENT