What is the oldest documented vulnerability? As far as OSVDB is aware, it’s a tie between UNIX-V6 su File Descriptor Exhaustion Local Privilege Escalation and Sendmail Unspecified Multiple Security Issues (yes, we’d love to know the details of the Sendmail issues back then!). These were documented on August 23, 1981, well over 24 years ago.
I’m sure there are vulnerabilities that were discovered and published before that. Does anyone have a copy of the old “Unix Bug List“? Some old t-file or email with an ancient vulnerability? Perhaps a changelog for a product as venerable as Sendmail? We want it, and we’ll reward you for it…
I’m not exactly sure what the reward will be yet. Maybe a gift certificate from one of your favorite shops, maybe some OSVDB swag, maybe something a little more silly, who knows. The rules of this contest:
- The information must be somewhat specific. Sendmail can get away with ‘multiple issues’ and remain vague due to the extensive history behind the program. We need to know some detail about the vulnerability. “BSD 0.83beta had a vulnerability” will not cut it.
- The vulnerability must be documented somewhere. No stories or second hand accounts will work. Changelogs, advisories, email or anything else that can help authenticate it is required.
- It must be a solid vulnerability. Concerns, weaknesses and best practices won’t work.
- Lastly, it must pass the general ‘BS’ test. If our cynical minds detect shenanigans, it doesn’t count.
That’s it! So, beat our two entries from August 23, 1981 and grab a minute of fame on this blog, our appreciation, bragging rights, and whatever reward we come up with. Mail submissions to moderators at osvdb dot org.
OK, OSVDB is not really closing. But based on my experience with running and participating in projects and sites, the second you announce a valuable resource is going away, people come out of the woodwork to volunteer or support the project to keep it going. When the Attrition.org Defacement Mirror closed, I received several dozen mails asking, begging, even demanding that the project keep running. So why didn’t these same people help out for the years prior to the announcement? If a project or resource is that helpful and that valuable to you, why not support them?
Without going into a full rant or debate on the nature of open source (OS), one of the most prevalent arguments for OS is that the community can help. For OS code, it is argued that anyone can look at the source code and find bugs.. but they rarely do. For OS projects, it is argued that volunteers work on projects for the love of it, not because it’s a source of money for food and shelter.. but they often don’t.
That said, OSVDB could substantially benefit from one or two developers before any such closing. Ideally we need a couple folks with solid PHP coding experience, PostgreSQL database manipulation, and the willingness / desire / time to work on the project. We can promise you fortune and fame! OK not really. What we can offer you:
- The ability to develop and enhance the project in a leadership role (we’ll even call you ‘god’ if you want)
- The chance to significantly change the vulnerability database landscape (yes, really)
- Work on a number of long term development projects (we have ideas, you have skills!)
- The freedom to work when and how you want, with little to no supervision (go wild)
Often times you will see a VDB or researcher disclosure offer the solution “Edit the source code to ensure that input is properly sanitised.” I’ve never been fond of this for several reasons. First and probably the most obvious, duh? If I proclaim “send food to the hungry”, have I now provided a solution for world hunger? No need to debate semantics or definitions, the bottom line is I haven’t (or we wouldn’t have the problem anymore). So offering a solution of “editing the source to sanitize input” is about as helpful as my solution. Second, if the solution was really so easy, wouldn’t the developers have done it in the first place? Couldn’t we apply such advice to all programs from all projects? Third, most users and administrators don’t have the programming experience to make such source code changes. Even if they did, most simply don’t have the time to edit every package they may use, let alone fully test their changes and ensure functionality and security.
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.
Yichen Xie and other Stanford researchers posted to bugtraq announcing “99 potential security vulnerabilities”, all SQL injections. Five issues/comments/questions come to mind:
1. 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
2. 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.
3. 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?
4. 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?
5. 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.
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?
A couple days ago, “fearwall” created an eBay listing for a “Brand new Microsoft Excel Vulnerability”. I have mirrored a screenshot in case the listing is removed, which I expect it to be. One has to wonder if companies like iDefense or Tipping Point will bid, since they (and others) purchase vulnerabilities. Full text of the auction:
The lot: One 0-day Microsoft Excel Vulnerability
Up for sale is one (1) brand new vulnerability in the Microsoft Excel application. The vulnerability was discovered on December 6th 2005, all the details were submitted to Microsoft, and the reply was received indicating that they may start working on it. It can be assumed that no patch addressing this vulnerability will be available within the next few months. So, since I was unable to find any use for this by-product of Microsoft developers, it is now available for you at the low starting price of $0.01 (a fair value estimation for any Microsoft product).
A percentage of this sale will be contributed to various open-source projects.
Vulnerability De ion (read carefully, this is what you bid on).
Microsoft Excel does not perform sufficient data validation when parsing document files. As a result, it is possible to pass a large counter value to msvcrt.memmove() function which causes critical memory regions to be overwritten, including the stack space. The vulnerability can be exploited to compromise a user’s PC. It is feasible to manipulate the data in the document file to get a code of attacker’s choice executed when malicious file is opened by MS Excel. The exploit code is not included in the auction. You must have very advanced skills if you want to further research this vulnerability.
What will be delivered (at no extra charge):
The winning bidder must provide an e-mail address that accepts .xls attachments. Two xls files will be mailed to this e-mail address: one file is the original Microsoft Excel document, the other one is a copy of the same document modified to demonstrate the vulnerability. The demonstration merely triggers the exception causing Excel to crash. It does not do anything malicious. A detailed de ion of the vulnerability will be provided in the message body. At that time you can claim youself to be THE ONLY ONE IN THE WORLD possessing the knowledge about the vulnerability. Wow! Imagine that! (Well, not counting Microsoft, but I really doubt that they’ll share it with anyone.) It is up to you what to do with it, but you may not use it for malicious purposes – see terms and conditions below.
Microsoft representatives get 10% off the final price. To qualify, you MUST provide @microsoft.com e-mail address and MUST mention discount code LINUXRULZ during checkout.
Terms and conditions of the sale:
Your bid indicates that you agree to the following:
1. You may not use this information for malicious or illegal purposes. The information you receive is for educational and
research purposes only.
2. The seller reserves the right to refuse delivery to anyone (a full refund will be issued).
3. The seller will accept no responsibility for anything you do with this information.
4. The seller cannot be held liable under any circumstances.
5. Absolutely no refunds will be provided except for the reason mentioned above.
1. All trademarks are the property of their respective owners.
2. No proprietary software products were decompiled or reverse engineered.
3. All information advertised here was used and is to be used to promote the importance and advance the knowlegde in the field of the information security.
4. The seller does not encourage any illegal activity.
Even if this one is a joke, what is to stop this model of vulnerability selling and disclosure from occurring more often in the future? As MadSaxon joked about over two years ago, registering a 0-bay domain might be a fun business to start.
Just over ten years ago (95-09-15) *Hobbit* wrote a little tool called netcat (aka nc), swiftly dubbed the “TCP/IP Swiss Army knife”. *Hobbit* was affiliated with the l0pht, which was later purchased by @stake, which was later purchased by Symantec. At some point (circa 1998), Weld Pond ported the netcat utility to Windows. Weld was an original member of the l0pht and later the Director of Research and Development with @stake. Weld’s version was distributed at @stake for some time. Suffice it to say, the l0pht, @stake and its members/employees supported netcat’s use and distribution.
Jump forward to today, and Symantec now classifies netcat on a system as a High Risk Impact. As aj reznor asked, “is that to say that SYM bought a company known then for offering naughty things?” Let us also remember that Symantec owns SecurityFocus which conveniently offers the tool in their tool repository.
Also amusing are Symantec’s “technical details” for this “hacker tool”:
Hacktool.NetCat arrives as a tool commonly carried by malicious components and dropped on the compromised computer for remote exploitation.
When Hacktool.NetCat is executed, it performs the following actions:
1. Transmits data across network connections.
Yes, there is no number two on the list. Hopefully Symantec will have the foresight to classify TCP/IP stacks as “Hacktool.TCPIP” and label it a “High Risk Impact” if found on a system.