Posted by jericho
Fri, 06 Jan 2006 10:46:14 GMT
In the context of advisories, it’s simple, to help track documents and avoid confusion. Much the same reason a vulnerability database assigns a unique number to an issue. If there is confusion when discussing a vulnerability, you reference the unique ID and ideally, confusion goes away. That said, why does Hewlett-Packard feel the need to assign multiple tracking IDs to a single document/advisory?
HP-UX running WBEM Services Denial of Service (DoS)
http://archives.neohapsis.com/archives/bugtraq/2005-12/0231.html
So this is “SSRT051026 rev. 1”, “Document ID: c00582373”, and HPSBMA02088. Three drastically different tracking numbers for the same document. Fortunately, all three were referenced in the same place this time, but still.. why must vendors do this?
Posted in Vulnerability Disclosure | 2 comments
Posted by jkouns
Mon, 02 Jan 2006 07:54:47 GMT
The argument that Vulnerability Databases (VDBs) are evil because they provide the bad guys all of the information on how to hack has gone on for quite some time. Of course, this debate crosses over into the Full Disclosure argument, which asks the question, should the information be public at all? But for VDBs, the real question should not be about whether to provide information on vulnerabilities, but how specific the information cataloged should be?
Some believe that providing exploits or tools to make it easier to exploit a vulnerability is where it crosses the line on providing too much information. While there may be a few valid points on the topic, the real issue, in my opinion, is when resources provide vulnerability information in the context of a specific site/domain.
VDBs are not the only resource that may have site specific vulnerability information. Many search engines such as Google/Yahoo have come under fire as being a collection of security information to assist attackers. In fact, it could be argued that the search engines pose greater security disclosure problems than a VDB, since a search engine takes an attacker immediately to a vulnerable website. There is even a whole site (and following) centered around using Google to quickly find specific vulnerable software on web sites.
OSVDB has a policy that we do not catalog site specific vulnerabilities, and we make all efforts possible to avoid these entries being added to the database. In fact, quite a few VDBs follow this same practice. However, some VDBs will include sites specific vulnerabilities only for high profile websites. For example:
XSS vulnerabilities in Google.com
http://www.watchfire.com/securityzone/advisories/12-21-05.aspx
Google GMail ‘CheckAvailability’ Script May Disclose User Information to Remote Users
http://www.securitytracker.com/alerts/2004/Jul/1010647.html
Yahoo! Mail ‘order’ and ‘sort’ Field Input Validation Flaw Permits Cross-Site Scripting Attacks
http://www.securitytracker.com/alerts/2004/Mar/1009352.html
It is important to note that certain advisories make it very hard to determine if the issue is in a product or on a website. Recently, we have seen what appears to be more site specific issues being released by researchers. For example:
SpearTek Search Field Handling Cross Site Scripting Vulnerability
http://www.frsirt.com/english/advisories/2005/3052
There appears to be quite a few advisories released by r0t that may fall into the site specific category. If you look on r0t’s site, anything that says there is a XSS vulnerabillity in the “Search Module” may very well be a vulnerability in the company website, not in the product–even though he lists version numbers in the advisory.
Considering VDBs such as OSVDB do not have the resources to verify all advisories, we must rely on the information provided, and in some cases site specific vulnerabilities make it into VDBs by accident. In fact, dozens of entries in OSVDB currently have internal flags on them as we try to determine if they are site specific.
Providing a company website or an online service that has a security issue is not something that OSVDB believes to be appropriate, even though many contributors personally find it extremely interesting, and believe it is valuable. Many organizations that rely on online services may find great value in knowing about an issue with their online email provider. The fact that many businesses use sites like Google, Gmail or Yahoo heavily suggests that vulnerabilities in the services are just as dangerous as vulnerabilities in the software deployed on their own network.
It may make OSVDB look incomplete compared to VDBs that include site specific vulnerabilities, but we are willing to accept that risk. The OSVDB project aims to provide useful information to help improve the level of security for the community, and site specific vulnerability do not fall in that category currently.
Posted in Vulnerability Disclosure | 3 comments
Posted by jericho
Tue, 13 Dec 2005 22:36:09 GMT
Yichen Xie and other Stanford researchers posted to bugtraq announcing “99 potential security vulnerabilities”, all SQL injections. Five issues/comments/questions come to mind:
- This sounds impressive, but even by OSVDB’s level of abstraction (significantly higher than other VDBs), this is far from 99 vulnerabilities. Looking at the phpWebThings SQL injections announced, we see:
ERROR: ./forum.php:@main: _GET#g[“direction”]
ERROR: ./forum.php:@main: _POST#g[“direction”]
ERROR: ./forum.php:@main: _GET#g[“sforum”]
ERROR: ./forum.php:@main: _POST#g[“sforum”]
ERROR: ./forum.php:@main: _REQUEST#g[“msg”]
ERROR: ./forum.php:@main: _GET#g[“msg”]
ERROR: ./forum.php:@main: _REQUEST#g[“forum”]
ERROR: ./forum.php:@main: _GET#g[“forum”]
By OSVDB standards, this is a single vulnerability (forum.php Multiple Variable SQL Injection). Even going one more level of abstraction and breaking it out by variable, we see that eight of these vulnerabilities are really four, just using different HTTP request methods. If any VDB were to break out such vulnerabilities, it would be interesting to see how it applied to the hundreds (thousands?) of previously disclosed SQL injections. Do researchers even check the different methods? In some cases, yes, but I have a feeling it is fairly rare.
Utopia NewsPro - 8 claimed - 5 actual
e107 - 16 claimed - 4 actual
myBloggie - 16 claimed - 11 actual (1 previously disclosed)
PHP Webthings - 20 claimed - 7 actual
DCP Portal - 39 claimed - 16 actual (5 previously disclosed)
Total - 99 claimed - 33 actual (6 previously disclosed) = 27 new vulns
- Some of the issues disclosed have already been reported. Of specific interest is the myBloggie login.php username Variable SQL Injection which was originally reported Sep 5, 2005, supposedly fixed, and found to still be vulnerable using a NULL character method. So, does Stanford’s PHP-CHECKER look for such variations, or is this a case of a false positive triggered due to the incomplete fix implemented?
Why does their tool find DCP Portal POST Method calendar.php year Variable (OSVDB 20494) vulnerable to SQL injection, but not POST Method register.php name Variable (OSVDB 20493) vulnerable? Seems like the vendor would have patched all or nothing, so finding one and not the other is suspicious.
Has the research team used it against other packages with a history of SQL injection problems to determine if it finds the same ones? Does it no longer find them on later versions, after vendor fix? In short, how robust and how accurate is this tool?
The top of the post says:
More detailed information, including proof of concept exploits (vendor notified, and since patched), about the tool can be obtained from the links below.
However, the DCP Portal vulnerabilities it found were disclosed as far back as Oct 1, 2003. Were they not patched correctly? The Stanford team says they tested 6.1.1, the vendor was notified, and the vulnerabilities patched, yet the vendor download page still shows 6.1.1 as current. PHP Webthings “1.4 patched” was tested, but the vendor download page still shows that as the current version and dated 07/05/2004. They tested e107 “v0.7” but didn’t indicate that 0.7 is “in development, available from CVS”, while 0.6172 is the current stable version. The myBloggie vendor page shows 2.1.3 beta is the current version, dated 15 Jun 2005, and the same version tested by Yichen Xie et al. Only one of the five programs tested (Utopia NewPro) has confirmation of a fixed version in the news update (”UNP 1.1.5 has been released to fix a few very minor security issues.”)
So where are the fixed versions for the rest?
- Is this tool going to be released? If so, to who? If not, why not? This tool in the right hands could potentially eliminate thousands of SQL injections in countless programs in a matter of weeks.
Posted in Vulnerability Disclosure | 2 comments
Posted by jericho
Tue, 13 Dec 2005 06:26:14 GMT
http://blogs.securiteam.com/index.php/archives/133
On “Responsible Disclosure”: Stripping the Veil From Corporate Censorship
Matthew - December 5, 2005 on 8:31 am | In Microsoft, Commentary, Full Disclosure, Law, Culture, Cisco |
[..]
In the case of 911302, the ‘report of a vulnerability’ Microsoft cites is information published by a British firm regarding the Window. Race Condition in its Internet Explorer browser. The catch that Microsoft fails to mention? The vulnerability had already been reported publicly after Microsoft discounted it as a non-exploitable flaw. The lag time between the two reports also hurts Microsoft’s case: the issue has been known since May, and the code execution possibility was reported in November.
So, in the case of 911302, Microsoft is complaining because it failed to consider the possibility that a class of race conditions (those that reliably produce calls to free portions of the virtual address space) that has historically proven exploitable would prove equally dangerous in this instance. Microsoft failed to do its homework, and then chastised the British firm (ComputerTerrorism.com) for exposing the company’s gross negligence in its handling of this vulnerability.
[..]
Posted in Vulnerability Disclosure | no comments
Posted by jericho
Fri, 09 Dec 2005 06:07:18 GMT
Late yesterday, Jaime Blasco posted to bugtraq looking for a security contact at 3com to further attempt to disclose a vulnerability in one of their products responsibly. Such posts are not uncommon these days, and one of the driving forces behind the OSVDB Vendor Dictionary. For vendors who may be under some delusion that their products contain no vulnerabilities, you should still maintain the security@ alias as per RFC 2142 standards. Ideally, we’d like for you to contact us with your preferred security address so our vendor dictionary is updated and accurate.
The irony of Blasco’s post is that 3com owns TippingPoint who runs the Zero Day Initiative (ZDI), set up to purchase 0-day vulnerabilities from researchers. Why do I think that had Blasco mailed ZDI, he would have received a prompt reply?
Posted in Vulnerability Disclosure | 2 comments
Posted by jericho
Sun, 20 Nov 2005 20:35:54 GMT
H D Moore recently wrote that he discovered several vulnerabilities in Google Search Appliances. You can find details of these on the Metasploit Vulnerability Page, as well as search OSVDB for the corresponding entries. Normally this wouldn’t be worth posting about, however Moore’s comments on the Google EULA and how it impacts vulnerability research is worth noting. From his mail:
I found some fun bugs in the Google Search Appliance and uploaded the results in preparation for a Monday morning release. To get an idea of how many affected systems there are, just Google for inurl:proxystylesheet. Google released a patch on August 16th and I agreed to wait at least 60 days past that before disclosing the bugs.
A warning to anyone who owns one of these appliances - the EULA and confidentiality agreement prohibit any form of security research or publication of results. After I reported the issue, their security team offered to send me a Mini for patch verification, but agreeing to the license terms would prevent me from publishing any information about the product in the future. I got a beach towel and shirt instead :-)
This also brings up why Google won’t publicly release their security advisories. Searching Google for “GA-2005-08-m” finds one reference to someone having problems with the latest patches, but no copies of the advisory. Seems Google is all about organizing and sharing world information.. unless it’s information on their own vulnerabilities? Oh wait, “the Google Search Appliance does not create security issues”!
Posted in Vulnerability Disclosure | 1 comment
Posted by jericho
Mon, 14 Nov 2005 13:56:18 GMT
The idea behind CERT-like groups is the responsible disclosure and handling of vulnerability information. NISCC, in their own words:
Welcome to the National Infrastructure Security Co-ordination Centre
A fundamental role for any government is to ensure the continuity of society in times of crisis. This often involves providing extra protection to essential services and systems to make them more resistant to disruption and better able to recover quickly.
NISCC has no regulatory, legislative or law enforcement role; it seeks to achieve its aim through four broad work streams:
Outreach. Promoting protection and assurance by encouraging information sharing, offering advice and fostering best practice.
Despite their claims of outreach, the Openswan project is calling this into question. From a post to the DailyDave mail list:
NISCC’s achievement this time:
- do not release vulnerability information to open source vendors prior to release. Just tell them they cannot have the information for 4 months.
- try to postpone another 3 months, but getting their hands forced by CERT-FI
- do not list vendors impacted in their announcement.
- do not request a CVE.
- give the public absolutely no information on the vulnerability and whether they are impacted or need to urgently upgrade or not.
Posted in Vulnerability Disclosure | no comments
Posted by jericho
Thu, 10 Nov 2005 11:05:13 GMT
When a security researcher finds a vulnerability, they may choose to release the details in a formal advisory. The different between a random post to a mail list and an advisory typically involves the level of detail and the amount of peripheral information to the vulnerability. This includes discovery date, vendor communication timeline, patch information, formal writeup and technical details of the vulnerability. Because advisories are used as marketing material as much (or more) as vulnerability research/disclosure, some security companies would rather use them to attract attention to their web site.
To do this, they may post a brief message to a mail list announcing the discovery of a new vulnerability and a link to the advisory on their web page. This may seem logical and understandable, but in the long run this does a huge disservice to the security community. What happens when the security company goes out of business or gets purchased by another company? Overnight, all of their advisories and research may disappear. Mail list archives will then contain no useful information and a dead link to a site/advisory no longer there.
This problem (and debate) goes back a ways, most notably in 2000 when Elias Levy (then moderator of Bugtraq) rejected a post from @stake because the vulnerability report did not contain enough information. Thomas Greene covered this incident and dug into the issue. Levy later cited his reason for rejecting the post, which touches on my previous post:
“For very long we have tolerated the marketing copy on vendor advisories because while annoying they were
accompanied by useful information. But in this change there is no value added to list subscribers. It’s for this reason that we are not accepting such advisories,”
For those of you who side with companies that post glorified advertisements without technical details, consider the following
quote from Levy:
“I’ve asked the list subscribers for their opinions. I’ve received over five-hundred messages to far. While a handful of people liked the notices, the large majority of them, probably around 95 per cent, found the change to be a negative one and want me to hold firm to the policy of not approving them.”
The ultimate irony here is the Levy work[s|ed] for SecurityFocus, who was purchased by Symantec, who also recently purchased @stake and subsequently removed the @stake advisories from the web site a few weeks ago.
Posted in Vulnerability Disclosure | no comments
Posted by jericho
Wed, 09 Nov 2005 07:40:59 GMT
Security advisories are a form of advertising. First and foremost, they are used to promote the technical capability of a security company and showcase the talent. If a researcher or company was completely altruistic, they would not release an advisory and would not care about credit if the vendor released an advisory. Releasing vulnerability information has been used as a form of marketing for over a decade, and it works for everyone. The company releasing the information gets free press, the security community gets vulnerability information in return. In recent years, many companies have relied on it for getting started and attracting their initial customer base.
With the full vs responsible disclosure debate a constant shroud hanging over security companies, they must be careful not to scare away potential customers by giving the impression that they don’t care about security or the repercussions of their disclosure. As such, many companies have taken a very strong stance on responsible disclosure, some arguably taking it too far.
One example of this strong stance is NGSSoftware who began witholding details of vulnerabilities for 90 days, in order for administrators to have plenty of time to patch the vulnerability. This is a good thing overall, and NGSS has set a good example showing that security companies can help the community while protecting them just the same. Of course, NGSS should make sure to release those details after 90 days, something they don’t always do in a timely fashion. An example of NGSS’ policy can be seen in their recent post to Full-Disclosure as well as their immediate followup. While vague, it does tell us that multiple vulnerabilities were found, what software they were found in, and what types of vulnerabilities they are. These correspond to information provided in the Oracle security bulletin and serve as a warning to the severity/importance of the vendor patch.
A few weeks ago, Integrigy Corporation took it too far in my opinion. In a posting to Full-Disclosure titled Vulnerabilities in Oracle E-Business Suite 11i - Critical Patch Update October 2005, they provided a four page summary of .. no vulnerability disclosure. The bulk of the post was to point out they had released analysis of the Oracle patches and what it could mean for customers. While this information is helpful, it is NOT disclosing a vulnerability in any fashion. The only thing resembling disclosure was the ‘credit’ section which states:
Some of the vulnerabilities fixed in the Critical Patch Update October 2005 were discovered and reported to Oracle by Stephen Kost of Integrigy Corporation.
This isn’t disclosing a vulnerability, and should not be posted to a list centered around full disclosure. The company name “Integrigy” appears 14 times in the post, and their company URL 3 times. They mention their products AppSentry and AppDefend a total of four times.
Argue all you want, but this is blatant advertisement, not a security advisory.
Posted in Vulnerability Disclosure | 3 comments
Posted by jericho
Wed, 05 Oct 2005 19:46:42 GMT
Software Bugs: To Disclose or Not to Disclose
October 3, 2005
Kenneth van Wyk
http://www.esecurityplanet.com/views/article.php/3553196
It’s the age-old battle of security: to disclose or not to disclose software defects.
The proverbial pendulum of opinion has been swinging back and forth on this issue for decades, and it’s not likely to stop any time soon. The issue reappeared just recently when an ISS employee was prohibited from speaking at a conference on the topic of a security vulnerability in Cisco’s IOS operating system.
Here’s my take on it…
[..]
Kenneth van Wyk, a 19-year veteran of IT security, is the prinicpal consultant for KRvW Associates, LLC. The co-author of two security-related books, he has worked at CERT, as well as at the U.S. Department of Defense.
Posted in Vulnerability Disclosure | no comments
