Recently in SYSSEC Category

The second major attack described by Prasad et al. is a clip-on memory manipulator. The device in question is a small microcrontroller attached to a clip-on connector. You open the control unit, clip the device onto the memory storage chip, rewrite the votes, and disconnect it. There are a number of countermeasures we could consider here.

Physical Countermeasures
We've already discussed seals, but one obvious countermeasure is to encase the entire memory chip in plastic/epoxy. This would make it dramatically harder to access the memory chip. One concern I have about this is heat: were these chips designed to operate without any cooling. That seems like a question that could be experimentally answered. I think you'd want to use transparent epoxy here, to prevent an attacker from drilling in, access the memory chip, and covering it over, maybe with a small piece of plastic to permit future access. I also had an anonymous correspondent suggest encasing the entire unit in epoxy, but at most this would be the circuit board, since the device has buttons and the like; this would of course make the heat problem worse.

Cryptographic Countermeasures
Another possibility would be to extend the cryptographic checksum technique I suggested to deal with the dishonest display. At the end of the election when the totals are recorded the CPU writes a MAC into the memory over all the votes (however recorded) as well as writing a MAC over the totals. It then erases the per-election key from memory (by overwriting it with zeros). This makes post-election rewriting attacks much harder—the attacker would need to also know the per-election key (which requires either insider information or access to the machine between setup and the election) and the per-machine key, which requires extensive physical access. I think it's plausible to argue that the machine can be secured at least during the election and potentially before it. Note that this system could be made much more secure by having a dedicated memory built into the CPU for storage of the per-unit key, but that would involve a lot more reengineering than I'm suggesting here.

In their paper on Indian EVMs, Prasad et al. demonstrate that you can easily pry off the LED segment display module and replace it with a malicious display. At a high level, it's important to realize that no computer system can be made secure if the attacker is able to replace arbitrary components, since in the limit he can just swap everything out with lookalike components.

The two basic defenses here to use anti-counterfeiting techniques and to use cryptography with hardware security modules. Most of the proposals for fixing this problem (and the memory overwriting problem) are of the anti-counterfeiting variety; you seal everything up with tamper-evident seals and make it very hard to get/make the seals. Then any attacker who wants to swap components needs to break the seals, which is in theory obvious. Unfortunately, it's very hard to make seals that resist a dedicated attacker. In addition, sealing requires good seal procedures in terms of placing them and checking them with this many machines in the field it's going to be quite hard to actually do that in a substantially better way than we are doing now.

The other main defense is to use cryptography. The idea is that you embed all your sensitive stuff in a hardware security module (one per device). That module has an embedded cryptographic key and is designed so that if anyone tampers with the module it erases the key. When you want to make sure that a device is legitimate, you challenge the module to prove it knows the key. That way, even if an attacker creates a lookalike module, it can't generate the appropriate proof and so the substitution doesn't work. Obviously, this means that anything you need to trust needs to be cryptographically verified (i.e., signed) as well. Periodically one does see the suggestion of rearchitecting DRE-style voting machines to be HSM-based, but this seems like a pretty big change for India, both in terms of hardware and in terms of procedures for managing the keying material, verifying the signatures, etc.

However, there is an intermediate approach which would make a Prasad-style attack substantially harder without anywhere near as much effort. The idea is that each machine would be programmed by the Election Commission of India with a unique cryptographic key. This could be done at the same time as it was programmed for the election to minimize logistical hassle. Then at the same time that the vote totals are read out, the machine also reads out a MAC (checksum) of the results computed using that key. That MAC is reported along with the totals and if it doesn't verify, that machine is investigated. Even though the malicious display can show anything the attacker wants, the attacker cannot compute the MAC and therefore can't generate a valid report of vote totals. The MAC can be quite short, even 4 decimal digits reduces the chance of successful attack on a machine to 1/10000.

This approach is significantly less secure than a real HSM, since an attacker who recovers the key for a given machine can program a display for that machine. But it means that the window of opportunity for that attack is much shorter; if the key is reprogrammed for each election then you need to remount the attack between programming time and election time, instead of attacking the machine once and leaving the display in place indefinitely. It's also worth asking if we could make it harder to recover the key; if it's just in the machine memory, then it's not going to be hard to read out using the same technique that Prasad et al. demonstrate for rewriting vote totals. However, you could make the key harder to read by, for instance, having two keys, one of which is burned into the machine at manufacture time in the unreadable (hard to read) firmware which is already a part of each machine and another which is reprogrammed at each election. The MAC would be computed using both keys. This would require the attacker to attack both the firmware on the machine (once) and the main memory (before each election).

Clearly, this isn't an ideal solution but as I said at the beginning of this series, the idea is to improve things without doing too much violence to the existing design. Other approaches welcome.

LaTeX is, of course, the standard document production system for computer science documents (with a tiny minority using {t,n}roff). It's also a good example of one of the standard CS approach of solving problems by inventing a new programming language. Consider that designing a modern Web page involves using three separate languages, HTML, CSS, and JavaScript (of these only JavaScript is obviously Turing complete). As another example, when you print documents, you generate PDF or PostScript, which are just programming languages (PostScript is Turing complete, not sure about PDF)... Anyway, LaTeX is a bit too complete, it turns out.

Steve Checkoway, Hovav Shacham, and I have a paper at LEET describing how a malicious LaTeX file can compromise your computer:

We show that malicious TEX, BIBTEX, and METAPOST files can lead to arbitrary code execution, viral infection, denial of service, and data exfiltration, through the file I/O capabilities exposed by TEX's Turing-complete macro language. This calls into doubt the conventional wisdom view that text-only data formats that do not access the network are likely safe. We build a TEX virus that spreads between documents on the MiKTEX distribution on Windows XP; we demonstrate data exfiltration attacks on web-based LATEX previewer services.

This isn't just an issue of LaTeX files. While people do sometimes run LaTeX files prepared by others, generally those are only files you get from people you know, i.e., your collaborators. But it turns out you can also embed malicious code in BibTeX files, which people routinely copy and paste from totally untrusted sources (the BibTeX entry for this paper is here) in order to simplify reference management. The other major case is LaTeX class files, which people download for conference submission.

The good news is that the main threat is on Windows because LaTeX on UNIX is more restrictive about where you can write files. The bad news is that it's also an issue if you run Emacs (look, another embedded language!) with AucTeX (the best way to edit LaTeX files), AucTeX writes executable cache files in the local directory, so you're at risk.

Happy editing!

Henry Farrell over at Crooked Timber reports on having his laptop lost and then recovered. He then goes on to recommend a variety of precautions for future incidents:

Also - in the spirit of locking the barn door after the horse has gone but to your very great surprise been returned later through the benevolence of strangers - recommendations for minimizing the pain of stolen machines.

(1) Back Up Everything Important somewhere external. This is the one measure I did take - and the pain would have been far, far greater had I lost my work along with the machine. I use Sugarsync which keeps the work documents on my various machines in sync with each other as well as giving me an online back up - others swear by DropBox, SpiderOak and other services.

(2) Make sure that your account is password protected. I didn't do this - remarkably stupidly - but appear to have gotten away without loss of personal information. You shouldn't take this risk. I won't again.

(3) Set up a firmware password if you have a recently made Mac. Makes it much harder to wipe the OS.

(4) Consider buying anti-theftware like Undercover. Depending on your tolerance for risk, this may be too expensive for the benefits provided (me: my risk tolerance has decreased substantially since this happened to me).

(1) is of course good advice. Backups are good practice for a variety of threat models, including just plain hardware failure. I personally run backups and also keep most of my important stuff in a revision control (originally CVS but I'm moving over gradually to SVN).

Recommendation (2) is nowhere near strong enough. Passwords (barely) protect you against someone who has ephemeral physical access, but if you don't encrypt the hard drive, then a dedicated attacker can either boot up in repair mode (the BIOS password (#3) makes this more difficult) and read your data off or just pull the hard drive out. What you need here is disk encryption. Luckily, the Mac comes with FileValult: a quite serviceable (if a hair slow) disk encryption system.

Recommendation (4) makes some sense, though I doubt I would bother myself. I've never lost a laptop and when we multiply out the chance of loss times the chance of recovery and factor in the likelihood that your laptop will be covered by homeowner's insurance, I'm not sure that the $50 for Undercover is a good bet.

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.