Slashdot Mirror

The US depends on it's software industry; we shipped all our labor jobs overseas to trade them for office work (programming).

Really? Then how do you explain the fact that the US has a multi-Trillion manufacturing sector which employs around 12 million people?

Bear in mind that the size of the global market for software is around $300 Billion and the number of US software developers is around 900,000.

Take a look at his biography.

Don't you mean brography?

Take a look at his biography. His experience starts mid-90s in large corporations. Maybe he thinks computing started then?

Our cofounders (I'm director of product management at Veracode) helped to coauthor the responsible disclosure standard, and it's linked on our web site. Short version: we don't disclose details about customer findings.

Having read their actual analysis which was linked by someone in a comment further down, it would appear they're not actually reading the code correctly. They claim that calling unknown.checkCallingOrSelfPermission "requests permissions for both COARSE_LOCATION, and FINE_LOCATION". What it actually does is check whether the app has these permissions, presumably so that the library can skip any attempt to retrieve GPS information when used in an app that hasn't requested permission to do so.

The actual Vericode post says it's both the iPhone and Android versions. I'm not sure why the article linked in the summary [and thus the summary] only mentions the Android version.

I wonder then, does the web browser interface do something similar, minus the GPS info of course? What about the Pandora One desktop app?

There are specs for getting geolocation information via JavaScript, so possibly. However, your browseri s supposed to ask your permission prior. This also doesn't preclude other Pandora components, such as Flash, which may have their own API.

That said, am I the only one who just doesn't care? This company is providing bandwidth and fronting music industry negotiations in order to deliver a useful and valuable service to me for free. As per the implicit (and explicit) contract with almost every modern free service, it's a willing exchange of information, and I'm perfectly willing to trade my phone ID and location for this service (for now).

It would be nice, though, if there was an Android requirement that each application disclosed exactly what data it was collecting, and for what purpose, in order to be included in the Marketplace.

The actual Vericode post says it's both the iPhone and Android versions. I'm not sure why the article linked in the summary [and thus the summary] only mentions the Android version.

I wonder then, does the web browser interface do something similar, minus the GPS info of course? What about the Pandora One desktop app?

I'll open with a disclaimer: most of my smartphone experience and awareness is centered around Android phones. That said, this article is yet another with a standard theme: "Remember, you stupid public, that smartphones are still computers". This is another in the a set of articles about people who write phone applications requesting a smorgasbord of permissions, receiving them from the user, and using them maliciously. Put simply, this is another in the formulaic series:

Mystique of Computers * Fear of Malware * Novelty of Phones = Profit

Chris Wysopal, co-founder and technology head at security firm Veracode, which helped the BBC with its project, said smartphones were now at the point the PC was in 1999.

No offense, but Chris Wysopal is an idiot. Modern smartphones run every application in a sandboxed per-application environment with fine-grained permission controls that are, to some degree, opaque to the user. These applications, by a well-defined default, must exist in a central repository managed by a powerful authority and receive realtime user reviews. This is nothing like PCs in 1999 (remember, that was Windows 98). Then again, he's certainly quite biased, as his company makes a living certifying applications.

All of the information-stealing elements of the spyware program were legitimate functions turned to a nefarious use.

Yes, of course they were. BBC didn't actually do anything innovative, like find an exploitation or break out of the sandbox. They just abused the OS's granted privileges to the fullest extent. Is this actually a problem? Given any set of privileges and any degree of fine-grained control, you can still abuse whatever you're given to the fullest extent.

At least one fundamental thing failed here: the user installed a phone game that requested privileges such as:

• SEND_SMS: Allows an application to send SMS messages.
• INTERNET: Allows applications to open network sockets.
• READ_CONTACTS: Allows an application to read the user's contacts data.
• READ_OWNER_DATA: Allows an application to read the owner's data.
• ... to name a few

As the owner and user of the device, it is ultimately your responsibility to determine what software you install on your phone. If you are downloading a single-player game that asks for these kinds of permissions, you had damned well better check out the source of that game. If it's not a company that you are comfortable trusting and you still install it, then you are (frankly) stupid. BBC does, of course, presume that its users are stupid.

But that's the problem ... no amount of protection will allow stupid people have free access to a computer and remain protected. You have to strip away something from one of these factors ... either whittle down free access or reduce the base of stupid users. Better design models only serve to decrease the thresholds required for either.

Is there an inherent issue with those kinds of permissions being available and grantable? Sure, there is! Applications, especially closed-source ones, are effectively black boxes. The permissions that I am presented with at installation-time are, in fact, my only real insight as to what the application is capable of doing. Arguing for a finer grain of control is pointless, though. Regardless of what permissions are grantable, you will never circumvent the fundamental problem that stupid users will blindly install applications. Presenting them with more information will not change that fact.

It is the job of the OS vendor (Apple, Google, RIM, etc.) to declare a set of permissions that reasonably mitigates the dangers of overly-gener

I made my submission after first seeing a story in El Reg. While I saw it in several other places, I thought the Dark Reading story was a bit better in highlighting the findings than most. You're right, though. It's very light on the methodology. The press release on VeraCode's site has a bit more information:

...1,600 Internally Developed, Open Source, Outsourced, and Commercial applications analyzed when first submitted to Veracode...

...the first report of its kind to provide security intelligence derived from multiple testing methodologies (static, dynamic and manual) on the full spectrum of application types (components, shared libraries, web and non-web applications) and programming languages (including Java, C/C++ and .NET) from every part of the software supply chain on which organizations depend.

...analyzing billions of lines of code submitted to Veracode for independent verification of software security from more than 15 industries.

(emphasis added)

So. The sample consists of approximately 1,600 applications consisting of billions of lines of code from self selecting organizations; organizations who have an interest in writing the most secure code possible or they wouldn't be subjecting themselves to this process or paying for the service. And still, 60% of all these apps fail the first time through!

I've been following testing results for FOSS for years. I've waded through thesis papers, press releases, magazine articles, Coverity's Scan site, you name it and I've dug into it. Virtually everything else that I've come across covered just a single means; static or dynamic code analysis, pen testing, fuzz testing, bug report analysis, mathematical breakdowns that attempt to address the "why" FOSS works so well, etc. The press release defines a sample size that is at least within shouting distance as the largest two that I know of; a study commissioned by the European Commission to analyze the economic impact of FLOSS which briefly discusses bug fixing, Coverity, and Coverity again.

At most, they might have tackled two methodologies in a single article. This is the first such announcement that I've been able to find that covers multiple methodologies. IMNSHO, that's what makes this an important story. Slashvertisement or not.

(BTW, note that the original announcment was at RSA Conference 2010. I suppose that makes it a RSAvertisement first? Nahhh. Doesn't trip off the tongue. ;) )

If you take a look at the full report (registration required), you'll see that the application pool from which the report was drawn was 47% Java, 31% C/C++ (on Windows, Red Hat Linux, and Solaris), and 22% .NET. Other data is provided (industry, supplier type) to help frame the terms of the application pool from which the data was drawn. We acknowledge the inherent selection bias (the applications in the report come from our customers) in the methodology section.

Disclaimer: I work for Veracode and was a co-author of the report.

You can check out the full report online from the Veracode.com website (requires registration).

We disclose the sample size in the appendix (1591 applications).

You can test the quality of code you are developing yourself with a simple source code scanner, but testing third party code is a little more challenging. I don't know too many significant applications that are entirely created in house, with no dependency on third party libraries.

Disclaimer: I work for Veracode and was a coauthor of the study.

That's pretty troubling, I wouldn't think the device should accept a service book from anywhere but it's authorized BES server. That means that *any* BB can probably be silently "upgraded" with a SB that compromises encryption (as an example) by the ISP.

It's already been done elsewhere by ss8.
http://www.veracode.com/blog/2009/07/blackberry-spyware-dissected/

It is believed this is the same method the US government intercepts a blackberry with a warrant as well.

I've posted on the Veracode Blog about this issue for clarification purposes.

Here's the content:

With regard to the recent Patch Tuesday fix, there has been an issue fixed regarding NTLM Relaying, that has been around for more than eight years.

In 2000, I wrote an advisory about NTLM relaying (CVE-2000-0834). The problem turned out to be significantly larger than I originally suggested in the advisory. The attack extended to other NTLM-based authentications on other protocols and allowed general-purpose credential theft via a man-in-the-middle attack.

The SMBRelay tool was published in 2001 by Sir Dystic of Cult Of The Dead Cow, and that really took it to the next level. The protocol completely fell apart. It kicked off a number of other analyses of the NTLM protocol that finally resulted in this patch. Eight years after itâ(TM)s discovery.

At least they got around to it. Thanks!

--chris

(Buy my house! http://tinyurl.com/dilshouse)

Veracode

Based on its breakthrough binary analysis technology, Veracode offers the world's first subscription-based security testing service that provides organizations with the only automated and independent assessment of security risks in applications, whether those applications are built in house, purchased as commercial off-the-shelf software or developed offshore.

Disclaimer: I know the founders but I am not involved in the company at all.

- SR

I was interviewed for this article by Scott Berinato. I have added some thoughts on the topic to my blog. A rich and robust vulnerability research community needs legal access to the software we are researching. As more and more software becomes web 2.0 instead of running on our desktops we will have less and less independent vulnerability research.

Vulnerability Disclosure in the new "Software in the Cloud" World
http://www.veracode.com/blog/?p=11

-Chris