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 #19 1989-04-17 (1 file, 2762 bytes)
NOTICE: recognises the rights of all third-party works.


Security Digest Volume 1 Issue 19


            IBM AIX 2.2 Security
            Bad VMS behavior
            Security hole in 386i login
            Security hole in 386i login

            Re:  Security hole in 386i login


Date: 17 Apr 89 09:17:04 BST (Mon)
From: Ian G Batten <uunet!!igb>
Subject: IBM AIX 2.2 Security

IBM make a lot of noise about how they've tidied up the security
implications of running Unix in their AIX release.  Those of you who
know what to do with IFS and vi to gain a root shell will be amused to
note that, although the file you create is called 'usr' rather than
'bin' it all still works just fine.


Date: Fri, 21 Apr 89 13:31:32 EST
From: Gene Spafford <uunet!!spaf>
Subject: Bad VMS behavior

I've just had report of some nasty behavior on the part of some VMS
software, and an equally bad response from DEC software folks.

First, the problem: There is at least one kernel service call that is
undocumented for user use.  This call, the EXE$GETSPI call, is
mentioned in the microfiche and many users have discovered it.  In
fact, it has been the subject of discussion recently in some of the
mailing lists.  However, the call and parameters are not intended for
casual users.

HOWEVER, once you know that the call is there, you can use it if you
know the proper parameters.  It provides useful information for
monitoring purposes.  However, if you provide the right set of
parameters, including a buffer of the wrong size, attempts to use the
call will cause VMS to crash horribly.  This is repeatable.  A 30 line
Fortran program can cause the system to go belly-up
immediately...*any* VMS system.

DEC's response: My source informs me that this has been reported to
several individuals at DEC, including through formal channels.  The
response from DEC has been "That's not a bug or a security problem.
It's an undocumented feature that users aren't supposed to use.  If
they do, the behhavior is undefined."

Obviously, the DEC folks involved don't know good design and they
don't understand what is meant by a "Denial of Service" attack.  If

the source code to exercise this bug gets out (and many people know
about it already) then there could be obvious far-reaching problems.
I sure wonder if a VMS worm with this in place were to be loosed
inside the DEC e-net if they would still claim it not to be a security

If any of you have any influence on the folks at DEC, you might try
explaining that a bug is not a feature when any user without special
privileges can use it to crash a system without warning.

I can provide further details via private mail to anyone who can
convince me that they have a legitimate need to know.


Date: 24 Apr 89
From: [email protected]
Subject: Security hole in 386i login

[ This was posted to an internet mailing list - neil ]

The login program supplied by Sun for its 386i machines accepts an argument
which bypasses authentication.  It was apparently added in order to allow

the Sun program "logintool" to do the authentication and have login do the
housekeeping.  This allows any user who discovers the new argument to the
login program to become root a couple of ways.  An example of one method is
attatched.  Our 386is are running version 4.0.1 of Sun OS (SOS).  While
awaiting a response from Sun we intend to disable logintool and patch the
login binary using the "strings" and "adb" method made famous last November.
        We do not have access to SOS source code and ran across this while
attempting to identify another bug in "logintool".

        I have sent messages containing more or less the same information
as contained above to the security mailing list (4/10 1808 EDT) and to the
cert mailbox (4/11 1441 EDT).  I have yet to receive a response of any kind.
I must admit, I was expecting at least an ACK, if not a RTFM.

[ I can't find any postings about this sent to [email protected],
  perhaps the mail was lost? - neil ]

        Has this been reported before?  Should I have mailed to different
mboxes?  Am I out in left field?  Come in Rangoon, over.

ps:  Mike Rigsby ([email protected]) tells me that at a 386i SOS
     administration class he attended, he was informed that this access path
     was a design feature put in for forgetful administrators but that the

     class was told to keep it a secret.  I find this surprising, if true,
     since this is the OS that Sun claims "meets the spirit of C2
     specifications."  Then again, maybe I understand even less of the C2
     specs than I thought I did.


Date: 24 Apr 89
From: [email protected]
Subject: Security hole in 386i login

[ This was also posted to an internet mailing list - neil ]

        I composed my last message by editing a copy of the message I had
sent to the CERT.  I forgot to delete the sentence that referred to an
example.  I intentionally did not include the example in the general mailing.
        Since sending the last message I broke down and phoned the CERT,
something I probably should have done in the first place.  They have
asked me to not give out the argument to login and to refer callers to
the CERT (412-268-7090).


Date: 24 Apr 89
From: [email protected] (CERT)
Subject: Re:  Security hole in 386i login

[ This was also posted to an internet mailing list - neil ]

Your mail did cause us to start telephoning Sun in order to get them working on
the problem.  We have made progress with Sun in the security area.  They have
reported that an offical fix will be available in another day or two.

There is another quick fix that we have been suggesting callers try.  Instead
of using adb on login, just change the protections to 2750 which removes
access to it from users.

Software Engineering Institute / Computer Emergency Response Team

        End of Security Digest Volume 1 Issue 19