dente@els.ee.man.ac.uk (Colin Dente) (07/19/90)
Ho hum - so much for my ideas about not disclosing the nature of security-related patches... Following Jim Richardson's recent mention of patch_m0121, and the importance of installing the same, I thought 'Hmm... 'spose I'd better get hold of a copy.' So, I 'phoned the response centre here in the UK, said I was after a security related patch, gave them the patch number, and waited for them to call me back. The first thing that the response centre person did was to confirm that I had the right patch number by telling me precisely the nature of the security hole that it fixes!! Oh boy oh boy! nasty one that. Can I ask any HP/Apollo people reading this to press for it to become corporate policy (or whatever you call it) NOT to disclose information of this nature. I intend to speak to the person involved, and whoever is in charge of such things in the UK, but in the mean time, PLEASE keep the nature of security holes quiet. Anyway, I would repeat Jim's comments on this patch - get it and install it!! Colin -- Colin Dente | JANET: dente@uk.ac.man.ee.els Dept. of Electrical Engineering | ARPA: dente@els.ee.man.ac.uk University of Manchester, UK | UUCP: ...!ukc!man.ee.els!dente --------------------------------------------------------------------
rees@dabo.ifs.umich.edu (Jim Rees) (07/20/90)
In article <1469@m1.cs.man.ac.uk>, dente@els.ee.man.ac.uk (Colin Dente) writes:
PLEASE keep the nature of security holes quiet.
I disagree, and patch 121 is a perfect example of why we need to discuss
security holes. Unless I miss my guess, this patch does not fix the hole at
all, it just removes a copy of a program that exploits that hole. You go
away thinking your machine is now somehow more secure, and anyone who really
wants to can still get in.
I may be wrong, but since we're not discussing this hole here, we'll never
find out, will we?jonathan@jarthur.Claremont.EDU (Jonathan Ball) (07/20/90)
In article <1990Jul19.193641.23420@terminator.cc.umich.edu> rees@citi.umich.edu (Jim Rees) writes: In article <1469@m1.cs.man.ac.uk>, dente@els.ee.man.ac.uk (Colin Dente) writes: > PLEASE keep the nature of security holes quiet. I disagree, and patch 121 is a perfect example of why we need to discuss security holes. Unless I miss my guess, this patch does not fix the hole at all, it just removes a copy of a program that exploits that hole. You go away thinking your machine is now somehow more secure, and anyone who really wants to can still get in. I may be wrong, but since we're not discussing this hole here, we'll never find out, will we? Well, perhaps Jim Richardson and anyone else who DOES know what the problem is, and HAS applied the patch, could tell us that information without revealing the hole to the rest of the world. Jon -- jonathan@jarthur.claremont.edu (134.173.4.42)
jimr@maths.su.oz.au (Jim Richardson) (07/20/90)
In article <7871@jarthur.Claremont.EDU>, jonathan@jarthur.Claremont.EDU (Jonathan Ball) writes: > I may be wrong, but since we're not discussing this hole here, we'll never > find out, will we? > >Well, perhaps Jim Richardson and anyone else who DOES know what the problem >is, and HAS applied the patch, could tell us that information without >revealing the hole to the rest of the world. As I said in my previous posting <1990Jul17.004711.19627@metro.ucc.su.OZ.AU> on this, >I hope everybody has m0121 installed by now. Maybe in a month or two it will >be safe to discuss it on the net ... or maybe not. Let's *please* give people some more time to install it before we start the discussion -- particularly since (as roger@GW1.AGS.BNL.GOV (Roger A. Katz) pointed out in <9007171350.AA29728@gw1.ags.bnl.gov>) you can't even install the patch with install++ because of yet another bug of some sort but have to copy the "module" (as Roger delicately and securely described it) into its place manually. In the meantime, there *is* a safe way of approaching security questions: use CERT. I haven't had time (or the telephone link, from this distance) to talk to them myself. If there are people who *do* want to discuss security issues in depth, please do it with CERT not on Usenet, at least for the time being. I append two old postings of Gene Spafford's describing CERT. I hope someone will take this up. -- Jim Richardson Department of Pure Mathematics, University of Sydney, NSW 2006, Australia Internet: jimr@maths.su.oz.au ACSNET: jimr@maths.su.oz FAX: +61 2 692 4534 -- From: spaf@cs.purdue.EDU (Gene Spafford) Newsgroups: comp.sources.d,news.sysadmin Subject: Re: Security, not obscurity. Message-ID: <10263@medusa.cs.purdue.edu> Date: 8 Apr 90 01:31:16 GMT References: <16900@well.sf.ca.us> <1990Mar29.055350.2922@Jhereg.Minnetech.MN.ORG> <1105@rwing.UUCP> <2364@sialis.mn.org> <LYNDON.90Apr5115012@orthanc.AthabascaU.CA> <291@van-bc.UUCP> Reply-To: spaf@cs.purdue.edu (Gene Spafford) Followup-To: comp.sources.d Organization: Department of Computer Science, Purdue University If you want to report a security bug or problem, your best bet is to report it to the CERT (Computer Emergency Response Team). Their e-mail address is cert@cert.sei.cmu.edu The CERT 24-hour hotline is (412) 268-7080. They will accept (and solicit) reports of any security flaw in software/hardware in systems currently on the Internet, and they will also accept reports of breakins and security incidents in progress. The folks at the CERT have ties in to most major vendors, they take reports very seriously, they keep the information confidential until fixes are available, and they don't dally when they get a report. They also have good contacts and working relationships with the various law enforcement agencies that would respond to problems you may be having. The CERT does no investigation on its own, and has no explicit jurisdiction or authority over security or law -- they are just a trusted crisis center that can direct your reports to the most appropriate parties. If you want to submit something to the security mailing list, you can mail it to "security@cpd.com" or "zardoz!security". Mailings to this list will reach people at major vendors, including DEC, AT&T and Sun, as well as the CERT and admins at many major sites. Note that the list may go to some unprotected sites, and anything appearing in the list is assumed to be known to the "bad guys" shortly after posting, so please use care in sending in news of gaping holes that cannot be fixed (send them to CERT, instead). If, for any reason, you do not wish to be associated with a report to the CERT or a security list, you can send reports to me. If I receive a report via email (or phone -- 317-494-7825) with a request to forward it anonymously, I will be happy to pass it along to the appropriate place with all identification stripped. I will also pass along other reports, too, if you ask me to. That assumes you feel you can trust me, of course. (1/4 :-) -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf From: spaf@cs.purdue.EDU (Gene Spafford) Newsgroups: comp.sources.d Subject: Re: Security, not obscurity. Message-ID: <10283@medusa.cs.purdue.edu> Date: 10 Apr 90 01:00:08 GMT References: <16900@well.sf.ca.us> <1990Mar29.055350.2922@Jhereg.Minnetech.MN.ORG> <1105@rwing.UUCP> <2364@sialis.mn.org> <LYNDON.90Apr5115012@orthanc.AthabascaU.CA> <291@van-bc.UUCP> <10263@medusa.cs.purdue.edu> Reply-To: spaf@cs.purdue.edu (Gene Spafford) Organization: Department of Computer Science, Purdue University Ooops! A minor goof. The CERT 24-hotline number is (412) 268-7090 The 7080 is a daytime general information number for CERT. -- Gene Spafford
pha@CAEN.ENGIN.UMICH.EDU (235 Chry) (07/20/90)
From: jonathan%jarthur%usc.uucp@ucsd.edu Organization: Harvey Mudd College, Claremont, CA 91711 Message-Id: <7871@jarthur.Claremont.EDU> Subject: Re: Patches and security In article <1990Jul19.193641.23420@terminator.cc.umich.edu> rees@citi.umich.edu (Jim Rees) writes: In article <1469@m1.cs.man.ac.uk>, dente@els.ee.man.ac.uk (Colin Dente) writes: > PLEASE keep the nature of security holes quiet. I disagree, and patch 121 is a perfect example of why we need to discuss security holes. Unless I miss my guess, this patch does not fix the hole at all, it just removes a copy of a program that exploits that hole. You go away thinking your machine is now somehow more secure, and anyone who really wants to can still get in. I may be wrong, but since we're not discussing this hole here, we'll never find out, will we? Well, perhaps Jim Richardson and anyone else who DOES know what the problem is, and HAS applied the patch, could tell us that information without revealing the hole to the rest of the world. Jon -- jonathan@jarthur.claremont.edu (134.173.4.42) I sent jonathan a description of the problem, and why patch 121 doesn't fix anything. This is a very serious problem. It defies rational thought to believe that it exists in the first place, and that this type of "patch" supposedly fixes it in the second place. Security by obscurity is DANGEROUS!!!! Paul Anderson CAEN Systems Programmer University of Michigan
dente@craven.ee.man.ac.uk (Colin Dente) (07/20/90)
In article <7871@jarthur.Claremont.EDU> jonathan@jarthur.Claremont.EDU (Jonathan Ball) writes about Jim Rees writing about what I said in the first place: [Me] >>> PLEASE keep the nature of security holes quiet. [Jim] >>I disagree, and patch 121 is a perfect example of why we need to discuss >>security holes. Unless I miss my guess, this patch does not fix the hole at >>all, it just removes a copy of a program that exploits that hole. You go >>away thinking your machine is now somehow more secure, and anyone who really >>wants to can still get in. Well, much as I hate doing it, on reflection I have to (at least partially) agree with Jim, even though he is correcting me 8-) When I saw the nature of the patch, I thought 'Great - that solves the problem entirely' - more fool me! As Jim so rightly points out, all the patch does is change a single program that doesn't run suid or anything fancy. The *REAL* security hole is the fact that a simple user-mode program could, *and still can* create an suid root file when run as a normal user. Let's face it, when you consider the nature of this bug - 10.2 CAN NEVER BE EVEN SLIGHTLY SECURE. Give me access to any machine, and the ability to load at most two files on, and I can become root by typing a single command. This is no exaggeration. Even sites which have installed patch 121 are not immune from the effects of this hole (they simply require me to load two files instead of one). [Jim] >>I may be wrong, but since we're not discussing this hole here, we'll never >>find out, will we? Unfortunately, you're not wrong - as I said before - 10.2 is wide open. [Jon] >Well, perhaps Jim Richardson and anyone else who DOES know what the problem >is, and HAS applied the patch, could tell us that information without >revealing the hole to the rest of the world. Unfortunately, I don't think I can say much more about it without revealing it's exact nature, but I will say this to HP: If this bug has not been fixed in SR10.3, then I can see no way of justifying its release. Fixing this bug should be made the highest possible priority if you wish to have any pretensions towards being a supplier of professional computer equipment. Boy am I mad... -- Colin Dente | JANET: dente@uk.ac.man.ee.els Dept. of Electrical Engineering | ARPA: dente@els.ee.man.ac.uk University of Manchester, UK | UUCP: ...!ukc!man.ee.els!dente ... I am the one you warned me of ...
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (07/21/90)
> I sent jonathan a description of the problem, and why patch 121 doesn't > fix anything. I have also verified that the patch is trivial to work around. I also verified that 'install' does not install the patch "module." > This is a very serious problem. It defies rational thought to believe that > it exists in the first place, and that this type of "patch" supposedly fixes > it in the second place. It is even worse in that it _TELLS_ you that it was unable to break security, but does so anyway!!! The problem is that, now that a copy of the dangerous module has been available, the only way I can think of to repair the damage is to change the internals for that module. That would involve several driver-level changes, and would ruin many other software packages. > Security by obscurity is DANGEROUS!!!! True! Notice how obscure we are, anyway. I have opened up a call with Apollo on the failure of this patch. I am going to try and get a new APR for it, along with some sort of answer from them as to what they intend to do about it. Until then, I will not mention where the breaach is, or how to get around the "patched" hole, although most everyone seems to know anyway. John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either)
jonathan@jarthur.Claremont.EDU (Jonathan Ball) (07/21/90)
In article <7871@jarthur.Claremont.EDU>, I write: >Well, perhaps Jim Richardson and anyone else who DOES know what the problem >is, and HAS applied the patch, could tell us that information without >revealing the hole to the rest of the world. In article <1990Jul20.031221.14378@metro.ucc.su.OZ.AU> jimr@maths.su.oz.au (Jim Richardson) writes: >Let's *please* give people some more time to install it before we start the >discussion [...] If there are people who *do* want to discuss >security issues in depth, please do it with CERT not on Usenet, at least >for the time being. Agreed. I apologize for opening the can of worms. Jon -- jonathan@jarthur.claremont.edu (134.173.4.42) -- jonathan@jarthur.claremont.edu (134.173.4.42)
jimr@maths.su.oz.au (Jim Richardson) (07/21/90)
In article <7892@jarthur.Claremont.EDU>, jonathan@jarthur.Claremont.EDU (Jonathan Ball) writes: >Agreed. I apologize for opening the can of worms. Thanks, Jon. [ I have been trying to send you mail for a couple of days, but jarthur appears to be dead from here. ] I hope everybody saw my posting <1990Jul20.031221.14378@metro.ucc.su.OZ.AU> on CERT (Computer Emergency Response Team): (412) 268 7090, cert@cert.sei.cmu.edu. That article of mine seems to have crossed with Jon's, Colin's, and several others. Please talk to CERT (and HP I suppose :-) about the new hole, rather than discussing it on the net yet. The ramifications of OS security are really too enormous and wide-reaching for safe open discussion for the time being: things may come to that eventually, but we have enough other avenues still open not to be completely desperate yet. The newsfeed to Australia has been snail-like for the last few days and I'm struggling to keep up down here. If there's a news guru on/near the US backbone willing to do me a favour perhaps you could email me. -- Jim Richardson Department of Pure Mathematics, University of Sydney, NSW 2006, Australia Internet: jimr@maths.su.oz.au ACSNET: jimr@maths.su.oz FAX: +61 2 692 4534
mike@tuvie (Inst.f.Techn.Informatik) (07/21/90)
In article <1491@m1.cs.man.ac.uk>, dente@craven.ee.man.ac.uk (Colin Dente) writes: |> In article <7871@jarthur.Claremont.EDU> jonathan@jarthur.Claremont.EDU (Jonathan Ball) writes about Jim Rees writing about what I said in the first place: |> |> When I saw the nature of the patch, I thought 'Great - that solves the |> problem entirely' - more fool me! As Jim so rightly points out, all |> the patch does is change a single program that doesn't run suid or |> anything fancy. The *REAL* security hole is the fact that a simple |> user-mode program could, *and still can* create an suid root file when |> run as a normal user. Let's face it, when you consider the nature of |> this bug - 10.2 CAN NEVER BE EVEN SLIGHTLY SECURE. Give me access to |> any machine, and the ability to load at most two files on, and I can |> become root by typing a single command. This is no exaggeration. |> Even sites which have installed patch 121 are not immune from the |> effects of this hole (they simply require me to load two files instead |> of one). |> |> If this bug has not been fixed in SR10.3, then I can see no way of |> justifying its release. Fixing this bug should be made the highest |> possible priority if you wish to have any pretensions towards being a |> supplier of professional computer equipment. Well, I fear the day people find out the syscalls necessary to do this breach! In the maentime I think sysadmins should note that they should *REMOVE* THE OLD COPY OF THE PROGRAM! It is probably still in your authorized area ind /install/ri.apollo.os.v.10.2/ - and you know the rest of the patch. This will still allow anybody with access to a cartridge tape, a disk, email, the keyboard or just about anything else allow to intrude - but not quite as easily! 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 ___/
pha@CAEN.ENGIN.UMICH.EDU (Paul H. Anderson) (07/23/90)
> I sent jonathan a description of the problem, and why patch 121 doesn't > fix anything. I have also verified that the patch is trivial to work around. I also verified that 'install' does not install the patch "module." > This is a very serious problem. It defies rational thought to believe that > it exists in the first place, and that this type of "patch" supposedly fixes > it in the second place. It is even worse in that it _TELLS_ you that it was unable to break security, but does so anyway!!! The problem is that, now that a copy of the dangerous module has been available, the only way I can think of to repair the damage is to change the internals for that module. That would involve several driver-level changes, and would ruin many other software packages. > Security by obscurity is DANGEROUS!!!! True! Notice how obscure we are, anyway. I have opened up a call with Apollo on the failure of this patch. I am going to try and get a new APR for it, along with some sort of answer from them as to what they intend to do about it. Until then, I will not mention where the breaach is, or how to get around the "patched" hole, although most everyone seems to know anyway. John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either) I've also got a call open on it - it was immediately raised to P1 priority at my request, and I am expecting an answer from customer services tomorrow or Wednesday as to if/when/how the hole will be fixed. I will let this group know the results of that call. I have asked for a patch for SR10.1, SR10.2, as well as SR10.3. Having a patch for just 10.3 doesn't help, as we have about an even mix of 10.1 and 10.2 machines running around. Paul Anderson