Tag Archives: NVD

Mobile Devices and Exploit Vector Absurdity

The last few days has seen several vulnerabilities disclosed that include serious gaps in logic with regard to exploitation vectors. What is being called “remote” is not. What is being called “critical” is not. Here are a few examples to highlight the problem. We beg of you, please be rational when explaining vulnerabilities and exploit chaining. The biggest culprit in all of this is the “need for a user to install a malicious app” to then allow a vulnerability to be exploited. Think about it.

Number One

We start with an H-Online article titled “Critical vulnerability in Blackberry 10 OS“. First word, critical. In the world of vulnerabilities, critical means a CVSSv2 score of 10.0 which essentially allows for remote code execution without user interaction. Consider that standard and widely accepted designation, and read the article’s summary of what is required to exploit this vulnerability:

As well as needing Protect enabled, the user must still install a malicious app, which then compromises a Protect-component so that it can intercept a password reset. This password reset requires the user, or someone who knows the BlackBerry ID and password, to go to the web site of BlackBerry Protect and request the password. If the attacker manages that, then the Protect component, compromised by the earlier malicious app, can let the attacker know the new password for the device. If he has physical access to the device, he can now log on successfully as the actual user. Otherwise, the attacker can only access Wi-Fi file sharing if the actual user has activated it.

The only thing missing from this exploit chain are the proverbial chicken sacrifices at midnight on a full blue moon. Want to get the same result much easier? Find your victim and say “Wow, that is a slick new phone, can I see it?” Nine out of ten times, they unlock the phone and hand it to you. Less work, same result.

Number Two

There were a few disclosures out of Japan’s JVN system, run by JPCERT. Two examples, both the same fundamental vulnerability, are summarized below:

#1 – CVE-2013-3643 (NVD Entry) – JVN 99813183 / JVNDB-2013-000056
#2 – CVE-2013-3642 (NVD Entry) – JVN 79301570 / JVNDB-2013-000055

#1 – The Galapagos Browser application for Android does not properly implement the WebView class, which allows attackers to obtain sensitive information via a crafted application.

Despite all these references, users are left with either incorrect or very misleading information. First, CVE says “an attacker” instead of qualifying it as a local attacker. I only call them out because they are historically more precise than this. Second, NVD calls this a “context-dependent” attacker via the CVSSv2 score (AV:N/AC:M/Au:N/C:P/I:N/A:N), saying it can be exploited over the network with moderate user interaction. NVD also says this affects confidentiality ‘partially’. JVN goes so far to say it can be exploited “over the Internet using packets” with “anonymous or no authentication”.

The Reality

The reality of these vulnerabilities is that they are not remote. Not in any form under any circumstances that the vulnerability world accepts. For some reason, VDBs are starting to blur the lines of exploit traits when it comes to mobile devices. The thought process seems to be that if the user installs a malicious application, then the subsequent local vulnerability becomes ‘remote’. This is absurd. Just because that may be the most probable exploit vector and chaining, does not change the fact that getting a user to install a malicious application is a separate distinct vulnerability that cannot have any scoring weight or impact applied to the vulnerability in question. If you can get a phone user to install a malicious application, you can do a lot more than steal ‘partial’ information from the one vulnerable application.

Let me put it to you in terms that are easier to understand. If you have a Windows local privilege escalation vulnerability, it is local. Using the above logic, if I say that by tricking a user into installing a malicious application it can then be exploited remotely, what would you say? If you have a Linux Kernel local DoS, it too can become remote or context-dependent, if the root user installs a malicious application. You can already spin almost any of these local vulnerabilities into remote by saying “remote, authentication required” and assuming it can be done via RDP or SSH. To do so though, devaluates the entire purpose of vulnerability classification.

Any doubts? Consider that CVE treats the exact same situation as the mobile browser vulnerabilities above as a local issue in Windows, even when a “crafted application” is required (see IDs below). The only difference is if the local user writes the application (Windows), or gets the user to install the application (Mobile). Either way, that is a local issue.

CVE-2013-1334CVE-2012-1848CVE-2011-1282CVE-2010-3942CVE-2009-1123CVE-2008-2252

VDB Relationships (hugs and bugs!)

Like any circle in any industry, having good professional relationships can be valuable to involved parties. In the world of security, more specifically Vulnerability Databases (VDBs), the relationships we maintain benefit the community behind the scenes. Like ogres and onions, there are layers.

Someone from CVE and someone from OSVDB run an informal list called ‘Vulnerability Information Managers’ (VIM) for discussion of vulnerabilities as relates to post-disclosure issues. New information comes up, additional research, vendor confirmations, vendor disputes and more. It’s a great resource for us to discuss the details that help each VDB fine-tune their information. (No new vulnerabilities are posted there, don’t bother)

In addition, some of the VDBs have stronger relationships that allow for great dialogue and information sharing. A few examples of these, from OSVDB’s perspective:

- A couple of the CVE guys are great for very informal chat about vulnerabilities. Despite being the dreaded “government contractors”, they are respectable, very knowledgeable and have a great sense of humor. I just sent one a mail with the subject “PROVENANCE BITCHEZ?!” challenging him on the details of a given CVE. They are so nice, I broke my rule of not taking candy from strangers and happily accepted the bag of leftover candy from their BlackHat booth. Joking aside, the ability to coordinate and share information is incredible and a testament to their integrity and desire to help the industry.

- OSVDB uses Secunia for one of our feeds to gather information. The two guys we regularly have contact with (CE & TK) lead a bright team that does an incredible amount of work behind the scenes. In case it slipped your attention, Secunia actually validates vulnerabilities before posting them. That means they take the time to install, configure and test a wide range of software based on the word of 3l1t3hax0ry0 that slapped some script tag in software you never heard of, as well as testing enterprise-level software that costs more than OSVDB makes in five years. Behind the scenes, Secunia shares information as they can with others, and there is a good chance you will never see it. If you aren’t subscribed to their service as a business, you should be. For those who asked OSVDB for years to have a ‘vulnerability alerting’ service; you can blame Secunia for us not doing it. They do it a lot better than we could ever hope to.

- The head of R&D at Tenable contributes a lot of time and information to VIM based on his research of disclosed vulnerabilities. Installing the software, configuring, testing and sometimes noticing additional vulnerabilities. He is a frequent contributor to VIM and has worked with OSVDB on sharing information to enhance the Nessus plugins as well as the OSVDB database.

- str0ke, that mysterious guy that somehow manages to run milw0rm in his spare time. What may appear to some as a website with user-posted content, is actually a horrible burden to maintain. Since the site’s inception, str0ke has not just posted the exploits sent in, but he has taken time to sanity check every single one as best he can. What you don’t see on that site are dozens (hundreds?) of exploits a month that were sent in but ended up being incorrect (or as OSVDB would label, “myth/fake”). When str0ke was overwhelmed and decided to give up the project, user demand (read: whining & complaints) lead him to change his mind and keep it going. Make sure you thank him every so often for his work and know this: milw0rm cannot be replaced as easily as you think. Not to the quality that we have seen from str0ke.

Since we have no corporate overlords, I’ll go ahead and talk about the flip side briefly:

- ISS (now IBM) runs a good database. Very thorough, keen to detail on including original source and vendor information. In 2004, the head of that group (AF) left, and until that time, we had a great dialogue and open communication. Since then, even before the IBM frenzy, we’ve mostly gotten the cold shoulder when mailing. Even when pointing out problems or negative changes on their side. LJ, bring back the old days!

- NVD. Why do you waste taxpayer money with that ‘database’? We pay $22 for Booz Allen Hamilton to “analyze” each CVE entry (thanks FOIA request!), yet they find a fraction of the typos and mistakes I do? By fraction, I mean exactly none from what I hear through the grape vine (DHS cronies are cool). If you can’t notice and report simple typos in a CVE, and you botch CVSS2 scores left and right (yes, I’ve mailed in corrections that were acted on), what exactly are you doing with our money? Are you the virtual Blackwater of VDBs?

- SecurityFocus / BID. Sorry, not going to bother with verbal fluffing. My countless mails pointing out errors and issues with your database are seemingly dumped to a black hole. Your promises of certain mail archives ‘not changing’ were pure fantasy. To this date you make erroneous assumptions about affected products, and still don’t grasp “case sensitive”. I know some of your team, you have great people there. Just lift the corporate policy that turns them into virtual shut-ins, please?

Sorry to end it on a downer. I still dream of a niche of the security industry (VDBs) where we can all play well with each other.

Scrubbing the Source Data

A few months ago, Jeff Jones at CSO Online blogged about “Scrubbing the Source Data”, talking about the challenges of using vulnerability data for analysis. Part 1 examined using the National Vulnerability Database (NVD) showing how you can’t blindly rely on the data from VDBs. In his examples he shows that using the data to examine Windows is probably fairly accurate, yet examining Apple is less so and Ubuntu Linux is basically not possible. Unfortunately, there isn’t a part two to the series (yet) as implied by the title and introduction. Jones concludes the post:

Given these accuracy levels for vulnerabilities after the vendor has acknowledged it and provided a fix, it doesn’t seem like too much of a stretch to also conclude that using this data to analyze unpatched data would be equally challenging. Finally, I think this exercise helps demonstrate that anyone leveraging public data sources needs to have a good understanding of both the strengths and the weaknesses that any given data source may have, with respect to what one is trying to analyze or measure, and include steps in their methodology that accomodates accordingly.

English is a Funny Language

NVD announced this week that they are now going to expand and provide vulnerability information in Spanish. I found this a bit amusing since OSVDB once thought that translating the database was a critical feature that needed to be delivered back in 2002. In fact, all of the language support was in the original OSVDB database schema and the backend code was created to handle it as we truly thought this would be implemented.

However, we quickly realized there were several issues with this concept including finding people to perform the translations! Additional concerns were raised as we spoke to more people in the security industry which included many conversations with non-US based security professionals (including a long ranting conversation with FX at Defcon). The critical concern was that much of the true meaning of the vulnerabilty is lost when the information is translated. The bottom line is that it was strongly believed that the vulnerability information in OSVDB should remain only in English.

OSVDB decided that we would not proceed any further with official plans to to translate the database, however, we have been contacted from other people that have wanted to translate OSVDB and we have provided permission to do so…

Here is a copy of the NVD announcement:

The National Vulnerability Database (NVD) is expanding to provide vulnerability translations. The first translation data feed is in Spanish and is being provided in cooperation with Inteco (http://www.inteco.es/), an entity of the Spanish government’s Ministry of Industry, Tourism, and Commerce (http://www.mityc.es/). Inteco is providing the translations and is solely responsible for the translation content. NVD is providing the translation infrastructure. The result of this cooperative effort is that NVD now contains an XML feed with 7,858 Spanish translations for the Common Vulnerabilities and Exposures (CVE) dictionary of security related software flaws. This feed will be maintained with translations for all new CVE vulnerabilities and, as with the other NVD data feeds, the data can be incorporated into commercial products and services with no licensing fees or restrictions. The translations are available through translation XML feeds at http://nvd.nist.gov/download.cfm#transxml.

We would love to hear any further thoughts (good and bad) on the value of translating vulnerability information into other languages.

English is a Funny Language

NVD announced this week that they are now going to expand and provide vulnerability information in Spanish. I found this a bit amusing since OSVDB once thought that translating the database was a critical feature that needed to be delivered back in 2002. In fact, all of the language support was in the original OSVDB database schema and the backend code was created to handle it as we truly thought this would be implemented.

However, we quickly realized there were several issues with this concept including finding people to perform the translations! Additional concerns were raised as we spoke to more people in the security industry which included many conversations with non-US based security professionals (including a long ranting conversation with FX at Defcon). The critical concern was that much of the true meaning of the vulnerabilty is lost when the information is translated. The bottom line is that it was strongly believed that the vulnerability information in OSVDB should remain only in English.

OSVDB decided that we would not proceed any further with official plans to to translate the database, however, we have been contacted from other people that have wanted to translate OSVDB and we have provided permission to do so…..

Here is a copy of the NVD announcement:

The National Vulnerability Database (NVD) is expanding to provide vulnerability translations. The first translation data feed is in Spanish and is being provided in cooperation with Inteco (http://www.inteco.es/), an entity of the Spanish government’s Ministry of Industry, Tourism, and Commerce (http://www.mityc.es/). Inteco is providing the translations and is solely responsible for the translation content. NVD is providing the translation infrastructure. The result of this cooperative effort is that NVD now contains an XML feed with 7,858 Spanish translations for the Common Vulnerabilities and Exposures (CVE) dictionary of security related software flaws. This feed will be maintained with translations for all new CVE vulnerabilities and, as with the other NVD data feeds, the data can be incorporated into commercial products and services with no licensing fees or restrictions. The translations are available through translation XML feeds at http://nvd.nist.gov/download.cfm#transxml.

We would love to hear any further thoughts (good and bad) on the value of translating vulnerability information into other languages.

National Vulnerability Database (New Vulnerability Outage)

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.

Follow

Get every new post delivered to your Inbox.

Join 5,026 other followers