Recently in SYSSEC Category

A fair bit has been written about Google's "new approach to China"

Like many other well-known organizations, we face cyber attacks of varying degrees on a regular basis. In mid-December, we detected a highly sophisticated and targeted attack on our corporate infrastructure originating from China that resulted in the theft of intellectual property from Google. However, it soon became clear that what at first appeared to be solely a security incident--albeit a significant one--was something quite different.

...

Third, as part of this investigation but independent of the attack on Google, we have discovered that the accounts of dozens of U.S.-, China- and Europe-based Gmail users who are advocates of human rights in China appear to have been routinely accessed by third parties. These accounts have not been accessed through any security breach at Google, but most likely via phishing scams or malware placed on the users' computers.

...

These attacks and the surveillance they have uncovered--combined with the attempts over the past year to further limit free speech on the web--have led us to conclude that we should review the feasibility of our business operations in China. We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all. We recognize that this may well mean having to shut down Google.cn, and potentially our offices in China.

I don't really see the connection between this incident and Google's decision to stop offering filtered access to search queries in China, at least in terms of protecting Google from future attacks. Let's say for the sake of argument that not only were the attacks originated in China but also that (and as far as I know, this is unproven), they were directly sponsored by the Chinese government. How does refusing to offer filtered searches help? It's not like the hackers (allegedly) used some vulnerability in the filtering software as their attack vector. Similarly, even if Google were to pull out of China, or even cut off all access to Chinese IP addresses, Chinese hackers aren't restricted to using IP addresses in Chinese address ranges; they can perfectly well use machines which are located in the US, either by using legitimately purchased accounts as stepping stones, or by using compromised American hosts, of which there are plenty.

I don't have any inside information, but it seems to me like a more plausible story (see this Slate article for an alternate view) is that Google thinks the Chinese government is behind these incidents and this is a way of retaliating against China, under the assumption that China would prefer to have some Google than none. I have no idea whether or not this is something China cares about, however. [Mrs. Guesswork observes that another theory is that Google was previously cooperating with China's surveillance efforts and feels like China overstepped their agreement.]

On a different note, it has been fairly widely reported that an IE 0-day was used in the attack, but Bruce Schneier claims that the hackers exploited a Google-created backdoor intended for lawful intercept (though he doesn't provide any sources):

(CNN) -- Google made headlines when it went public with the fact that Chinese hackers had penetrated some of its services, such as Gmail, in a politically motivated attempt at intelligence gathering. The news here isn't that Chinese hackers engage in these activities or that their attempts are technically sophisticated -- we knew that already -- it's that the U.S. government inadvertently aided the hackers.

In order to comply with government search warrants on user data, Google created a backdoor access system into Gmail accounts. This feature is what the Chinese hackers exploited to gain access.

Of course, both of these can be true. Even if Google built a surveillance tool for the purpose of lawful intercept, presumably it wasn't something you could just connect to without authorization, so I would imagine that you would need to do some hacking to get access to it (unless, of course, the password is "1234").

Sequoia Voting Systems recently announced that it will be publishing the source code to their Frontier opscan voting system. Reaction in the security community seems generally positive. Here's Ed Felten:

The trend toward publishing election system source code has been building over the last few years. Security experts have long argued that public scrutiny tends to increase security, and is one of the best ways to justify public trust in a system. Independent studies of major voting vendors' source code have found code quality to be disappointing at best, and vendors' all-out resistance to any disclosure has eroded confidence further. Add to this an increasing number of independent open-source voting systems, and secret voting technologies start to look less and less viable, as the public starts insisting that longstanding principles of election transparency be extended to election technology. In short, the time had come for this step.

I'm less sanguine. I'm not saying this is a bad thing necessarily, but I'm not sure it's a good thing either. As always, it's important to consider what threats we're trying to defend against. We need to consider two kinds of vulnerabilities that might be present in the code:

• Backdoors intentionally introduced by Sequoia or their engineers.
• Design and or implementation errors accidentally introduced by Sequoia engineers.

A lot of the focus on open voting systems has focused on the first kind of threat (corporations are stealing your votes, etc.) I think there's certainly a credible argument to be made that having to publish the source code does make this form of attack somewhat harder. If people are looking at your code, then you probably can't put a naked backdoor ("if someone types 1111, give them operator control") into the code because that might get caught in a review. On the other hand, it would be a pretty risky move to put that kind of backdoor into a piece of software anyway, since even closed voting source code does get reviewed, both as part of the system certification process and in private reviews like those conducted by Califoria and Ohio. More likely, you'd want to hide your back door so it looked like an accidentally introduced vulnerability, both to make it harder to find and to give you plausible deniability.

This brings us to the second form of vulnerability: those introduced as errors/misfeatures in Sequoia's development process. These aren't necessarily a sign of incompetence; as Steve Bellovin says, "all software has bugs and security software has security relevant bugs." Having access to the source code makes it easier to find those vulnerabilities (though as Checkoway et al. have shown it's quite possible to find exploitable vulnerabilities in voting systems without access to the source code). This of course applies both to attackers and defenders. There's an active debate about whether or not on balance this makes open source inherently more or less secure. I'm not aware of any data which settles the question definitively, but I don't think that anyone in the security community believes that a previously insecure piece of software will suddenly become substantially more secure just because the source is disclosed; there are just too many security vulnerabilities for the sort of low-level uncoordinated review that you get in practice to stamp out. On the other hand, it does provide a pretty clear near-term benefit to attackers, who, after all, just need to find one vulnerability.

Now, that's not what Sequoia is doing. According to their press release, Frontier is an entirely new system which they say has been "developed from the ground up with the full intention of releasing all of the source code to any member of the public who wishes to download it - from computer scientists and election officials to students, security experts and the voting public". This syncs up better with another argument about why openness is important, which is more about incentives: if vendors know their code will be open to scrutiny they will be motivated to be more careful with their designs and implementations. Reviews of Sequoia's previous systems have been pretty negative; it will be interesting to see if the new one is any better. On the other hand, we have the confounding factor that modern standards for what it means for a piece of software to be secure are a lot higher than those which applied when the original SVS system was written, so it will be hard to tell whether it's really openness which provided the value, or just that they started from scratch.

One more thing: suppose that the source code is published and the code is full of problems. What then?

My comments can be found here. You may also be interested in ACCURATE's comments which can be found here.

[See here]

S 5.2.2 requires that systems be written in programming languages which support block-structured exception handling:

The above requirement may be satisfied by using COTS extension packages to add missing control constructs to languages that could not otherwise conform. For example, C99[2] does not support block-structured exception handling, but the construct can be retrofitted using (e.g.) cexcept[3] or another COTS package.

The use of non-COTS extension packages or manufacturer-specific code for this purpose is not acceptable, as it would place an unreasonable burden on the VSTL to verify the soundness of an unproven extension (effectively a new programming language). The package must have a proven track record of performance supporting the assertion that it would be stable and suitable for use in voting systems, just as the compiler or interpreter for the base programming language must.

One could interpret this requirement as simply being that the language must support this functionality, not that it be used, in which case the requirement is unobjectionable. However, S 5.2.5 makes clear that programmers are expected to actually use exception constructs, which is significantly more problematic.

The first issue is that an exception-oriented programming style is significantly different than an error code-oriented programming style, so complying with the spirit of this requirement implies a very substantial rewrite of any existing system which uses error codes. However, experience with previous VVSG programming style requirements suggests that vendors will do the minimum required to comply with the letter of the VVSG. Because the two styles are similar enough that the conversion process can be done semi-mechanically, the likely result will be a a program which superficially works but which now has subtle bugs which were introduced during the conversion process.

One class of bugs that deserves particular attention is the proper cleanup of objects before function exit. When a function creates a set of objects and then encounters an error, it is important to clean up those objects before returning with the error. Failure to do so can leak memory and, more importantly, lead to improper finalization of objects which may be connected to non-memory resources such as network connections, hardware, etc. In languages such as Java, this is handled by garbage collection, but C is not garbage collected. Thus, when an exception is thrown from a function deep in the call stack and caught in a higher function, it bypasses all explicit cleanup routines in intermediate functions, which can lead to serious errors. Handling this situation correctly requires extreme care comparable to that required with conventional error handling. Writing correct code under these circumstances is challenging under the best of conditions, but is likely to be impractical under conditions where programmers are required to convert existing error code-based software.

While it might be the case that a completely new system written along exception-oriented lines would be superior, I am aware of no evidence that a retrofitted system would be superior and there is a substantial risk that it will be worse.

The second issue is that because C has no native exception handling, systems written in C will need to use a COTS package. Unfortunately, because exception handling is not a native feature of C, any attempt to retrofit it involves tradeoffs. As an example, the cexcept[3] package cited above, does not support conditional exception handling. In C++ exceptions, it is possible to have a Catch statement which only catches some exceptions, e.g.,

   try {
 

   }
   catch (memory_exception){
     ;
   } 
   catch (data_exception){
     ;
   }
 
   // Other exceptions get passed through

But in cexcept, a Catch statement catches exceptions of all types and you need to use an explicit conditional in order to discover which exception was thrown. But this creates much the same opportunity to ignore/mishandle unexpected exceptions that error codes do.

Another problem with cexcept is that it is very brittle whenever exception handling is intermixed with conventional error handling. Any function which jumps out of a try/catch block can result in "undefined" behavior (i.e., the implementation can do anything whatsoever). This, of course, is an easy mistake to make when converting from return codes to exceptions.

cexcept is not, of course, the only C exception package. For instance, Doug Jones has developed a different exception package, which makes different tradeoffs (though the above intermixed exception/return problem seems to exist here too).

Third, the use of the term "COTS" to cover these packages seems to require a fairly loose definition of COTS. While it is true that there are a number of exception packages available for free download, it is not clear to what extent they are in wide use by programmers. In my experience as a professional programmer, I have yet to work on a system written in C which used on of these packages. As the stated purpose of the COTS requirement is to be to ensure that the packages have seen enough deployment that we can have confidence in their quality, it seems questionable whether any of the available packages meet this standard.

Nominum is introducing a new "cloud" DNS service called Skye. Part of their pitch for this service is that it's supposedly a lot more secure. Check out this interview with Nominum's John Shalowitz where he compares using their service to putting fluoride in the water:

In the announcement for Nominum's new Skye cloud DNS services, you say Skye 'closes a key weakness in the internet'. What is that weakness?

A: Freeware legacy DNS is the internet's dirty little secret - and it's not even little, it's probably a big secret. Because if you think of all the places outside of where Nominum is today - whether it's the majority of enterprise accounts or some of the smaller ISPs - they all have essentially been running freeware up until now.

Given all the nasty things that have happened this year, freeware is a recipe for problems, and it's just going to get worse.

...

What characterises that open-source, freeware legacy DNS that you think makes it weaker?

Number one is in terms of security controls. If I have a secret way of blocking a hacker from attacking my software, if it's freeware or open source, the hacker can look at the code.

By virtue of something being open source, it has to be open to everybody to look into. I can't keep secrets in there. But if I have a commercial-grade software product, then all of that is closed off, and so things are not visible to the hacker.

By its very nature, something that is freeware or open source [is open]. There are vendors that take a freeware product and make a slight variant of it, but they are never going to be ever able to change every component to lock it down.

Nominum software was written 100 percent from the ground up, and by having software with source code that is not open for everybody to look at, it is inherently more secure.

First, I should say that I don't have any position on the relative security of Nominum's software versus the various open source DNS products. With that said, I'm not really that convinced. The conventional argument goes that it's harder for attackers to find vulnerabilities in closed source software because it's harder to work with the binaries than the source. This is a proposition which I've seen vigorously argued but for which there isn't much evidence. Now, it's certainly true that if nobody can get access to your program at all, then it's much harder to figure out how it works and how to attack it. However, Nominum does sell DNS software, so unless the stuff they're running on Skye is totally different, it's not clear how much of an advantage this is.

Salowitz also argues that being closed source lets him hide "secret way[s] of blocking a hacker from attacking my software". This seems even less convincing, primarily because it's not really clear that such techniques exist; there's been a huge amount of work on software attack and defense in the public literature, so how likely is it that Nominum has really invented something fundamentally new? And if you did in fact have such a technique, but one that's only secure as long as it's secret, then it's far more vulnerable to reverse engineering than programs ordinarily are, since the attacker just needs to reverse engineer it once and it's insecure forever. By contrast, if they reverse engineer your program to find a vulnerability, you can close that vulnerability and then they need to find a new one.

Again, this isn't to say that Nominum's system is or isn't more secure than other DNS servers (though DJBDNS, for instance, has a very good reputation). I don't have any detailed information one way or the other. However, this particular argument doesn't seem to me to establish anything useful.

A number of political blogs (e.g., Obsidian Wings, Matthew Yglesias, etc.) seem to have a problem with comment impersonation. The general pattern is that someone will show up and post something more or less blatantly offensive under the name of a well-known commenter. This is then followed by a series of posts asking "was that really John or just a comment spoofer?" "Can someone check/block their IP?", and often eventual removal of the offending comment, leaving everyone confused about what the fuss is about.

Obviously, the underlying source of the problem is that most blog software has completely open commenting: you don't need to register and you can provide any identity you want and it will just accept it. This is convenient if you regularly post from random machines, but makes this sort of impersonation trivial. The natural "security guy" defense here is of course to require actual user authentication [this seems to be supported by most blog software], but that's really overkill for this situation, where all we really want to do is stop random people from impersonating random other people. Here, then, is my suggestion for a small set of changes which would make most casual impersonation very difficult:

1. The first time a given identity is used, record the IP from which it is used and install a cookie in the browser which is used to make the comment.
2. In future, restrict use of that identity to requests which either come from that source IP or present the right cookie.
3. If you see a request from a different source IP that present the right cookie, add that source IP to the whitelist.
4. If you see a request from a whitelisted source IP without a cookie, install the cookie.
5. Have a manual mechanism (e.g., e-mail challenge response) for allowing a new computer to post comments under an existing name.

This isn't perfect in a number of respects. First, it doesn't provide perfect security. For instance, if I ever post from a hotspot (which generally has a NATted network) anyone else from that hotspot will be able to post as me. However, that seems relatively unlikely given the form of attack which we're generally seeing here, which is mostly trolls trying to disrupt the conversation. The second problem, of course, is that it's a little inconvenient if you have multiple computers, but even people who do post from multiple computers generally only have a few and those would quickly be whitelisted. The big advantage of this scheme is that it provides reasonable deterrence against a common attack and is generally pretty transparent to most users. We don't have a comment impersonation problem here on EG, and I'm too lazy to implement it for the public good, but I'm a litle surprised that hosting services like Typepad haven't implemented something similar.

Ed Felten writes about the problem of fleeing voters:

Well designed voting systems tend to have a prominent, clearly labeled control or action that the voter uses to officially cast his or her vote. This might be a big red "CAST VOTE" button. The Finnish system mistakenly used the same "OK" button used previously in the process, making voter mistakes more likely. Adding to the problem, the voter's smart card was protruding from the front of the machine, making it all too easy for a voter to grab the card and walk away.

No voting machine can stop a "fleeing voter" scenario, where a voter simply walks away during the voting process (we conventionally say "fleeing" even if the voter leaves by mistake), but some systems are much better than others in this respect. Diebold's touchscreen voting machines, for all their faults, got this design element right, pulling the voter's smart card all of the way into the machine and ejecting it only when the voter was supposed to leave -- thus turning the voter's desire to return the smart card into a countermeasure against premature voter departure, rather than a cause of it. (ATM machines often use this same trick of holding the card inside the machine to stop the user from grabbing the card and walking away at the wrong time.) Some older lever machines use an even simpler method against fleeing voters: the same big red handle that casts the ballot also opens the curtains so the voter can leave.

I was at the Fidelity office in Palo Alto today and I noticed an ingenious solution to a related problem: fleeing customers. Their investment terminals have dead-man switches, well mats:

The way that this works (apparently) is that there's a pressure sensitive mat in front of the terminal, positioned so that you need to (or at least it's really inconvenient not to) stand on the mat in order to use the terminal. When you step off the mat to walk away, the terminal logs you out, so there's only a minimal window of vulnerability where you're logged in but not present. Now, obviously, a real attacker could tamper with the mats to keep you logged in, but this seems like a pretty good safeguard against simple user error being exploited by subsequent customers. You could imagine building a similar safeguard into voting machines, where the machine rings some alarm if you step away.

UPDATE: Fixed blockquote...

Wired reports on Apple's response to EFF's proposed DMCA exception for iPhone jailbreaking. I'm not qualified to have a position on the legal arguments Apple is advancing, but check out their technical arguments:

More generally, as Mr. Joswiak testified at the hearings in Palo Alto, a critical consideration in the development of the iPhone was to design it in such a way that a relationship of trust could be established with the telecommunication provider (AT&T in the case of users in the U.S.). Before partnering with Apple to provide voice and data services, it was critical to AT&T that the iPhone be secure against hacks that could allow malicious users, or even well- intentioned users, to wreak havoc on the network. Because jailbreaking makes hacking of the BBP software much easier, jailbreaking affords an avenue for hackers to accomplish a number of undesirable things on the network.

For example, each iPhone contains a unique Exclusive Chip Identification (ECID) number that identifies the phone to the cell tower. With access to the BBP via jailbreaking, hackers may be able to change the ECID, which in turn can enable phone calls to be made anonymously (this would be desirable to drug dealers, for example) or charges for the calls to be avoided. If changing the ECID results in multiple phones having the same ECID being connected to a given tower simultaneously, the tower software might react in an unknown manner, including possibly kicking those phones off the network, making their users unable to make phone calls or send/receive data. By hacking the BBP software through a jailbroken phone and taking control of the BBP software, a hacker can initiate commands to the cell tower software that may skirt the carrier's rules limiting the packet size or the amount of data that can be transmitted, or avoid charges for sending data. More pernicious forms of activity may also be enabled. For example, a local or international hacker could potentially initiate commands (such as a denial of service attack) that could crash the tower software, rendering the tower entirely inoperable to process calls or transmit data. In short, taking control of the BBP software would be much the equivalent of getting inside the firewall of a corporate computer - to potentially catastrophic result. The technological protection measures were designed into the iPhone precisely to prevent these kinds of pernicious activities, and if granted, the jailbreaking exemption would open the door to them.

This is an odd set of arguments: if what I want to do is bring down the cell network, I've got a lot of other options than hacking my iPhone. For instance, I could buy a less locked down phone or a standard programmable GSM development kit on the open market. In general, GSM chipsets and radios just aren't a controlled item. Second, if a misbehaving device is able to bring down a significant fraction of the cellular system, then this represents a serious design error in the network: a cell phone system is a distributed system with a very large number of devices under the control of potential attackers; you need to assume that some of them will be compromised and design the network so that it's resistant to partial compromise. The firewall analogy is particularly inapt here: you put untrusted devices outside the firewall, not inside. I'm not an expert on the design of GSM, but my impression is that it is designed to be robust against handset compromise. The designs for 3GPP I've seen certainly assume that the handsets can't be trusted.

That leaves us with more mundane applications where attackers want to actually use the iPhone in an unauthorized way. Mainly, this is network overuse, toll fraud, etc. (Anonymous calling isn't that relevant here, since you can just buy cheap prepaid cell phones at the 7/11. You'd think someone at Apple would have watched The Wire.) As far as toll fraud goes, I'm surprised to hear the claim that hacking the iPhone itself lets you impersonate other phones. My understanding was that authentication in the GSM network was primarily via the SIM card, which is provided by the carrier and isn't affected by phone compromise. [The GSM Security site sort of confirms this, but I know there are some EG readers who know more about GSM security than I do, so hopefully they will weigh in here.] It's certainly true that control of the iPhone will let you send traffic that the provider doesn't like, and the phone can be programmed to enforce controls on network usage, so this is probably getting closer to a relevant concern. On the other hand, controls like this can be enforced in the network in a way that can't be bypassed by tampering with the phone.

While I'm not that concerned about jailbreaking leading to the parade of horrors Apple cites here, it's arguable that Apple's insistence on locking down the platform has made the problem worse. What people want to do is primarily: (1) load new software on the phone and (2) unlock the phone so they can use it with other carriers. However, because Apple won't let you do either of these, a lot of effort has been put into breaking all the protections on the phone, which naturally leads to the development of expertise and tooling for breaking the platform in general. There's an analogy here to the observation (I think I heard Mark Kleiman make this) that minimum drinking ages lead to the development of a fake ID industry, which then makes it easier for criminals and terrorists to get fake IDs.

Miguel Helft has a somewhat confusing/confused article in today's NYT about Google's ChromeOS and moving applications into the cloud. In order to make sense of this, it's important to understand what we're talking about and what its properties are.

Your typical computer (say, a Windows machine) is loaded with an OS, whose job it is to let you run applications, talk to the various devices on the system, mediate access to shared resources, etc. Most of the work is done by a variety of applications that run on top of the operating system. Almost everything you ordinarily use (Word, IE, Firefox, Safari, Exchange, ...) are applications that run on top of the OS They rely on the OS to let them talk to all those resources, including the network, the disk, and to some extent the system memory. What we're talking about with a Web-based system is something where the operating system has been stripped down and only really runs one program: the Web browser. In the case of ChromeOS, the operating system is Linux and the browser is Chrome.

With that in mind, let's take a look at this article.

PCs can be clunky and difficult to maintain. They're slow to start up and prone to crashing, wiping out precious files and photographs. They are perennially vulnerable to virus attacks and require frequent upgrades. And if you lose your laptop, or worse, it's stolen, you lose not only your machine but everything stored in its circuitry that's not backed up - those files, contacts, e-mail messages, pictures and videos.

But what if a computer were nothing more than an Internet browser - a digital window pane onto the Web? You could forget about all the software that now powers your computer and everything it does. All of those functions would be done through the Web. And none of the information that's now inside your computer would be there anymore. Instead, it would all be on the cloud of connected computers that is the Internet.

There are a number of points here, so let me take them in turn: maintainability, availability, and security.

It's certainly true that PCs are a pain to maintain. This is especially true if you're running a PC with software from a variety of manufacturers, since any of those packages can need upgrading. However, it's not like you won't need to upgrade your ChromeOS machine as well: both Linux and Chrome will require periodic upgrades. Now, if Google does a good job, then those upgrades will be automatic and relatively painless—both Microsoft and Apple already do this, though I guess it's a matter of opinion how painless they are and of course it remains to be seen if ChromeOS's mechanisms are any better. The good news with a Web-based system is that the number of pieces of software you're running is strictly limited and that new functionality can be implemented by software that runs inside the browser, so you don't need to download or manage it.

As for the reliability/availability of your data, having your PC crash is of course a not-infrequent occurrence, and data certainly does get lost. If your data is stored on some machine on the Internet, then failures of your PC don't cause data loss. But the flip side of this feature is that if you don't have access to the Internet, then you may not be able to get at your data at all. It's possible to design networked systems that depend on remote storage but cache data on your local PC so you can work on it when you're disconnected—I routinely use systems like this for collaboration—but it's hard to make that sort of thing work purely in the browser context, since the whole point is that the software resides on the Web server, not on your local machine.

I'm less convinced by the security story. The basic way that your computer gets infected with malware is that a program with a vulnerability processes some malicious data supplied by an attacker. On a typical PC, there are only a few programs which an attacker can send data to: primarily the Web browser, mail client (unless you use Webmail), IM client (unless you use Web-based IM), word processor (unless you use Google docs), maybe a PDF previewer, spreadsheet, etc. Note how prominently the browser appears here; a putative web-based operating system will presumably be running a standard browser, so vulnerabilities in the browser still potentially lead to viruses. It's possible to run the browser in an isolated environment which resets itself after each invocation (think VMware here), but you could at least in principle do the same thing on a commodity PC. Fundamentally, the security of a system like this depends on the security of the browser, which is to a great extent the situation with commodity PCs as well.

Speaking of security, I should mention that the following seems pretty implausible:

Any device, anywhere - from a desktop PC to a mobile phone - could give users instant access to all their files and programs so long as it had a Web browser. At the same time, new kinds of devices would be possible, from portable computers that are even lighter than today's thinnest PCs, to, say, a Web-connected screen in a hotel room that would give guests full access to their digital lives.

Now, obviously it's technically possible to build a Web-based system where you can remotely access all your data from a machine in your hotel room, but that's not really something you would want; remember that you have no idea what software is running on the PC in your hotel room, so you have no way of knowing that it's not just pretending to run ChromeOS (or whatever), but actually stealing your password and all your data. [Technical note: it could also be virtualized, running a keylogger, or an inline keyboard logger, etc.] I can see that you might want to have a very lightweight machine that you carry around and that does most of its thinking in the cloud—to some extent that's what an iPhone already is—but it really needs to be a device you control.

Moving on...

In the past few years, phones have started to act more like computers, and devices like the iPhone have whetted consumers' appetite for a combination of power and simplicity. Now that power and simplicity could migrate from the phone to the PC.

"The experience that we have on our iPhones and smart phones prefigures what the PC will become," said Nicholas Carr, the author of "The Big Switch," a book about cloud computing.

This is a particularly odd argument. Originally the iPhone was precisely this sort of Web-based system: you couldn't load your own software and the only extensibility point was that you could write new web applications. It quickly became clear that due to intentional restrictions in the browser environment (largely intended as security features) this was a really inadequate way of adding new functionality, which was one of the major original motivations for people to jailbreak the iPhone. Then, of course, the app store became available and now all sorts of new functionality is added by loading new programs onto the iPhone operating system, just like you would if you were running a regular PC (except, of course, from having to get all the software via Apple). If anything the iPhone seems like an argument against this concept, not for it.

Andy Zmolek of Avaya reports on VoIP security research company VoIPshield's new policy requiring vendors to pay for full details of bugs in their products. He quotes from a letter VoIPShield sent him:

"I wanted to inform you that VoIPshield is making significant changes to its Vulnerabilities Disclosure Policy to VoIP products vendors. Effective immediately, we will no longer make voluntary disclosures of vulnerabilities to Avaya or any other vendor. Instead, the results of the vulnerability research performed by VoIPshield Labs, including technical descriptions, exploit code and other elements necessary to recreate and test the vulnerabilities in your lab, is available to be licensed from VoIPshield for use by Avaya on an annual subscription basis.

"It is VoIPshield's intention to continue to disclose all vulnerabilities to the public at a summary level, in a manner similar to what we've done in the past. We will also make more detailed vulnerability information available to enterprise security professionals, and even more detailed information available to security products companies, both for an annual subscription fee."

In comments, Rick Dalmazzi from VoIPshield responded at length. Quoting some of it:

VoIPshield has what I believe to be the most comprehensive database of VoIP application vulnerabilities in existence. It is the result of almost 5 years of dedicated research in this area. To date that vulnerability content has only been available to the industry through our products, VoIPaudit Vulnerability Assessment System and VoIPguard Intrusion Prevention System.

Later this month we plan to make this content available to the entire industry through an on-line subscription service, the working name of which is VoIPshield "V-Portal" Vulnerability Information Database. There will be four levels of access (casual observer; security professional; security products vendor; and VoIP products vendor), each with successively more detailed information about the vulnerabilities. The first level of access (summary vulnerability information, similar to what's on our website presently) will be free. The other levels will be available for an annual subscription fee. Access to each level of content will be to qualified users only, and requests for subscription will be rigorously screened.

So no, Mr. Zmolek, Avaya doesn't "have to" pay us for anything. We do not "require" payment from you. It's Avaya's choice if you want to acquire the results of years of work by VoIPshield. It's a business decision that your company will have to make. VoIPshield has made a business decision to not give away that work for free.

It turns out that the security industry "best practice" of researchers giving away their work to vendors seems to work "best" for the vendors and not so well for the research companies, especially the small ones who are trying to pioneer into new areas.

As a researcher myself—though in a different area—I can certainly understand Dalmazzi's desire to monetize the results of his company's research. One of my friends used to quote Danny DeVito from Heist on this point: "Everybody needs money. That's why they call it money." That said, I think his defense of this policy elides some important points.

First, security issues are different from ordinary research results. Suppose, for instance, that Researcher had discovered a way to significantly improve the performance of Vendor's product. They could tell Vendor and offer to sell it to them. At this point, Vendor's decision matrix would look like this:

Not Buy	Buy
0	V - C

Where V is the value of the performance improvement to them and C is the price they pay to Researcher for the information. Now, if Researcher is willing to charge a low enough price, they have a deal and it's a win-win. Otherwise, Vendor's payoff is zero. In no case is Vendor really worse off.

The situation with security issues is different, however. As I read this message, Researcher will continue to look for issues in Vendor's products regardless of whether Vendor pays them. They'll be disclosing this vulnerabilities in progressively more detail to people who pay them progressively more money. Regardless of what vetting procedure Researcher uses (and "qualified users" really doesn't tell us that much, especially as "security professional" seems like a pretty loose term), the probability that potential attackers will end up in possession of detailed vulnerability information seems pretty high. First, information like this tends to leak out. Second, even a loose description of where a vulnerability is in a piece of software really helps when you go to find it for yourself, so even summary information increases the chance that someone will exploit the vulnerability. We need to expand our payoff matrix as follows:

	Not Buy	Buy
Not Disclose	0	V - C
Disclose	-D	?

The first line of the table, corresponding to a scenario in which Researcher doesn't disclose the vulnerability to anyone besides Vendor, looks the same as the previous payoff matrix: Vendor can decide whether or not to buy the information depending on whether it's worth it to them or not to fix the issue [and it's quite plausible that it's not worth it to them, as I'll discuss in a minute.] However, the bottom line on the table looks quite different: if Researcher discloses the issue, then this increases the chance that someone else will develop an exploit and attack Vendor's customers, thus costing Vendor D. This is true regardless of whether or not Vendor chooses to pay Researcher for more information on the issue. If Vendor chooses to pay Researcher, they get an opportunity to mitigate this damage to some extent by rolling out a fix, but their customers are still likely suffering some increased risk due to the disclosure. I've marked the lower right (Buy/Disclose) cell with a ? because the costs here are a bit hard to calculate. It's natural to think it's V - C - D but it's not clear that that's true, since presumably knowing the details of the vulnerability is of more value if you know it's going to be released—though by less than D, since you'd be better off if you knew the details but nobody else did. In any case, from Vendor's perspective the top row of the matrix dominates the bottom row.

The point of all this is that the situation with vulnerabilities is more complicated: Researcher is unilaterally imposing a cost on Vendor by choosing to disclose vulnerabilities in their system and they're leaving it up to Vendor whether they would like to minimize that cost by paying Researcher some money for details on the vulnerability. So it's rather less of a great opportunity to be allowed to pay for vulnerability details than it is to be offered a cool new optimization.

The second point I wanted to make is that Dalmazzi's suggetion that VoIPshield is just doing Avaya's QA for them and that they should have found this stuff through their own QA processes doesn't really seem right:

Final note to Mr. Zmolek. From my discussions with enterprise VoIP users, including your customers, what they want is bug-free products from their vendors. So now VoIP vendors have a choice: they can invest in their own QA group, or they can outsource that function to us. Because in the end, a security vulnerability is just an application bug that should have been caught prior to product release. If my small company can do it, surely a large, important company like Avaya can do it.

All software has bugs and there's no evidence that it's practical to purge your software of security vulnerabilities by any plausible QA program, whether that program consists of testing, code audits, or whatever. This isn't to express an opinion on the quality of Avaya's code, which I haven't seen; I'm just talking about what seems possible given the state of the art. With that in mind, we should expect that with enough effort researchers will be able to find vulnerabilities in any vendor's code base. Sure, the vendor could find some vulnerabilities too, but the question is whether they can find enough bugs that researchers can't find any. There's no evidence that that's the case.

Finally, I should note that from the perspective of general social welfare, disclosing vulnerabilities to a bunch of people who aren't the vendor but not the vendor seems fairly suboptimal. The consequence is that there's a substantial risk of attack which the vendor can't mitigate. Of course, this isn't the researcher's preferred option—they would rather collect money from the vendor as well—but if they have to do it occasionally in order to maintain a credible negotiating position, that has some fairly high negative externalities. Obviously, this argument doesn't apply to researchers who always give the vendor full information. There's an active debate about the socially optimal terms of disclosure, but I think it's reasonably clear that a situation where vulnerabilities are frequently disclosed to a large group of people but not to the vendors isn't really optimal.

Acknowledgement: Thanks to Hovav Shacham for his comments on this post.