On an otherwise normal day of Unix fun, you discover a security bug on one of your systems. A minor bug, or perhaps much worse. A bug that someone could exploit to gain access to your systems, networks, and/or proprietary data. A dangerous bug.
You test the bug, duplicating the results from before. Yep, it's a keeper. The real thing. You collect all the necessary data (see below), and ship it off via e-mail to your Unix vendor (also see below). The anticipation mounts. You've discovered a bug, and it will be OK: Your vendor will fix it. You relax a bit.
An automated reply comes back from the vendor's security alert e-mail alias. The reply gives you a tracking number, perhaps, and some information on the process. Stay tuned, says the message: If it's a bug, we will fix it. We will be in touch. You relax a bit more.
Then...silence. Nary a word. No more status updates. What is going on? Days pass. Still no word. You begin to think the worst. You start to believe that your bug report has gone to the great /dev/null in the sky. You lose hope.
SO WHAT ARE YOU GONNA DO ABOUT IT, MR. UNIX VENDOR?
The paragraphs above summarize a common misconception: That Unix vendors are lethargic and apathetic about security bug reports. The silence you might have "heard" is simply proof that nothing is being done, and that the vendor does not care. Not true!
Any Unix vendor follows a specific process for the care and feeding of security bug reports. Here, for example, is the process followed by one such Unix vendor, Hewlett Packard:
Hewlett Packard S/W Security Problem Resolution Process Overview
Hewlett Packard (HP) has put in a place an internal process to handle S/W security problem resolution. The process begins with a message sent to the email node security-alert@hp.com, and a customer can initiate the process with the submittal of an SR (Service request) to HP by a customer that is marked "critical" and the word "security" in the text. Always make sure that the security-alert@hp.com email node is notified. The email is monitored by multiple HP personnel during working hours Pacific and Rocky Mountain Time. CERT is also a source of potential security problems via encrypted messages sent to identified members of the HP security team that CERT has met face to face. HP is also a member of FIRST (Forum of Incident Response and Security Teams) and receives potential security problems from fellow team members via encrypted messages. The following steps in a documented process occur upon receipt of a potential S/W security problem:
The output of the action plan is typically a Security Bulletin issued to the email subscriber list called "security_info" for both HP-UX and MPE operating systems (or it can be an Advisory or a workaround). The HP-UX security patches referenced in the Security Bulletin are available via the HPSL email server. In some cases for MPE, a tape with the security patch and a cover letter is usually pushed to the customer base. In either case the fix is always available from the HP Response Centers. All HP-UX patches are md5 checksummed.
Hewlett Packard's HP-UX patches/Security Bulletins/Security
patches are available via email and/or WWW (via the browser
of your choice) on HP Supportline (HPSL).
The steps detailed above are not frivolous. Rather, they are designed to insure that bug fixes do not introduce MORE bugs. A quality bug zapper is a happy bug zapper!
Be aware, as well, that the vendors must prioritize the issues they receive. Just like a typical system admin's day, the vendors must pick and choose between what is HOT and what is warm. The difference? Unlike a typical system admin, the vendor can not send out e-mail with the Top Ten Security Bugs to Fix. That would only lead to massive exploitation of what might have been heretofore unknown security issues. The only option is to sit back and trust that the vendor is prioritizing the issues with the good of all customers in mind.
SO WHAT TAKES SO LONG TO FIX MY SECURITY ISSUE?
Another common misconception or complaint is the timeliness of bug fixes. Hey, what takes soooo long? Well, consider this: I once rewrote /bin/su for a client. It took me a few days and some cups of coffee, and I was done. Simple, right?
Now consider the differences between me and a major Unix vendor. What I create does not have to come with any warranty (GNU license, natch). What I create does not necessarily have to be backward compatible with several OS releases. What I create won't necessarily be utilized by thousands of customers and sites (well, not yet anyway... ;-). In short, no Unix vendor can create even a minor security fix on an AS-IS basis. It requires many hours of testing, coding, re-testing, and documentation to create even the tiniest or most minor security bug fix. It has to be RIGHT. It has to be SEAMLESS. It MUST work. And it must not introduce more bugs. And it might take some teamwork...
THE VIRTUAL SECURITY TEAM
Although the major Unix vendors are rivals in the marketplace, they are partners when it comes to security. They will come together to discuss common security bugs and issues that may affect them all. They will work with CERT and AUSCERT to ascertain the degree of danger a security bug may pose. They SHARE information, just like the Black Hat community.
Consider the recent rash of X11 holes. These were mostly linked to a set of problems in the X11 libraries -- something common to most Unix vendors. By pooling their information and resources, the vendors are able to work these security issues as a community. The vendors can then warn each other of impending security issues. They are a much closer community than you might have thought...
OK, WHAT CAN I DO TO HELP?
First off, TEST the security bugs you find! Spend the time up front to insure that you have actually discovered a potential security bug. Ask your fellow admins to check your results. Many "security bugs" are introduced by the environment or user community. However, if you are not sure, REPORT IT! Better safe than hacked.
Second, give the vendor something to work with! Details of your bug or exploit are necessary, of course. However, some other key bits of information can be very helpful as well:
Third, notify both CERT and AUSCERT, as well. The security bug might warrant a CERT/AUSCERT advisory. CERT and AUSCERT will work with the vendor to coordinate such an advisory, if needed.
Fourth, be discreet! Now, having typed that, I must state that I am NOT a fan of the "security through obscurity" philosophy. However, you can use this information with discretion. Posting it to lists such as Bugtraq may result in someone using the exploit posted by you against YOU! Worse, it may result in some Black Hat attacking an un- prepared site. Use your common sense here. Think: Would you want someone to post an exploit that rendered your systems and networks defenseless?
The vendors, however, are trying to spread the word and collect the information! Take, for example, this posting from Sun Microsystems:
Command - Information Returned/Action Taken
_______ _________________________________
help - An explanation of how to get information
key - Sun Security Coordination Team's PGP key
list - A list of current security topics
query [topic] - The email is treated as an inquiry and is forwarded to the Security Coordination Team
report [topic] - The email is treated as a security report and is forwarded to the Security Coordinaton Team. Please encrypt sensitive mail using Sun Security Coordination Team's PGP key
send topic - A short status summary or bulletin. For example, to retrieve a Security Bulletin #00138, supply the following in the subject line (not body):
unsubscribe - Sender is removed from the CWS mailing list
----------------------------------------------------------------------------
As you can see, the information is out there. You simply need to access it.
I HAVE A SECURTY BUG WITH VENDOR X. TO WHOM DO I REPORT IT?
For Sun security issues, report it to:
security-alert@sun.com
For HP security issues, report it to:
security-alert@hp.com
For SGI security issues, report it to:
security-alert@sgi.com
For IBM security issues, report it to:
ers@vnet.ibm.com
For DEC security issues, report it to:
rich.boren@cxo.mts.dec.com
For CERT, report it to:
cert@cert.org
For AUSCERT, report it to:
auscert@auscert.org.au
I think the best thing to take away from this article is that the Good Guys, or White Hats, can join together and share information just as the Black Hats do. It is important that all of us (admins, vendors, security folks, end users) share as much information as we possibly can. We need to keep each other informed and in the loop.
Take the time to give your vendor as much info as you can. Vendors should then reciprocate with timely responses and as much detail as legally and ethically allowable. By sharing our knowledge and pooling our resources, we can make some serious strides towards a more secure computing environment. Good Karma!
GIVING THANX
Thanx goes out to Chok Poh of Sun Microsystems, Rich Boren of DEC, and Miguel Sanchez of SGI (and their respective teams) for the review and/or input.
Special thanx goes out to Dan Grove and crew at HP for their review, input, and especially Dan's assistance in putting me in touch with other key folks.