Security Digest Volume 1 Issue 19 subject(s): 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 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 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 problem.... 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: oconnor@sccgate.scc.com 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 security@cpd.com, 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 (rigsby@ctc.contel.com) 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: oconnor@sccgate.scc.com 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: cert@SEI.CMU.EDU (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 **********************