Running a mail list archive is a straight forward task. Collect, organize and make mail list posts available via the web. You can see such archives at seclists.org or the Neohapsis arhive. Most folks that use archives like this have their favorites for various reasons. Speed, the lists they archive, or the organization usually. Most archives use a system where the URL to the post is logical and somewhat informative. Looking at the URL to the latest Bugtraq post archived at Neohapsis:
http://archives.neohapsis.com/archives/bugtraq/2005-10/0259.html. We see the mail list name, the year and month, and a unique number for the post. Bugtraq, 2005, October, 259th post. Simple and easy!
SecurityFocus maintains an archive of the mail lists they run. Until a couple months ago, they used a scheme that wasn’t very informative. A sample URL http://www.securityfocus.com/archive/1/245152 shows it doesn’t help us discern anything about the post. Annoying, but oh well, most people could live with it. A month or two ago, SecurityFocus decided to revamp their system which would also impact their entire archive. They made assurances that the changes would be transparent and that old URLs would work. As I predicted to one SF employee, it didn’t work out so smooth, and many of the old URLs did not translate properly. At first he doubted me, then asked for examples. After providing half a dozen he saw that it wasn’t a fluke and that something had gone wrong. Unfortunately, whoever he shared that information with didn’t act on it. What is more annoying, and more damning, is that SF implemented a new scheme that is just as bad as the old one. Look at an example of their new scheme:
http://www.securityfocus.com/archive/1/414100/30/0/threaded. This URL doesn’t tell us anything about the mail list or post either.
Why does this matter? There are hundreds of Nessus plugins that reference these old URLs, and in some cases only reference mail list posts, via the SecurityFocus archive. Clicking these now leads to .. no information. There are also countless CVE entries that reference the old URL scheme. If you want to see the original point of disclosure, you are forced to visit another database (that competes with SecurityFocus) such as ISS X-Force or OSVDB to see a valid link, as they choose to reference mail list archives that are more friendly to users.
In short, if you maintain a security product or database, please do not reference SecurityFocus or any other archive that uses an obscured scheme, or has intentions of changing their scheme.
This paper is an advisory but mostly it describes a mistake made by Microsoft on patch MS05-018 where Microsoft failed to properly fix a vulnerability having to release a new patch MS05-049. Hopefully this paper will open the eyes to software vendors to not repeat this kind of mistakes.
As you have seen Microsoft did what you never have to do, Microsoft failed to build a good fix thus losing a lot of money and time, also Microsoft make users to lost time (maybe also money if you think time=money) since users have to patch again what they have already patched. I personally have seen Microsoft improvements on all aspects of security over the last years, but I think that Microsoft still needs some fine tunning on the patching process in order to avoid this kind of mistakes. I also must say that Microsoft is 1000% better than Oracle at handling and patching vulnerabilities.
Several years ago, iDefense started purchasing vulnerabilities from freelance researchers, and created its Vulnerability Contributor Program. Find a vulnerability, disclose it to iDefense under mutual NDA, and they would act as a mediator between you and the vendor for disclosure. After a patch was available, iDefense releases an advisory and pays you. Ignoring the fact that they would sit on the information for up to a year before disclosing it to the vendor, this program rewarded people for finding and disclosing vulnerabilities.
Months back, David Endler left iDefense to join Tipping Point, a division of 3Com. Shortly after, TP announced its “zero day initiative”. Like iDefense, the ZDI would pay for vulnerabilities, but also created a ‘loyalty’ program for continuing to disclose vulnerabilties through them (wonder if they give out keychain thingies like my grocery store does?).
Now, Digital Armaments is also offering a “pay for vuln” program. Instead of just offering cash for 0-day, they also offer trade-in credit so you can receive other 0-day in return for your own. This deviates off the path of “responsible disclosure” (questionable under the other two models) quite a bit.
I’ve spent the last few hours working on the OSVDB database, specifically working on making sure that we had entries that correspond with two vendors and their security issues. After an hour or two of digging through the Hitachi advisories, I questioned why we only had ~ 20 entries when there were closer to 80 advisories. Ends up many of them cover vulnerabilities that impact a wide variety of platforms such as Microsoft vulns, OpenSSL or other more commonly deployed cross-platform packages. Unfortunately, Hitachi’s security team didn’t have the common sense to include links to the original advisories OR links to the CVE numbers in many cases, making my job extremely difficult. And yes, I leave feedback on vendor advisory/KB pages “was this helpful” boxes. And yes, we make an effort to include their advisories on the related entries.
Next, I moved to BEA and the WebLogic mess. Historically, I like Macromedia/BEA as they have been open and honest about vulnerabilities for many years. They don’t seem to try to hide the fact their software has bugs, and they release advisories with detailed patch information. While the actual vulnerability information may be a bit vague, I fully understand the fact that they will release the most basic information and appreciate they do so to protect customers. I think that it is extremely important in this day and age to do so. That said.. I am making BEA my example for this post. Apologies, but you deserve it (was re: please, learn from this rant!)
Like many vendors, BEA maintains a security advisory page. Release date, advisory number, title, products affected. This gives more summary information than most, and on first impression seems very helpful and thorough. However, to the anal retentive and compulsive VDB maintainer, it is a nightmare. Go ahead, look at it again.. what’s wrong with it?
First, look at their advisory IDs. Second, look at the links to their advisories and the resulting URL you would get if you clicked:
http://dev2dev.bea.com/pub/advisory/138 – BEA05-87.00
http://dev2dev.bea.com/pub/advisory/139 – BEA05-80.02
http://dev2dev.bea.com/pub/advisory/140 – BEA05-85.00
http://dev2dev.bea.com/pub/advisory/141 – BEA05-86.00
http://dev2dev.bea.com/pub/advisory/142 – BEA05-88.00
http://dev2dev.bea.com/pub/advisory/143 – BEA05-89.00
A nice logical progression in advisory numbers.. 138, 139, 140, yet the BEA advisories go 05-87, 05-80, 05-85. Why don’t these correspond? Ok ok, minor annoyance I know, but when you are trying to create a timeline to help you verify you have every advisory in a database, it sucks. Now, for the real sin! Look at the HREF links from the list of advisories, to the URLs (remembering that the URLs are like the ones quoted above).
2005-08-15 | BEA05-61.01 | A patch is available to prevent Denial of Service attack
2005-05-24 | BEA05-82.00 | Denial of Service attack
Yet these link to 134 and 132. Where is 133? Almost three months between these, and they skipped 133? No, they didn’t.. follow the link to one of those two, but manually change the URL and voila, advisory ‘133’ is there (do this in other parts, and there isn’t an advisory at all, just a big gap..). Why doesn’t BEA include that link on their page? Scroll up through the advisories, and look at the links as you mouse over. Notice the other missing advisories? 123, 124, 130, 133 .. where are you?
BEA (and countless other companies), you are making life hell on your customers that pay attention to detail (and us anal retentive folk that run VDBs). Please, use some basic logic and common sense when ordering or numbering such advisories. If you skip numbers, put in a brief note explaining that it is intentional. It shouldn’t be too dificult to have one or two people that coordinate the disclosure efforts, and they should not have problems that may cause this kind of mess. If you don’t explain these gaps, your paying customers are going to want to know what you may be hiding.
I had planned on writing about this weeks ago but got swamped with that pesky day job along with the steady stream of new vulnerabilities released daily. That steady stream that absolutely will not get better with vendors taking a new approach to dealing with them. Fortunately for me, John Dvorak wrote an article and voiced some of my opinion as well. This comes some three years after Richard Forno wrote a related piece.
The Microsoft Protection Racket
By John C. Dvorak
Does Microsoft think it is going to get away with charging real money for any sort of add-on, service, or new product that protects clients against flaws in its own operating system? Does the existence of this not constitute
an incredible conflict of interest? Why improve the base code when you can sell “protection”? Is Frank Nitti the new CEO?
So what is actually going on here? I think there were some bottom-line questions that must have been brought up internally. Obviously someone at Microsoft looked at the expense of “patch Tuesday” and asked, “Is there any way we can make some money with all these patches?” The answer was “Yeah, let’s stop doing them and sell ‘protection’ instead.” Bravo! And now the company has a new revenue stream.
What Dvorak doesn’t mention that is just as important, is that Microsoft is not the only one doing this. A colleague recently pointed out that Symantec is offering IDS/IPS solutions for their own software. So instead of truly patching a vulnerability, they can quickly write a rule/filter to stop attacks against a specific/known attack. While this is often effective, history shows us that such solutions often fall victim to being bypassed with crafted requests, altering exploit code or using various evasion techniques.
SYM05-011 – August 12, 2005
VERITAS Backup Exec for Windows Servers, VERITAS Backup Exec for NetWare Servers, and NetBackup for NetWare Media Server Option Remote Agent Authentication Vulnerability
8/12/2005 – Revision One – updated details, affected products and response information.
8/12/2005 – Revision Two – Adding Tech Support links to currently available product updates as tested and posted for download by Symantec engineers. Link to IDS/IPS signatures for Symantec Security products.
8/13/2005 – Revision Three – Added Tech Support link to additional product updates. All supported affected products have updates available now.
8/14/2005 – Revision Four – Added links to IDS/IPS signatures for additional security products. All relevant Symantec Security products have signatures available now.
Again, what is the motivation/incentive for a vendor to patch a vulnerability, when they can just as easily ignore it, and spend time developing a profitable workaround or additional product?
Developers ‘should be liable’ for security holes
Tom Espiner, ZDNet UK
October 12, 2005, 12:15 BST
Software developers should be held personally accountable for the security of the code they write, said Howard Schmidt, former White House cybersecurity advisor, on Tuesday.
“In software development, we need to have personal quality assurances from developers that the code they write is secure,” said Schmidt, who cited the example of some developers he recently met who had created a Web application to talk to a back-end database using SSL.
XSS Virus Whitepaper
The following paper explores the new threat of cross-site ing (XSS) viruses. To date, cross site ing has never been utilised to generate viruses. These viruses are a new species which are platform independent and not affected by common firewall configurations. XSS viruses could have a significant impact for Internet continuity, including distributed denial of service (DDOS) attacks, SPAM and dissemination of browser exploits. This is particularly relevant with the increasing sophistication of web browsers and the growing popularity of web based applications such as Wikis and Blogs.
October has been named “National Cyber Security Awareness Month” by some. From a news article about this:
New York State, the University of North Carolina and the city of Charlotte, N.C., are joining the Department of Homeland Security, the National Cyber Security Alliance and numerous companies from the computer security industry to promote educational initiatives and free software giveaways to encourage the adoption of good cyber security practices in small businesses and citizens’ homes.
While security alliances, states and cities are grabbing their pom-poms, i’ll play the role of cynic. This awareness month means nothing to security companies and software developers that practice good security year round. As the article says, this awareness month is for businesses and end users which is good in theory. But will it help? You can answer this yourself actually. Find a friend or neighbor and ask them what other things we are supposed to be ‘aware’ of in the month of October. If your friend can’t remind you that it is National Breast Cancer Awareness Month, Domestic Violence Awareness Month, Down Syndrome Awareness Month, National Disability Employment Awareness Month, Energy Awareness Month, or Lupus Awareness Month, then this awareness month may fail too. Did you know there were more? Check out this great list of “Bizzare, Crazy, Silly, Unknown Holidays & Observances in October”.
From: Steven M. Christey (coley @ mitre.org)
To: bugtraq @ securityfocus.com
Date: Tue, 4 Oct 2005 17:11:51 -0400 (EDT)
Subject: A common researcher diagnosis error: misreading error messages
I am seeing increasing numbers of reports by researchers who make the same diagnostic error that you just highlighted. They throw some input for one vuln type at an application (say, XSS manipulations), get an error that shows “XSS,” and completely miss the fact that the error message shows a more serious problem at play, such as SQL injection or directory traversal. The XSS is “resultant” from these other “primary” errors.
Similarly, just because you throw a long input at a program and the program fails, it doesn’t necessarily mean that you found a buffer overflow. You could have triggered a memory allocation error; or the program didn’t recognize the argument as a valid argument; or it spotted the long input and returned a null pointer, but forgot to check and led toa null dereference; or multiple other reasons.
For those researchers who care about quality of information, make sure that you interpret error messages correctly, especially if you’re using some generic attack program that throws a lot of junk at an application. Error messages are important clues, but not the whole story.
Vulnerability information analysts – e.g. for vulnerability databases and scanning tools – should be vigilant for these common diagnostic errors.
In this particular instance, it doesn’t help that PHP’s error message generators don’t seem to quote the error messages that are generated, so a lot of “XSS-as-symptom-but-not-cause” problems are reported for PHP apps. Whether this is a problem with PHP itself or not is a separate question.
The Web Application Security Consortium (WASC) is announcing the availability of the Web Security Threat Classification in English, Japanese, Spanish, and Turkish. The material is open source and provided in TXT, PDF, and DOC formats.