Posted by jericho
Tue, 15 Nov 2005 05:36:03 GMT
From: nvd@nist.gov
To: Multiple recipients of list (nvdupdate@nist.gov)
Date: Mon, 14 Nov 2005 14:03:33 -0500 (EST)
Subject: National Vulnerability Database (New Vulnerability Outage)
There has been a serious and unexpected failure with the National Vulnerability Database (NVD) and Common Vulnerabilities and Exposures (CVE) vulnerability processing system. While all newly discovered vulnerabilities are being processed internally, these vulnerabilities are not being added to CVE or NVD. Due to the nature of the problem, it may take several days before the situation can be resolved. At that time, you will see a surge in vulnerability publication activity as we catch back up.
We apologize profusely for the outage and assure you that this will never happen again. We take our job of providing a timely and comprehensive vulnerability service very seriously and we are working hard to constantly improve the service for you.
Posted in General Vulnerability Info | 1 comment
Posted by jericho
Fri, 04 Nov 2005 12:11:34 GMT
I recently made a post titled Mail List Archives 101 (or why SF hates VDBs) commenting about the restructure of the SecurityFocus mail list archive. In short, it’s a bad thing. Unfortunately for many people, especially vulnerability databases, this is happening more and more, on various sites. Instead of an isolated event and one blog entry, now it seems I may want to start keeping a list. This time, welcome Mandriva Linux to the list.
Up until Apr 6, 2005, Mandrake Software used a standard URL for accessing advisories, which now gives a 404 of sorts:
http://www.mandrakesoft.com/security/advisories?name=MDKSA-2005:072
Sometime on or around Apr 6, 2005, Mandrake Software became Mandriva, and offered the advisories on a new URL:
http://www.mandriva.com/security/advisories?name=MDKSA-2005:122
Checking that URL now will redirect you to the generic advisory page:
http://frontal2.mandriva.com/security/advisories
Now, new Mandriva advisories are distributed with a URL like this:
http://frontal2.mandriva.com/security/advisories?name=MDKSA-2005:204
Databases that have been referencing MDKSA advisories the past five or more years are now left with several hundred links that 404 or redirect to the main security advisory page (more recently). Not a good move Mandriva/Mandrake. Since the advisory ID remains the same, the least you could have done is set up more friendly redirects for the old advisories/domains. Jerks.
Posted in General Vulnerability Info | 1 comment
Posted by jericho
Fri, 04 Nov 2005 11:06:36 GMT
I know the title of this may seem to be a slight on the researches I will use as examples, but that is not the case at all. Some people in the security community have a perception that some vulnerability researchers are so-called “one trick ponies”, meaning they know one trick and are not able to offer diversity or research different types of issues.
In some cases this might be accurate, as the ability to test and “research” vulnerabilities such as cross-site ing takes nothing more than a simple cut/paste and witnessing a resulting pop-up. Other researchers may know the basics of overflows or format strings, but not know how to exploit more tricky occurances. Even so, these people show that countless programs, even recently developed ones, continue to suffer from the same old weaknesses we’ve seen over the last twenty years. They show that many programmers still don’t get it, don’t learn from history, and do not practice secure coding techniques.
In other cases, some researches stick to what they do best, and it isn’t a lack of proficiency affecting their results. Like them or not, their efforts do serve a good purpose and they have good intentions.
Secunia and “archive handling” issues.
Lostmon and XSS
Luigi Auriemma and games
Alexander Kornbrust and Oracle
Posted in General Vulnerability Info | 1 comment
Posted by jericho
Sun, 23 Oct 2005 09:47:22 GMT
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.
Posted in General Vulnerability Info | 6 comments
Posted by jericho
Sat, 22 Oct 2005 05:05:12 GMT
Cesar Cerrudo of Argeniss Information Security recently posted announcing the release of a new paper titled “Story of a dumb patch”.
Abstract:
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.
Conclusion:
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.
Posted in General Vulnerability Info | no comments
Posted by jericho
Thu, 20 Oct 2005 12:43:18 GMT
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.
Posted in General Vulnerability Info | 1 comment
Posted by jericho
Thu, 13 Oct 2005 14:37:58 GMT
http://www.securiteam.com/securityreviews/6H00D0KEAY.html
http://www.bindshell.net/papers/xssv.html
XSS Virus Whitepaper
SUMMARY
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.
[..]
Posted in General Vulnerability Info | 4 comments
Posted by jericho
Sat, 08 Oct 2005 06:06:23 GMT
http://archives.neohapsis.com/archives/bugtraq/2005-10/0025.html
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.
Posted in General Vulnerability Info | no comments
Posted by jericho
Thu, 06 Oct 2005 08:42:05 GMT
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.
http://www.webappsec.org/projects/threat/
Posted in General Vulnerability Info | no comments
Posted by jericho
Wed, 28 Sep 2005 04:51:40 GMT
A Day in the Life of a Security Bulletin
http://blogs.technet.com/msrc/archive/2005/09/28/411635.aspx
Hi all- Alexandra Huft here again! I thought you might find it interesting to see “behind the scenes” of how a security vulnerability eventually becomes a security bulletin.
So, I’ll start way back at the beginning. We receive reports from many different finders on issues that may or may not be a vulnerability. The first thing that we do is work to determine that we are able to duplicate what the finder has reported. Sometimes this is very simple, other times we need to go back to the finder for additional information, but whenever possible we try and recreate what they’ve discovered with our own research. We work with the affected product teams and our own experts on the Secure Windows Initiative team (SWI) to reproduce these reports. We also try to keep the finder updated with as much information as we can provide, so that they are aware of where we are in the process. We then work on determining the severity, which is not always the easiest thing. Like you, we all have our opinions, which lead to many a heated discussion in the MSRC Situation Room where we meet several times a week. We all want the best decision for all of our customers.
[..]
I’d be interested in seeing the same topic covered by Sun Microsystems, HP, Oracle and other vendors with large product bases.
Posted in General Vulnerability Info | no comments
