ton@let.rug.nl (Ton Roovers) (02/20/91)
Some months ago I converted our HP-UX 7.0 systems to 'secure systems'. Only last week one of 'my' users discovered (by pure accident), that by making a mistake in entering his username (in login) he was logged in as ROOT! (I think it is not wise to state the exact procedure here). I immediately contacted our CRC about this and within a few hours I had a new version of the login program in my e-mailbox and the problem was fixed. But I noticed that this 'new' version of login was over ONE YEAR OLD (Feb. 6, 1990). How many HP-UX systems are running today with the same huge security hole? When I asked the engineer of the (Dutch) CRC he answered, that it is not a standard procedure of HP to send their clients all possible patches, because many of them are not useful for all systems. So you have to ask for them. Furthermore there is no way of warning clients of possible security holes... Of course I (re)read the Software Status Bulletins, but they did not contain any reference to this problem. I even went through all my accumulated articles in comp.sys.hp with the same result. You could have this problem too, if you are running HP-UX 6.5 (on 300's) or 7.0 (on 300's and 800's) with the original login AND you converted to 'secure system'. Please contact your CRC, not me: I'm still busy checking if someone in the last months actually USED this hole in my systems :-( I know there has been a lengthy discussion on the topic of customer support in this newsgroup and don't want to trigger a new one right now, but I would like to repeat here what I told my CRC-engineer: "I expect to be warned by Hewlett-Packard for possible security problems in my HP-systems just like I expect the manufacturer of my car to warn me if the brakes are not safe." -- Ton Roovers systems manager _______________________________________________________________________________ Faculty of Arts and Letters, Groningen University ton@let.rug.nl PO Box 716, NL 9700 AS Groningen, The Netherlands
jim@cs.strath.ac.uk (Jim Reid) (02/21/91)
In article <1581@gufalet.let.rug.nl> ton@let.rug.nl (Ton Roovers) writes:
"I expect to be warned by Hewlett-Packard for possible security problems
in my HP-systems just like I expect the manufacturer of my car to warn
me if the brakes are not safe."
This is rather naive. Most computer companies (and HP in particular)
will not discuss security problems with their software or notify their
customers when security holes/bugs are found. In most cases, they hide
behind the feeble excuse of "company policy". This also lets the
company get away with doing nothing - what customers don't know
about can't worry them. It also means the company decides what
security problems you need to know about, regardless of whether they
are important to you or not. Mr. Computer Vendor knows what's best for
you so just trust him....
What makes things worse is the double standards that apply when a
customer finds a problem: the company expect you to tell them
everything about it (without knowing who you're talking to or if they
can be trusted), but the person you speak to won't trust you enough to
discuss security matters with you.
[I can understand that companies won't want that sort of information
getting into the wrong hands - imagine the lawsuits if somebody
damages a computer using a security hole told to them by a vendor's
employee. However, that is no excuse for saying absolutely nothing and
treating customers with contempt.]
Some years ago, we had a security problem with HP-UX. After a lot of
complaining, HP sent their "security expert" to check out the system
and run an audit script which ostensibly checked permissions, looked
for non-standard setuid-root files, inspected the version numbers of
some bits of software and so on. This checked out OK (surprise,
surprise!) and the security expert said there were no problems or
holes on the system that he was aware of. About a month later an
update tape arrived from HP. The date on the covering letter was well
BEFORE the visit of the security person. The update letter explained
that this was to fix some security holes in sendmail - no surprises
there - and some other networking utilities. It didn't say what the
holes were, so the customer was to blindly do the upgrade without
knowing what holes were being fixed (or left unfixed). The important
thing here is that HP knew there was a problem but wouldn't tell the
customer - instead they implied there wasn't a problem. In fact, they
misled us by telling us something that the company knew was untrue. Of
course, we're not gullible enough to believe that computer support
people tell customers the truth, the whole truth and nothing but the
truth. However this shows what can happen when a company policy of
silence is followed. The whole escapade has irreversibly damaged the
image and reputation of HP for me.
Jimalex@sapphire.idbsu.edu (Alex Feldman) (02/22/91)
In article <1581@gufalet.let.rug.nl> ton@let.rug.nl (Ton Roovers) writes: > >Some months ago I converted our HP-UX 7.0 systems to 'secure systems'. >Only last week one of 'my' users discovered (by pure accident), that >by making a mistake in entering his username (in login) he was logged >in as ROOT! (I think it is not wise to state the exact procedure here). > [stuff deleted] > >You could have this problem too, if you are running HP-UX 6.5 (on 300's) >or 7.0 (on 300's and 800's) with the original login AND you converted >to 'secure system'. Please contact your CRC, not me: I'm still busy >checking if someone in the last months actually USED this hole in my >systems :-( > It happened to us on 7.03. They were pretty quick about getting us a tape with the fix. Sure can ruin your day, though. What happens to people who don't have software support?? -- --alex alex@opal.idbsu.edu Boise State University doesn't have any opinions. Therefore, these are not the opinions of Boise State University.
jlol@remus.ee.byu.edu (Jay Lawlor) (02/24/91)
>>>>> On 20 Feb 91 13:57:33 GMT, ton@let.rug.nl (Ton Roovers) said:
Ton> Some months ago I converted our HP-UX 7.0 systems to 'secure systems'.
Ton> Only last week one of 'my' users discovered (by pure accident), that
Ton> by making a mistake in entering his username (in login) he was logged
Ton> in as ROOT! (I think it is not wise to state the exact procedure here).
Yeah, we ran into this under 6.5. Our solution? Reinstall and don't
convert to a secure system. It was much more secure that way. :)campbell@dev8n.mdcbbs.com (Tim Campbell) (02/25/91)
In article <JIM.91Feb21124615@baird.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes: > In article <1581@gufalet.let.rug.nl> ton@let.rug.nl (Ton Roovers) writes: > > "I expect to be warned by Hewlett-Packard for possible security problems > in my HP-systems just like I expect the manufacturer of my car to warn > me if the brakes are not safe." > > This is rather naive. Most computer companies (and HP in particular) > will not discuss security problems with their software or notify their > customers when security holes/bugs are found. In most cases, they hide > behind the feeble excuse of "company policy". This also lets the > company get away with doing nothing - what customers don't know > about can't worry them. It also means the company decides what > security problems you need to know about, regardless of whether they > are important to you or not. Mr. Computer Vendor knows what's best for > you so just trust him.... That's taking an awful big risk. Can you imagine the lawsuits resulting if some unscrupulous employee of HP decided to use this information to his advantage and attack vulnerable unsuspecting customers. It's an awful big risk to take. With (to name competition) Sun, you can be put on the "customer distributed buglist" - they don't actually send patches for everything, just a summary of the known bugs, fixes, and/or workarounds. I don't know as much about HP, perhaps they have a similar list. [stuff deleted] > [I can understand that companies won't want that sort of information > getting into the wrong hands - imagine the lawsuits if somebody > damages a computer using a security hole told to them by a vendor's > employee. However, that is no excuse for saying absolutely nothing and > treating customers with contempt.] At least YOU would have the opportunity to be informed and take action. The scenario previously mentioned leaves you vulnerable. Obviously SOMEBODY knows that the bugs exist - and it's up to their own discretion as to who they want to let in on the secret. I imagine most people prefer that nobody should know "except me". > Some years ago, we had a security problem with HP-UX. After a lot of > complaining, HP sent their "security expert" to check out the system > and run an audit script which ostensibly checked permissions, looked > for non-standard setuid-root files, inspected the version numbers of > some bits of software and so on. This checked out OK (surprise, > surprise!) and the security expert said there were no problems or > holes on the system that he was aware of. About a month later an > update tape arrived from HP. The date on the covering letter was well > BEFORE the visit of the security person. The update letter explained > that this was to fix some security holes in sendmail - no surprises > there - and some other networking utilities. It didn't say what the > holes were, so the customer was to blindly do the upgrade without > knowing what holes were being fixed (or left unfixed). The important > thing here is that HP knew there was a problem but wouldn't tell the > customer - instead they implied there wasn't a problem. In fact, they > misled us by telling us something that the company knew was untrue. Of > course, we're not gullible enough to believe that computer support > people tell customers the truth, the whole truth and nothing but the > truth. However this shows what can happen when a company policy of > silence is followed. The whole escapade has irreversibly damaged the > image and reputation of HP for me. This really sounds like they gave you the security fix for the famous internet worm. When they checked out your system - all the files were correct. You *DID* in fact have the standard sendmail program shipped with the system and nobody tampered with anything. Unfortunately, that sendmail daemon wasn't really very secure. > > Jim -- -Tim --------------------------------------------------------------------------- In real life: Tim Campbell - Electronic Data Systems Corp. Usenet: campbell@dev8.mdcbbs.com @ McDonnell Douglas M&E - Cypress, CA also: tcampbel@einstein.eds.com @ EDS - Troy, MI CompuServe: 71631,654 Prodigy: MPTX77A P.S. If anyone asks, just remember, you never saw any of this -- in fact, I wasn't even here.
jmc@cnd.hp.com (Jerry McCollom) (02/27/91)
In article <1991Feb25.132419.1@dev8n.mdcbbs.com> campbell@dev8n.mdcbbs.com (Tim Campbell) writes: > > holes on the system that he was aware of. About a month later an > > update tape arrived from HP. The date on the covering letter was well > > BEFORE the visit of the security person. The update letter explained > > that this was to fix some security holes in sendmail - no surprises > > there - and some other networking utilities. It didn't say what the > > holes were, so the customer was to blindly do the upgrade without > > knowing what holes were being fixed (or left unfixed). The important > > thing here is that HP knew there was a problem but wouldn't tell the > > customer - instead they implied there wasn't a problem. In fact, they > > misled us by telling us something that the company knew was untrue. Of > > course, we're not gullible enough to believe that computer support > > people tell customers the truth, the whole truth and nothing but the > > truth. However this shows what can happen when a company policy of > > silence is followed. The whole escapade has irreversibly damaged the > > image and reputation of HP for me. > > This really sounds like they gave you the security fix for the famous > internet worm. When they checked out your system - all the files were > correct. You *DID* in fact have the standard sendmail program shipped > with the system and nobody tampered with anything. Unfortunately, that > sendmail daemon wasn't really very secure. The problem addressed by this patch was found around the same time that the worm did its thing, but was honestly unrelated. The worm depended on a problem in sendmail's debug code, which HP excluded from the that release of sendmail. Instead, the defect addressed by this sendmail patch was a little known (or, at least, not widely publicized) 4.2BSD sendmail security hole, not exploitable through the deamon, that was discovered and reported internally (and the graphic details were posted to an internal news group as I remember!!). I suspect the other "networking utilities" was the patch to ftpd for a security hole that was described in detail on NPR (National Public Radio). There were no security holes "left unfixed" that we knew of at the time of these patches. That doesn't mean there weren't (aren't) any yet-to-be-found security holes, but it does mean that we would never (and I personally would never) intentionally leave a known security hole in your software even if, as far as we knew, no customer knew about it. I think the sendmail patch was an example of this stance. It is certainly unfortunate if support people weren't up front about there being security problems requiring the patches. I know it was our (lab) policy to be up front about informing customers and support folks about the problems and that they should be patched A.S.A.P. I'm not aware of that there was any company-wide, "official", stated security patch policy at the time of this patch. I do know that our rational behind not revealing intimate details of such security holes was to protect customers who had yet to receive and install the patches (though we did try to ensure that they were distributed as quickly as possible, especially given the broadcast details of the ftp hole). It seemed to make sense to me at the time. Then again, I was privy to the details so I didn't have that pressing desire to know what the security holes were. I'm not involved in any work on HP-UX or networking anymore, but I do like to learn from the past. In this particular case (the sendmail/ftpd patches -- I don't know the details of your current problem) what sort of approach would you rather have seen us take? Regards, Jerry McCollom jmc@cnd.hp.com ----------------------------------------------------------------------- This response does not represent the official position of, or statement by, the Hewlett-Packard Company. This response is provided for informational purposes only. It is supplied without warranty of any kind. -----------------------------------------------------------------------
mck@hpcuhc.cup.hp.com (Doug McKenzie) (02/28/91)
Ton writes: > "I expect to be warned by Hewlett-Packard for possible security problems > in my HP-systems just like I expect the manufacturer of my car to warn > me if the brakes are not safe." Jim responds: > This is rather naive. Most computer companies (and HP in particular) > will not discuss security problems with their software or notify their > customers when security holes/bugs are found. In most cases, they hide > behind the feeble excuse of "company policy". This also lets the > company get away with doing nothing - what customers don't know > about can't worry them. It also means the company decides what > security problems you need to know about, regardless of whether they > are important to you or not. Mr. Computer Vendor knows what's best for > you so just trust him.... Edwin responds: > Ok, how to distribute the bad news?? Well, first of all, details > shouldn't be spread of course. A simple message like: ``There is a > serious problem with this_and_that on systems X, Y and Z, running > AA-BB p.qy and higher. We urge you to contact your local CRC for further > information''. Warning of security holes is tricky. Our "policy" is to look at each problem separately -- there is no algorithm. We generally try to correlate the announcement of a security hole to the size of the hole. If it's an extreme corner case, then we make no mention. If it seems likely to occur more frequently, we publicize it. The problem is, just mentioning that there is a problem causes people to look. Let me try another car analogy: if Porsche discovered that certain Toyota ignition keys would work on the Porsche, what should Porsche do? If they announce, "please contact your dealer", and the dealer tells everyone of the problem, it would be public knowledge within hours and far more people would be at risk. Is everyone who hears the broadcast entitled to full information? I'd be hesitant to install a patch unless I knew why I needed it. Patches cannot receive the full amount of interoperability testing that the original release does, because it's not possible to test all the combinations of patches for untoward interactions. By the way, the problem Ton refers to *was* publicized, because it seemed it might not be such a rare occurrence. It's KPR number 1650126268, which appears in the SSB dated 16 Dec 90. I'm a little hesitant to mention this, as there is more detail than I would have liked in the SR. (And now having mentioned my hesitation, some people might look it up who otherwise might not care.) It's been fixed in 8.0 of course. No company wants to broadcast that their systems have a security problem. But it's more than image manipulation; customers can also suffer from the broadcast. Ton, I'm sorry for the trouble it caused you. Doug McKenzie S800 HP-UX Support mck@cup.hp.com or ...hplabs!hpda!mck Disclaimer: I do not speak officially for HP.