obrennan@CC3.CC.UMR.EDU (obrennan) (06/28/90)
As an opinion: I appreciate receiving information about security problems with the Apollos. What I don't appreciate is having to obtain this type of information from a PUBLIC list that has many more users than just Apollo administrators. HP should be alerting customers when serious security problems exist!!! Unfortunately, I have not seen any alert bulletins to Apollo administrators. Since HP ALERT is not available others feel it necessary to post the information to this list, which I again dislike because it becomes a HACKER alert as well as an administrator alert. Also, what if a particular administrator is NOT on this list; we have just opened up a security problem (unknown to the administrator) for that site. If we have a concern, we should inform the other administrators as to Apollo Problem number to question the hotline about (I presume that they will allow customers to query a problem entry) or some other means of the like. Again, thanks for the info, but lets post it such that only Apollo administrators can obtain the details. Gerry O'Brennan Computing Services University of Missouri - Rolla ------------------------------ obrennan@apollo.cc.umr.edu c0022@umrvmb.umr.edu ------------------------------
Jacques_Gelinas@CMR001.BITNET (06/28/90)
> Again, thanks for the info, but lets post it such that only > Apollo administrators can obtain the details. NO! I feel compelled, as a simple user, to respond to this. Here is a true story. Back in 1976, the ADP director at RMC (Royal Military College) had all the WATFOR manuals expuged of the flag (pages=n) on the $JOB card to keep students from using too much paper. But when i transferred from RMC to CMR (College Militaire Royal) in 1979, i found with surprise that all the $JOB flags were explained at great length, in french, on the wall. Year after year, 150 students transfer from CMR to RMC!! The moral of this story is: You can control your own installation by removing/hiding information, but if this information is avalaible elsewhere, watch out. In ny own modest opinion, the only effective procedure to have security problems such as this rendered harmless is to post them on the wall... (By the way, if you trust the standard Unix password encryption and have not heard of the Cryptbreaker workbench, you are just like this RMC ADP director, hiding your head in the sand (:-))
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (06/28/90)
Actually I have heard very little about the Cryptbreaker workbench. Can someone elaborate on this? I don't see much that an average system administrator can do about Unix password encryption since the *&^%!!! system puts the ^%%HASD&^%%%!!! passwords in a file which *MUST* be publicly readable ... it's things like this that make me *HATE* Unix. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
obrennan@CC3.CC.UMR.EDU (obrennan) (06/28/90)
NO! I feel compelled, as a simple user, to respond to this. Here is a true story. Back in 1976, the ADP director at RMC (Royal Military College) had all the WATFOR manuals expuged of the flag (pages=n) on the $JOB card to keep students from using too much paper. But when i transferred from RMC to CMR (College Militaire Royal) in 1979, i found with surprise that all the $JOB flags were explained at great length, in french, on the wall. Year after year, 150 students transfer from CMR to RMC!! The moral of this story is: You can control your own installation by removing/hiding information, but if this information is avalaible elsewhere, watch out. In ny own modest opinion, the only effective procedure to have security problems such as this rendered harmless is to post them on the wall... (By the way, if you trust the standard Unix password encryption and have not heard of the Cryptbreaker workbench, you are just like this RMC ADP director, hiding your head in the sand (:-)) Is this to imply that because there are some inherent security problems that can't be alleviated that we tell of all of the other problems? Some security breaks take effort while others don't. The security problems that don't take effort will invite many more to the party who just want to see what is happening at the party and will inadvertantally get in trouble. The above thinking is in lines with "Because someone CAN break into my house I might as well give them the keys". By the way, with announcing the info to the list you are ALSO giving away the keys to others houses. I still think that the information can be just as helpful by opening up a problem report with Apollo and announcing that problem report # so that other administrators can query Apollo about it without exposing the network. Also, what is the liability of a person for publicly exposing this information? What if millions of dollars are lost because of the posting of the information? Gerry O'Brennan Computing Services University of Missouri - Rolla ------------------------------ obrennan@apollo.cc.umr.edu c0022@umrvmb.umr.edu ------------------------------
rees@dabo.ifs.umich.edu (Jim Rees) (06/28/90)
In article <9006281331.AA07122@richter.mit.edu>, krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: Actually I have heard very little about the Cryptbreaker workbench. Can someone elaborate on this? I may be confused, but I thought that CBW was intended for breaking the crypt command, not the crypt call. The crypt command uses a one-rotor enigma and has never been considered cryptologically secure, at least not since the Nazis used it (enigma, not unix) in WWII. The crypt call uses DES, and as far as I know, DES is still considered secure in the sense that the only known practical attack is brute-force. U.S. law prohibits the export of encryption "devices," including software, without a license, so unix systems intended for export usually have the crypt command removed. Interestingly enough, if you cripple DES such that it becomes one-way only, it is no longer considered an encryption device and may be freely exported. So you have the bizarre situation that the high-tech, secure crypt(3) is OK but the low-tech, insecure crypt(1) is restricted. I don't see much that an average system administrator can do about Unix password encryption since the *&^%!!! system puts the ^%%HASD&^%%%!!! passwords in a file which *MUST* be publicly readable ... it's things like this that make me *HATE* Unix. I think the rationale is that you shouldn't depend on hiding passwords for security, and that making the password file world readable forces you to use a secure encryption method instead. I agree that this is a pain and should be changed.
ericb@CAEN.ENGIN.UMICH.EDU (Eric Bratton) (06/29/90)
I have made our modified inprot template available for anonymous ftp. I hope that others will be able to see what we have done with the Apollo supplied (and slightly incomplete) inprot template and use this as a model for their own environment. I also wouldn't mind any helpful suggestions or discussions about improving Apollo file system security. It is available from freebie.engin.umich.edu (35.2.68.23) as the file pub/inprot.os.sr10.2. Use this template at your own risk, as we have modified other system files (such as netman.bin_sh) to work with the tighter ACLs. Quick security tip to sysadmins: Check your "default" passwords. *-----------------------------------------------------------------* | Eric Bratton | The University of Michigan, Inc | | ericb@caen.engin.umich.edu | #include <std.disclaimers> | *-----------------------------------------------------------------*
root@VLSI-MENTOR.JPL.NASA.GOV (The vlsi-mentor Super User) (06/29/90)
> I don't see much that an average system administrator can do > about Unix password encryption since the *&^%!!! system puts > the ^%%HASD&^%%%!!! passwords in a file which *MUST* be publicly > readable ... it's things like this that make me *HATE* Unix. Yea, but not APOLLO. If you keep your rgyds DOWN, nothing can access the /etc/passwd file. :) BTW, I believe security holes should be broadcast over the net. This way, they *will* get fixed, and security based upon hidden information is not secure. ---- Dave Hayes dave@vlsi-mentor.jpl.nasa.gov dave%vlsi-mentor@jpl-mil.jpl.nasa.gov "The word 'choice' is a fraud when one is taught what to choose."
pphillip@cs.ubc.ca (Peter Phillips) (06/29/90)
In article <1990Jun28.144947.13139@terminator.cc.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >In article <9006281331.AA07122@richter.mit.edu>, >krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: ...[ stuff about CBW deleted ]... > > I don't see much that an average > system administrator can do about Unix password encryption since > the *&^%!!! system puts the ^%%HASD&^%%%!!! passwords in a file > which *MUST* be publicly readable ... it's things like this that > make me *HATE* Unix. > >I think the rationale is that you shouldn't depend on hiding passwords for >security, and that making the password file world readable forces you to use >a secure encryption method instead. I agree that this is a pain and should >be changed. World readable or not, you had better use a secure encryption method. The password file might not be readable but that doesn't mean the contents are inivisible to everyone. A bug in the OS might inadvertantly allow users to trivially read the contents. Or, a piece of paper containing password information might be found in a dumpster. Or perhaps the paging system can be manipulated to look at files. Who knows? If the method of encryption isn't secure enough then the system isn't secure regardless of the permissions on the password file. The real problem is users who pick poor passwords. Having a world readable password file does make it easier for a cracker to do high-speed automated guessing but hiding the file doesn't prevent guessing, it just slows it down a bit. Check out alt.security for some good discussions of the pros and cons of hiding the password file. --- Peter Phillips, UBC Computer Science, <pphillip@cs.ubc.ca>
obrennan@CC3.CC.UMR.EDU (obrennan) (06/29/90)
Date: Thu, 28 Jun 90 13:11:44 PDT
From: root@vlsi-mentor.jpl.nasa.gov (The vlsi-mentor Super User)
Message-Id: <9006282011.AA28396@vlsi-mentor.jpl.nasa.gov>
To: apollo%umix.cc.umich.edu%jpl-mil@umix.cc.umich.edu
Subject: RE: security problems
BTW, I believe security holes should be broadcast over the net.
This way, they *will* get fixed, and security based upon hidden
information is not secure.
----
Dave Hayes dave@vlsi-mentor.jpl.nasa.gov
dave%vlsi-mentor@jpl-mil.jpl.nasa.gov
"The word 'choice' is a fraud when one is taught what to choose."
I'm not denying that a security hole should be broadcast but broadcasting the
Apollo hotline problem number instead of the actual problem on this list would
be more secure; then only approved hotline users can query the details.
Gerry O'Brennan
Computing Services
University of Missouri - Rolla
------------------------------
obrennan@apollo.cc.umr.edu
c0022@umrvmb.umr.edu
------------------------------ran@cns.umist.ac.uk (Bob Nutter) (06/29/90)
In article <9006281344.AA00445@cc2.cc.umr.edu> obrennan@CC3.CC.UMR.EDU (obrennan) writes: [stuff deleted...] > >...I still think that the >information can be just as helpful by opening up a problem report with Apollo >and announcing that problem report # so that other administrators can query >Apollo about it without exposing the network. [more stuff deleted...] ...all very well, and ideal if everything was perfect. Trying to get any sense out of Hp/Apollo these days, never mind details on an APR that someone filed in possibly a different continent is _not_exactly_easy_ Christ, they're not even sure about our contracts with them! I know it doesn't resolve the issue, but how many people out there have had a patch tape *offered* them by apollo? Do Apollo tell you about bugs/problems? Why do more problems get sorted out here than through manual-quoting support centres? (These are all questions someone at HP/Apollo should answer...) Just something to think about, I suppose... bob ------------------------------------------------------------------------ bob nutter, computer officer dept of computation, UMIST po box 88 manchester m60 1qd UK tel:+44 61 200 3386 email:ran@cns.umist.ac.uk root@ap.co.umist.ac.uk
wjw@eb.ele.tue.nl (Willem Jan Withagen) (07/02/90)
In article <9006291314.AA00280@cc2.cc.umr.edu> obrennan@CC3.CC.UMR.EDU (obrennan) writes: > > BTW, I believe security holes should be broadcast over the net. > This way, they *will* get fixed, and security based upon hidden > information is not secure. > >I'm not denying that a security hole should be broadcast but broadcasting the >Apollo hotline problem number instead of the actual problem on this list would >be more secure; then only approved hotline users can query the details. The problem with this is that I and many more of the "approved" users, are have trouble getting to the hotline. And it somnetimes takes a while for the correct info to propagate to place outside the US of A. Since a lot of us are'nt in the States it would be rather expensive, and they would not recognise use as a user with a service contract. Which brings me to the second point, how about all those users without a service-contract. There the ones that'll never find out what's going on. No, I'm in favour to expose as much of the bugs and features as is possible. Yours, Willem Jan Withagen Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (07/02/90)
You y You have a nice idea that does not work in pratice. The Hotline number is *NOT* restricted to system administrators. It is accessable to *ANY* user you knows how to dial 1-800-2-apollo and who knows your network's site-ID number. HP/Apollo has no way of telling whether or not the caller is 'trustworthy'. All that a user has to do is to dial the number, give the site-ID (and if they're sneaky, give their sys admin's name but their own phone number), and ask the necessary question "what's this about a new security bug?". The hotline is *not* secure. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
jal@acc.flint.umich.edu (John Lauro) (07/02/90)
With all the talk about security, and at least two problems with using Apollo's hot-line (No/Poor/Expensive to some, and not secure), perhaps a moderated mailing list would work. - John_Lauro@ub.cc.umich.edu
achille@cernvax.UUCP (achille petrilli) (07/03/90)
In article <9006281344.AA00445@cc2.cc.umr.edu> obrennan@CC3.CC.UMR.EDU (obrennan) writes: >as well give them the keys". By the way, with announcing the info to the list >you are ALSO giving away the keys to others houses. I still think that the >information can be just as helpful by opening up a problem report with Apollo >and announcing that problem report # so that other administrators can query >Apollo about it without exposing the network. Also, what is the liability of >a person for publicly exposing this information? What if millions of dollars >are lost because of the posting of the information? > > >Gerry O'Brennan >Computing Services >University of Missouri - Rolla Here are two true (horror) stories. As everybody knows, SR9 and before were plenty of security holes all over the place. I submitted a number of UCR (now APR). For most of them, I got answers that only meant the problem wasn't understood. For some other, the official answer was that 'Aegis was not meant to be a secure system, protections are there to prevent non-malicious users from deleting everything' ... No action as EVER been taken to close those holes, as matter of fact they are still there in SR9.7. The UCRs were sent during 1985/1986. One of my friends told me around 1986/1987 that sendmail had a security bug in it that could allow anyone to become root. I didn't ask details about it, but it came back to my mind when the Internet Worm arrived. The two stories above should tell you that the official channels or the 'security by ignorance' are not always the right way of handling this sort of problems. In some cases, you MUST go out to the net and take the risk. Achille Petrilli Management Information Systems CERN
mike@tuvie (Inst.f.Techn.Informatik) (07/04/90)
In article <2032@cernvax.UUCP>, achille@cernvax.UUCP (achille petrilli) writes: > One of my friends told me around 1986/1987 that sendmail > had a security bug in it that could allow anyone to become root. I didn't ask > details about it, but it came back to my mind when the Internet Worm arrived. > > The two stories above should tell you that the official channels or the > 'security by ignorance' are not always the right way of handling this sort of > problems. > In some cases, you MUST go out to the net and take the risk. > > Achille Petrilli > Management Information Systems > CERN The sendmail problem still exists in sr10.1. I guess the only way something will be done is by postin security problems to the net. First of all you will reach all Apollo users having access to the comp.sys.apollo group (which means the Europeans will get information as well). Also, if HP/Apollo think they can handle Apollo security problem by saying Apollos were never intended to be secure, then we should try to force them to enhance security by posting *ALL* problems to the net ('security by exposure' instead of 'security by ignorance'). bye, mike ____ ____ / / / / / Michael K. Gschwind mike@vlsivie.at / / / / / Technical University, Vienna mike@vlsivie.uucp ---/ Voice: (++43).1.58801 8144 e182202@awituw01.bitnet / Fax: (++43).1.569697 ___/
root@craven.ee.man.ac.uk (Operator) (07/04/90)
In article <1990Jul2.145952.13977@caen.engin.umich.edu> jal@acc.flint.umich.edu (John Lauro) writes: >With all the talk about security, and at least two problems with using >Apollo's hot-line (No/Poor/Expensive to some, and not secure), perhaps >a moderated mailing list would work. > I agree that the hot-line is not secure, but how on earth could you make a mailing list secure? What method could you use to ensure that someone is a bona-fide sysadmin? - And even if they are, can you really trust them? Gone are the days of the mainframe sysadmin as an elite breed - we're two a penny now (God! - I can almost feel myself slowly depreciating ;-() As far as I can tell - the only real solution is for HP/Apollo to IMMEDIATELY fix any security holes (no - fixed in release 15.23 1/2 WON'T do!!) and simply inform people that the patch exists and should be installed. They should not release any details of the nature of the problem as this simply makes things easier for hackers. I believe that DEC already operate in a similar fashion to this - though I could well be wrong. Frankly, it seems to me that Apollo's attitude towards security sucks, which is a great shame 'cos I generally love the machines. Anyway, enough rambling - here endeth my $0.02 worth. Colin
bep@quintro.uucp (Bryan Province) (07/05/90)
In article <1407@m1.cs.man.ac.uk> dente@els.ee.man.ac.uk writes: >As far as I can tell - the only real solution is for HP/Apollo to IMMEDIATELY >fix any security holes (no - fixed in release 15.23 1/2 WON'T do!!) and simply >inform people that the patch exists and should be installed. They should not >release any details of the nature of the problem as this simply makes things >easier for hackers. I believe that DEC already operate in a similar fashion to >this - though I could well be wrong. Yes DEC does do this. I used to administer a couple of DEC systems a few years ago and every once in a while I'd get a tape that said it was a "MANDATORY PATCH" and that it fixed a security bug and that if it wasn't installed that DEC wouldn't be responsible for any security problems that may result. They didn't describe the problem they just fixed it for you. Ah the good old days. Too bad HP/Apollo doesn't subscribe to the same policies that other companies have used for years (stab, gouge, flame). -- --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- Bryan Province Glenayre Corp. quintro!bep@lll-winken.llnl.gov Quincy, IL tiamat!quintro!bep@uunet "Surf Kansas, There's no place like home, Dude."
rees@dabo.ifs.umich.edu (Jim Rees) (07/05/90)
In article <1646@tuvie>, mike@tuvie (Inst.f.Techn.Informatik) writes:
Also, if HP/Apollo think they can handle Apollo security problem by saying
Apollos were never intended to be secure, then we should try to force them
to enhance security by posting *ALL* problems to the net
Warning: Crufty personal opinion ahead.
I think there has been a lot of confusion (even within Apollo) about the
Apollo model of security. I think the basic question you need to ask is,
"where is the boundary between the trusted side of the system and the
untrusted side?"
The traditional boundary has always been between the user and the computer.
Computers trust each other but not their users. Berkeley and Sun still
adhere to this model. I claim that this model is no longer valid, because
computers are now under the control of untrusted users. A perfect example
of this wrong-headed thinking is so-called "trusted ports" in TCP. Trusted
by whom? Any user with half a brain can make a TCP connection appear to
come from any port they want, and can make a connection to any port they
want. At Apollo we resisted for years implementing trusted ports, because
we knew it was a complete sham, and that anyone who depended on trusted
ports was just asking for trouble.
In today's world, you have to put the boundary not between the user and his
computer, but between computers. This is the exact opposite of the
Berkeley/Sun model. Computers must trust their users, because the user can
always hit the reset button or write his own kernel. These are extreme
examples, but the point is that the computer is no longer in a locked room,
it's on someone's desk, and anyone who has physical access to a computer can
(in theory) do whatever they like with it. Computers can no longer trust
each other, because each one is under the control of a (potentially hostile)
user.
This means that you can't trust anything that comes down the ethernet. If
you carry this argument to its logical conclusion, you need to implement
some kind of authentication/encryption scheme, like Kerberos (which has its
own flaws but at least is trying to solve the right problem).
IBM systems don't trust anyone.
Sun systems trust each other and pretend they don't trust their users. In
fact, they do trust their users, because when you trust a workstation, you
are trusting its user.
Apollo systems trust each other and didn't used to pretend that they don't
trust their users (got that?). Now that customers have bullied the company
into providing various abominations like the Berkeley 'r' commands, they
pretend to trust their users too. JLRU.steven@pacific.csl.uiuc.edu (Steven Parkes) (07/06/90)
|> ... every once in a while I'd get a tape that said it was a |> "MANDATORY PATCH" and that it fixed a security bug and that if it wasn't |> installed that DEC wouldn't be responsible for any security problems that may |> result. Of course, they (and everybody else) disclaim any responsiblity for the results of the use of their product anyway ... :-)
zeleznik@cs.utah.edu (Mike Zeleznik) (07/06/90)
>>As far as I can tell - the only real solution is for HP/Apollo to IMMEDIATELY >>fix any security holes (no - fixed in release 15.23 1/2 WON'T do!!) and simply >>inform people that the patch exists and should be installed. > >Yes DEC does do this. ... >... Too bad HP/Apollo doesn't subscribe to the same policies that >other companies have used for years (stab, gouge, flame). *YES*. And not just for security either. HP has been sending out periodic (quarterly I think) bug/status lists for some time. Given that Apollo has had the mothly patch tape mechanism going for years, it's a shame they couldn't have made it *MUCH* more useful by following this example (maybe now it will change, but I'd imagine HP has many other things of higher priority...). Mike Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617