July 21, 2008

CherryPal

Gizmodo covers the fully buzzword compliant CherryPal PC. The general idea is that it's a lightweight home device that relies on "cloud computing" for its backend computational operations. Some surprising security claims are also being made. Here's what's on Gizmodo (in what looks like a press release):
CherryPal is the only company that provides a patent-pending combination of both hardware and software encryption, making it highly secure. The CherryPal also offers a patent-pending single software layer technology. This collapses the operating system and browser into one layer, where there had traditionally been three separate layers. It makes the computer exponentially faster and virtually eliminates any risk of bugs or viruses for the user.

There appear to be two claims here. First, they are using "a combination of both hardware and software encryption", which makes things really secure. Now, it's true that there are settings in which hardware encryption is more secure than software encryption, but it's hard to see why they apply here. The major advantage of hardware encryption is that you can build hardware which makes the keying material inaccessible even if you have control of the device. So, for instance, if your device is remotely compromised the attacker wouldn't be able to steal the keys. As I said, there are situations where this is important, but it's not clear that this one; if your machine is remotely compromised, you're probably going to want to completely wipe it, and it's not really that hard to replace the crypto keys as well. Moreover, it's not clear from this material that they even are using hardware-based key isolation.

The second claim is this thing about the "patent-pending single software layer". I'm not sure what this means either. I usually think of the operating system and browser as two layers, so I'm not sure what the third layer is. It sounds like the claim is that the browser is running directly on the metal, which isn't impossible, but it's pretty unclear what the advantage is. One of the major features of modern systems is precisely that they separate the OS from the applications; this allows the OS to enforce policies on the application, as well as to contain compromise of the application (though of course you still have to worry about privilege escalation attacks.) I'm not aware of any security theory that indicates that it's more secure to have only one software component. While we're on the topic, since this sort of monolithic design is the way that systems used to work, it's not clear what's patentable here. (A little searching didn't turn up the patents, but if someone points me to them, I'll take a look.)

Oh, this is good too:

CherryPal is also the first company since Apple Computers to use a Power Architecture-based processor in a personal computer by employing the Freescale MPC5121e mobileGT processor. This chip allows for built-in graphics and audio processing, all while consuming only 400 MHz of power.

400 MHz isn't really that usual a unit of power. Am I supposed to multiply by Planck's constant here?

Posted by ekr at 9:55 PM | Comments (6)

May 10, 2008

Red Carpet Club WiFi

Danny McPherson posts about his experience with the free WiFi in the Unied Red Carpet Club:
More interesting is perhaps the access model they employ. To login, all you need is the United Mileage Plus number of the primary Red Carpet Club account holder. Now, having long questioned the wisdom of a luggage tag that displays these numbers, be it a "hole-punched" Mileage Plus membership card, or a more obvious oval-shaped Red Carpet Club tag, I'm even more wary now. But if you're in bind and need your airport wireless fix, odds are you won't have to walk far to find one available for the taking. As a matter of fact, I see two from where I'm sitting right now.

I've yet to explore how difficult it would be to exhaustive search for valid numbers, or if multiple logins are permitted at a given time, or how far outside of the Red Carpet Club these numbers are valid, or... I also wonder how long it'll be until some poor schmuck is arrested for allegedly downloading child porn from an airport wireless network...

If this were a wired network this wouldn't be a security problem. After all, if you're inside the RCC, presumably you're an RCC member (unless you bought a day pass), in which case you should be entitled to use the network. But as Danny indicates, the wireless AP is probably accessible from outside the RCC, so if you sit outside the club, you should be able to get on the network, making it just a matter of having a valid mileage plus number, which you can get off of someone's luggage tag.

As far as exhaustive search goes, MP numbers are 11 digits long, but the first digit seems to always be zero, so this is a 10 digit space. I don't know how many RCC members there are, but Wikipedia claims that there are about 750,000 Premier and Premier Executive members, so let's say there are on the order of 200,000 RCC members, or 2*10^{-5} of the space. If the numbers are randomly distributed, you'd need to search about 100,000 numbers in order to find one. This could take quite some time (over a day at one per second). You might be able to get some leverage because the distribution isn't random. They seem to be issued in some kind of increasing sequence, though there seem to be too many numbers for it to be strictly sequential. If there's a check digit like in credit card numbers this would make the space a lot easier to search. (If someone knows the actual algorithm, please write in.) Of course, you only need to know a few valid numbers, so this might not be a totally prohibitive attack if reading it off someone's tag weren't so easy.

Three more thoughts:

1 See draft-rescorla-stateless-tokens for a description of some techniques for avoiding the need for a centralized cookie database.

Posted by ekr at 8:56 PM | Comments (3)

May 8, 2008

MS Word wants to open a port on your machine... wait what?

Even the most diehard TeXhead has moments when he needs to read some Word document. Tonight was such a night and I have Office 2004 on my machine for just such an eventuality (Please don't write in to tell me that I should run Pages. As I said, I don't want to run either of them, but I also don't want to deal with Pages/Word incompatibility.) Anyway, I boot up Word and the Leopard firewall asks me if I'd like to let Word listen for network connections. I go to click no and either manage to click it or raise some other window or something. The dialog disappears and when I check the firewall it sure does say to block MS Word. So, that's OK, I guess.

And then I get to thinking, "Why is Word opening up TCP listening ports anyway?" So, I run netstat -a | grep LISTEN and get: 

[49] /usr/sbin/netstat -a | grep LISTEN
tcp4       0      0  *.3369                 *.*                    LISTEN
...

Hmmm. What's 3369? Google doesn't know, so that's not good. I close Word and the port goes away and lsof confirms it's Word: 

[52] /usr/sbin/lsof -i TCP:3369

COMMAND  PID USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
Word    8198  ekr   16u  IPv4 0x6c4d66c      0t0  TCP *:3369 (LISTEN)

I shut down Word and my WiFi and restart it, but it's not listening now. Maybe I need the network on. Sure enough, I bring the WiFi back up and restart Word and now it's listening, but on a different port: 3828 this time. Stranger and stranger. Now ordinarily this would only be about a 4.0 freakout on a scale of 1 to 10, but it turns out that I only recently installed Office on this machine and was unaware of the following delightful property of MS AutoUpdate: it only installs one update at a time, no matter how many updates are pending. So, when you have 10-20 updates to install, and you're just letting update run itself, it takes forever to get uprev. The consequence of this is that I was loading random people's documents with some two year old (and vulnerable) version of Word. Who knows what malware I've had the joy of installing. This jacks things up to a freakout factor of about 6.2.

Next step: compare to another machine. It shows up on my other Mac, which is a little comforting, but of course that machine could be infected too. I double check with Hovav, who is about as paranoid as I am, and his copy of Office is is listening, but on some other random port. That's sort of comforting. This is starting to look a lot less like malware and a lot more like a feature of Word. A little more digging tells us the process name that is actually doing the listening. It's Word (as I knew) but with some wacky argument starting with -psn_0_.... Searching on this, we find out that I'm not the only person who has had this question.

If you close UDP 2222, then no other computers will know which TCP port your copy of word has chosen to listen to (in the 3000-3999 range), because that info is broadcasted in the UDP packets. The protocol is thus: Your copy of word spews it's serial number (encoded) and the TCP port it is listening on in a packed on UDP 2222. Other copies of word on the network get this packet and then respond the your copy of word on the specified TCP port if they have the same serial. Then one copy shuts down.

I guess it was malware after all. Outstanding!

Posted by ekr at 9:54 PM | Comments (8)

April 21, 2008

Automatic exploit generation

In any cost/benefit analysis of vulnerability policy, we have to factor in the impact of exploitation that results from fixing the vulnerability. In particular, if you provide a full description of the vulnerability at the same time as you patch it, then it's generally easy for an attacker to construct an exploit. Since patch distribution and installation can take between hours and weeks, this gives the attacker a significant window of opportunity to mount attacks before people patch their machines.

A natural response to this is to simply release patches but not descriptions of vulnerabilities, on the theory that the patches disclose less. It's obvious that this isn't true with open source systems, since it's trivial to examine a given change and determine what attack it's designed to stop, but there have also been reports that attackers reverse engineer binary patches (in some cases within hours) to construct exploits. In this year's USENIX, Brumley et al. take this to its logical conclusion and describe a technique for automatically generating exploits based on patches. This doesn't really change the situation much as far as I can tell; it was widely believed this was possible, and while this tool takes seconds to minutes instead of hours, it was never plausible that you'd get complete patch deployment inside of 12-24 hours anyway, so shaving a few hours off the attacker time may not make much of a difference.

The authors describe a number of techniques (obfuscation, encrypted patches, P2P patch distribution) one might imagine using to reduce the impact of fast attack generation, and conclude (correctly IMO) they're not that likely to work. As I understand it, the critical path item in patch installation for important systems isn't obtaining the patch but testing it on sacrificial systems to make sure it doesn't introduce instability, and that creates an inherent lag that probably can't be removed with a new distribution method.

Another alternative (though it goes against the trend in recent practice) is to be less aggressive about releasing patches for vulnerabilities that haven't already been disclosed. The faster that attackers can respond to new vulnerabilities by comparison to defenders, the more that fixes released in an orderly fashion look like zero-day vulnerabilities and so the less attractive it looks to fix vulns that aren't generally known (Res04 has some analysis of this issue.)

Posted by ekr at 6:35 AM | Comments (1)

April 6, 2008

On the security of traffic school

Title: On the security of traffic school After a recent ticket (received while on a conference call, believe it or not), I opted for traffic school. In Santa Clara County, if you want Web traffic school, you need to take it from DriversEd.com. Luckily, as of 2008 you no longer need to go in and take a final exam in person; you can do the whole thing online, which makes the process comparatively painless.

Unsurprisingly, DriversEd.com has some features designed to ensure you receive the full educational value of the traffic school experience:

Of course, as a security guy the first thing I think about is how to bypass this stuff. The timers are easy: they're in JavaScript. If you run your browser without JavaScript they go away, so you can in principle zip through the pages as fast as you want. I didn't see any evidence this was enforced on the server side.

Of course, then you're not paying attention, so you may have some trouble with the intermediate tests. Luckily, if you get an answer wrong, they give you the right answer and then give you a slightly different selection of questions, but with a lot of overlap with the previous ones. I wasn't brave enough to try this, since there might be some limited try feature, but it looks like you could just fail your way to having all the answers. And, of course you could Google the answers. So, clearly, one could just zip through all the pages and then flail through the self-test.

The security questions are obviously designed to stop you from outsourcing the task of taking the class to someone else. You'd need to give them some personal information. Most of it (weight, DL#, height, DOB, zip code) isn't really private. You might not want to give your contract click monkey your SSN, though. Weirdly, the registration program prompts you for this stuff, even though a lot of it is on your license. I wonder if you could just type fake answers, in which case you would presumably be OK with having someone do it for you.

If you were willing to do some programming work, you could probably just screen scrape the pages, clicking through the instructional pages, picking out the self tests and answering them by random guessing + corrections (nicely highlighted in red and green), and then answering the security questions. With some luck, I suspect I could do this in about 20% more time than it would take to just go through the class the old fashioned way. That's what a real programmer would do.

Posted by ekr at 8:45 PM | Comments (0)

April 3, 2008

Security issues with automatic URL dereference

Martin Rex points to this whitepaper about a claimed security flaw in RFC 3280 (the RFC for X.509/PKIX certificates). The issue is that certificates can contain a variety of URLs, including:

When your client goes to validate the certificate, it may (automatically) try to retrieve what's on the other end of the URL. Arguably, this is bad:

However, elegant does not usually mean secure. The problem in this case is that until the certificate chain is verified, the user sending the certificate is usually untrusted. This means that the specified URI has to be treated as potentially evil input from an unauthenticated user. This simple fact is missing from the "Security Considerations" section of the RFC and thus implementors have gotten it wrong.

When implemented naively, this means that an unauthenticated user can embed arbitrary URIs within a certificate and can thus force the verifier to send out arbitrary HTTP requests on its behalf -- for example to networks formerly unreachable to an attacker. The response itself is not forwarded to the attacker, so he is limited to blind attacks. A specific case of this can be used to gain information about the verifier -- for example whether he has opened a certain email or office document. As more than one URI can be embedded in the certificate, it would also theoretically be possible to gain information on internal networks using timing information. For this, one would create a certificate with one URI controlled by the attacker, one URI internal to the attacked, one URI controlled by the attacker and measure the timing distance between the two accesses to the attacker-controlled URIs. In practical experience, this is still theoretical, though.

This certainly is technically true, but it's unclear how serious this issue is. After all, if your mail client is willing to read HTML mail (and many are) and if it automatically retrieves inline images (many do), then it's pretty easy for the sender to verify that you read a given message, and potentially mount the timing attacks these researchers describe (though it's an open question whether this would work.) There are actually a number of protocols that have automatic URL dereference built in.

There's actually something more interesting, though tricky to exploit (and harder to deal with) here. The white paper talks about probing internal servers, but depending on what services are running there and what ports they're running on, there's some possibility that the client (presumably behind the firewall) could talk to the internal server and do more than detect it. Theoretically, it might be able to give it instructions that it would follow. How well this actually works depends a lot on what the internal service you're talking to is. The attacker doesn't get much control of the message it sends to the server, it just gets to embed the URL in some HTTP GET request. Obviously, since the client is talking HTTP, it would be most convenient if you were talking to an HTTP server, since you'd be protocol compliant. In theory, HTTP GETs are not supposed to have side effects on the server, but of course that happens all the time.

If the server isn't HTTP, then you have to get pretty lucky. You need to be able to encode a meaningful protocol request in the URI and the server needs to be resilient enough to nonconformant traffic that it's willing to ignore the bogus HTTP request wrapper and process whatever request is embedded in the URI. This obviously isn't superconvenient for the attacker, who would like a much finer degree of control of the protocol messages, like you'd get with a client-side program (hence the browser same origin policy).

Posted by ekr at 8:27 PM | Comments (2)

March 2, 2008

James Bond and the futility of technical access controls

OK, so Mrs. Guesswork and I just finished watching Casino Royale and something bugging me. (spoilers after the jump).

Bond is in this poker tournament playing for $150 MM. The money is being held in escrow by a swiss bank. At the beginning of the tournament, each player enters their password into this briefcase-keypad-terminal-crypter thingy held by said banker. At the end of the tournament, the winning player enters his password and the destination account and the bank transfers the money into that account. After Bond wins, the villain (Le Chiffre) kidnaps him and the Bond Girl (Vesper Lynd) so that he can torture the account number out of her and the password out of Bond.

How does this make any sense at all? First, why does Le Chiffre need the account number? That's where Lynd wants the money to go! He wants the money put in his account and Lynd doesn't know that number. Second, why does he need the password? Remember that any one of the players could have won, so they all have passwords. What controls who gets the money is that the banker only lets one of them transfer the money out of escrow. Wouldn't it be much simpler to kidnap the banker and force him to hand over the money? He's not a secret agent so he's probably a lot easier to kidnap and threaten than Bond is. Moreover, if Le Chiffre shows up with Bond's password and asks that the money be put in his account, why would the banker allow that? Clearly something is fishy, so Le Chiffre will probably have to threaten him anyway. Why not keep things simple and start with the banker.

I should mention that when later the banker shows up to complete the real money transfer with Bond and Lynd enters the wrong account number, that does make sense. She needs the banker to accept the transfer and needs Bond to authenticate it. It makes sense, that is, except for the password, which is still pretty pointless, unless your theory is that after you win, someone else is going to pose as you and have the money transferred into your account. A far simpler system would be that when you register for the tournament you give them the account number where you want your winnings to and have the subsequent transfer happen automatically.

Posted by ekr at 9:38 AM | Comments (9)

February 28, 2008

Yeah, that's going to work...

One of the main reasons to have a blog is to call a bad idea a bad idea. Here's one. Former FBI Agent Patrick J. Dempsey suggests:
It's obvious that the Internet requires some type of governance. But it is just as obvious that trying to establish this governance through the numerous legal systems might not be practical. The other possibility for governing the Internet, and, more specifically, the criminal activity that occurs on the Internet, would be to change the structure of the Internet. Although I don't support ideas like the "national firewalls" put in place by some countries, this type of solution does afford some level of control over Internet traffic flowing through said country.

However, knowing all the possibilities with disguising or "spoofing" one's information on the Web, I'm not sure that there is a way to truly "protect our borders" when it comes to the Internet. The solution might be to establish two Internets -- the current Internet and a new, more secure Internet where users would be required to register prior to gaining access. Once again, though, we're confronted with the issue of what would be the governing body that would manage the user registrations? Would it be an organization similar to the IANA (Internet Assigned Numbers Authority) or InterNIC that would manage user registrations on the "new" Internet, or do we need to establish an entirely new entity to manage a more secure Internet?

The problem with this idea is it's totally confused about the security problem with the Internet, which has a lot more to do with stupid users and insecure software than it does with failing to authenticate everyone with a modem.

Let's play this out: you set up your new secure Internet. There's already an Internet 2, so let's call it Internet 3 or I3. Anyway, we've got I3 up and running and before they'll give you a connection you have to give them your fingerprint, irisprint, a blood sample and the keys to your car. Of course, if if you want I3 to be useful, you have to let pretty much anyone on, so just like the Internet, I3 is full of hackers. And since your software isn't any more secure than it was before, you're still just as likely to have your machine compromised. Now, it's true that having positive identification for each user might forensics a tiny bit easier: once you've managed to track the user down to the account they initially logged in from, you know who to arrest. But of course, hackers use compromised machines as stepping stones, so tracking them down isn't easy, and of course it's not exactly difficult to steal people's account information and log in as them instead of yourself.

Even if we somehow were able to create an I3 without any hackers on it, it wouldn't stay that way for long. I3 is one big sterile area, so as soon as any significant number of compromises happen it's game over. Initially, I3 is going to be pretty lame, so people are going to use both the Internet and I3. And since the Internet is full of hackers and their machines are compromised and they're going to use the same machines for both the Internet and I3, it's not going to be long before plenty of I3 credentials are circulating in the hacker community. Creating isolated networks is really hard even when you're working in real high security environments. It's basically impossible when you're dealing with millions of people, many of whom are willing to run any random .exe file you send them.

Posted by ekr at 8:31 PM | Comments (4)

January 5, 2008

Holy airgap, Batman!

Check out this Wired article and the FAA Report on which it is based about how the Boeing 787 control network is connected to the in-cabin entertainment network, which is probably not the design your average security guy would have chosen:
These special conditions are issued for the Boeing Model 787-8 airplane. This airplane will have novel or unusual design features when compared to the state of technology envisioned in the airworthiness standards for transport category airplanes. These novel or unusual design features are associated with connectivity of the passenger domain computer systems to the airplane critical systems and data networks. For these design features, the applicable airworthiness regulations do not contain adequate or appropriate safety standards for protection and security of airplane systems and data networks against unauthorized access. These special conditions contain the additional safety standards that the Administrator considers necessary to establish a level of safety equivalent to that established by the existing standards.

The FAA imposes the following requirement:

The design shall prevent all inadvertent or malicious changes to, and all adverse impacts upon, all systems, networks, hardware, software, and data in the Aircraft Control Domain and in the Airline Information Domain from all points within the Passenger Information and Entertainment Domain.

Obviously, this specifies a goal rather than a design, but it's pretty hard to see how this goal could be met without at minimum an airgap between the ACD/AID, and the PIED. I'm unaware of any networking technologogy which allows you to connect two networking domains together which can also guarantee that computers in the untrusted domains can't negatively impact computers in the trusted domains. The classic solution that falls short of airgaps is of course firewalls, but then you have to worry about vulnerabilities in the firewall, so this certainly doesn't prevent all attacks.

The more interesting question is whether an airgap is enough? An airgap provides good protection against logical attacks from the PIED network, but not against physical ones. Even if the ACD/AID cables are physically separate from the PIED cables, do they run through areas which are potentially accessible from the passenger cabin (especially the lavs!)? Do they use cryptography so that an attacker who accessed them couldn't directly talk to the ACD/AID network? Note that this isn't perfect protection, but it could substantially lower the attack surface.

Two other things worth noting here:

I don't know that much about how this kind of in-flight network is usually designed or how much security analysis usually goes into it, but to the extent to which we're concerned about passenger subversion of flight control systems, this seems like an unusually hostile threat environment. In particular, if the plane is completely fly by wire, does that mean that someone who controlled the computers could potentially fly the plane where (or into) anything they wanted? What features are provided for regaining manual control in the case of such subversion?

Posted by ekr at 9:51 AM | Comments (4)

December 14, 2007

Ohio voting reports

Ohio just published the results of their voting system review. They examined Hart, Premier Election Systems (formerly Diebold) and ES&S. Hart and Diebold were part of the California TTBR and a skim of the TOC and a sampling of the sections suggests that these reports mostly confirm the California/UC result (with one interesting new Hart vuln that allows an attacker with physical access to the interfaces to emulate keypresses, thus automating vote injection.) ES&S was not part of the UC review (but a smaller review was done afterward) and the Ohio team seems to have found serious problems in the ES&S system as well.

Posted by ekr at 10:23 AM

December 13, 2007

San Francisco and Open Source election systems

San Francisco has selected Sequoia Voting Systems voting machines, replacing their current ES&S systems. Reading the coverage, it's clear that whether SVS would open source their software was a big issue. It's not clear, however, whether SVS actually agreed to. Here's the Merc:
"This is a good system in front of us," Alioto-Pier said. "We should be excited for having it." She added that she felt open-source voting was important, but not readily achievable currently.

"Many of us are holding our noses around this vote," said Supervisor Tom Ammiano, who also opposed the resolution but acknowledged the agreement contained "some positives."

Ammiano said Sequoia had agreed to a third-party inspection of its source code and to bring its software into open-source compliance within a year.

Ammiano said a long-term solution might be for San Francisco to consider furnishing its own computer voting systems, to 'ensure that open source and transparency will happen,' he said.

The Examiner doesn't say anything about such a commitment:

"Until we take a stand and either force the vendors to open their source code to us or develop or own open source voting systems, really, what we did this past cycle is the only way that we can guarantee that every voters vote gets counted," he said.

Supervisor Sean Elsbernd countered that opponents "need to be a little bit more real" about The City's choices.

"Let's vote down this contract, and then what? We get to keep ES&S, the frauds. We cannot do that," Elsbernd said.

Supervisor Gerardo Sandoval said that with three elections on the horizon that The City needed to approve the contract.

"These elections are too important to have the results tabulated a month after the rest of the country knows what happens," he said, adding, "We can deal with the open- source issue at a later time."

I can't really tell whether SVS promised anything or not, but I'm not sure it really matters much one way or the other. First, if what you're concerned about is openness about the software the election is running, you don't need open source; you need published source. Open source software is about your ability to copy it and use it for your own purposes, but it's not clear why that's important for running elections. It's not like we're going to have election software up on SourceForge and then have the State of California compile the head of tree six weeks before the election. I suppose it's sort of possible that you would want to allow independent vendors to use Sequoia's software on their own hardware platforms, but given the certification requirements for the hardware—and the fact that each vendor has their own hardware—that seems fairly problematic.

If you're concerned about the security of elections, what you really need is to know that the software running the elections can be and has been reviewed. At most, though, that would require that the vendors publish copies of their source code so that people could review it. In this case, though, the software in question has already been reviewed fairly intensively, and the reviewers found fairly serious vulnerabilities. Given that, it's not clear how much you'd really learn about the security of the system from having the source code public so that people could informally review it.

Posted by ekr at 10:39 PM | Comments (1)

November 23, 2007

Combined software and services and wiretapping

For obvious reasons, law enforcement and investigative agencies aren't incredibly fond of encrypted communications. The most popular responses to this difficulty have generally been one or more of:

None of these have been particularly successful: the strong crypto cat is out of the bag, users have overwhelming rejected key escrow, and although people do sometimes have their keys subpenad (the UK has a law requiring complaince), there are standard cryptographic techniques that provide "perfect forward secrecy" so that even if your keys are disclosed after the fact your communications aren't readable. The government in the US has had some success with keyloggers, spyware, etc., but they either require physical access or compromise of the system in question.

The popularity of combined software/service operations like Hushmail and Skype opens up a new avenue, however. It's recently come out that Hushmail has in the past handed over keys to the government for users who used their online encryption system. This was made easier by Hushmails "software as a service" type architecture, where they do the encryption and decryption on their site. Hushmail also provides an option where you can download a Java applet, but it should be clear that under the right legal constraints, they could theoretically put a backdoor in the applet you downloaded, too.

Similarly, the German police have recently complained that they can't monitor Skype calls. They say they're not asking for the encryption keys, but because of Skype's architecture and the fact that Skype is involved in authenticating each call, it should be clear that Skype could mount a man-in-the-middle attack on your phone call and hand over the keys. They could also just give you an "upgraded" software version with a back door.

Combined software/service systems like Skype and Hushmail are uniquely susceptible to this kind of lawful intercept attack (or for that matter to cheating by the vendor of any kind.) If you use third party software than you don't have to worry about your ISP cheating you because they can't—they don't have the keys. And while your software vendor could potentially cheat you, they don't have the kind of constant contact with you that Skype or Hushmail does, so they would generally need to put a back door in every copy of the software, which carries a much higher risk of discovery and of users switching software. Who wants to run software with a deliberate back door?

Posted by ekr at 5:33 PM | Comments (6)

November 5, 2007

Voting talk at Stanford Security Seminar

I'll be speaking tomorrow at the Stanford Security Seminar:
Some Results From the California Top To Bottom Review

Eric Rescorla

In Spring of 2007, the California Secretary of State convened a team of security researchers to review the electronic voting systems certified for use in California. We were provided with the source code for the systems as well as with access to the hardware. Serious and exploitable vulnerabilities were found in all the systems analyzed: Diebold, Hart, and Sequoia. We'll be discussing the effort as a whole, providing an overview of the issues that all the teams found, and then discussing in detail the system we studied, Hart InterCivic.

Joint work with Srinivas Inguva, Hovav Shacham, and Dan Wallach

If you want to listen, heckle, whatever, it's at 4:30

Posted by ekr at 11:36 AM | Comments (1)

October 13, 2007

Some confusion about the threat model

The Swiss are somehow using quantum crypto to secure e-voting.
Developed by id Quantique in collaboration with the Australian company Senetas, the Cerberis quantum cryptography system will be used to protect election data relayed over a fiber optic connection. Unlike conventional Internet cryptography protocols, which use public key infrastructure, quantum cryptography relies on the principles of quantum uncertainty and generally involves encoding information into photons in a manner that will be noticeably and irreparably disrupted by any form of interception or monitoring. The cryptographic technique is still considered radically experimental, and this is one of the first practical applications of the technique.

Under ideal circumstances, quantum cryptography can ensure that communications between two parties have not been overheard. In the real world, however, quantum cryptography is subject to a number of different attacks. At present, any particle system is probably immune to such attacks because of the technical knowledge required to carry one out.

"We would like to provide optimal security conditions for the work of counting the ballots," said Geneva state chancellor Robert Hensler in a statement. "In this context, the value added by quantum cryptography concerns not so much protection from outside attempts to interfere as the ability to verify that the data have not been corrupted in transit between entry and storage."

I don't really understand what threat this is intended to counter. You've got some set of precincts (or whatever they're called Switzerland in) where the voting actually occurs. Those precincts are equipped with optical scanners, DREs or whatever, and they collect the votes. The votes (or maybe just counts) are sent to election central, where they're aggregated and the winners are determined. Based on this somewhat confusing article, they're using quantum crypto to secure that transmission over dedicated optical lines.

This seems both unnecessary and unwise. It's unnecessary because you don't really need to use a network to move the data. Just write it on CDROMs and drive or mail it to election central. The only reason to move it over a network is to make it a bit faster—something which seems sort of irrelevant if the election is being held within a single city. Even if you for some reason think that shipping stuff is too slow, you can always send the data over the network and then follow up with physical media as a double check. Note that the security issue here isn't primarily confidentiality—this data is sensitive but not that confidential, especially if you're just shipping tallies around. You just need integrity and you can double-check against the physical copies to match the preliminary results to the final results.

As for unwise, it's a really bad idea to have the computers at election central connected to the network, since that's a potential avenue for intrusion. Even if you use cryptographic (quantum or otherwise) access control to prevent any communication from the outside world, you're deliberately letting precinct devices connect to election central, which allows someone who has compromised a precinct device to potentially escalate privileges up to a compromise of election central. Since those devices generally aren't secured that carefully, That's not a really good design choice—even if we ignore the usual reasons why quantum crypto isn't that convenient.

Posted by ekr at 9:59 PM

September 1, 2007

iPhone unlocking

These guys claim that they have a program to unlock the iPhone. For those of you who aren't mobile phone wonks, here's how things work. In principle, the iPhone can work with two networks in the US: AT&T (formerly Cingular) and T-Mobile. Sprint and Verizon use a different cellular technology. The iPhone uses the European standard, GSM. One of the nice features of GSM is that the caller's information is contained on a chip called a Subscriber Identity Module (SIM). This has two implications:

For our purposes the second property is more interesting, because it allows consumers to mix and match phones and networks, forcing mobile phone carriers to compete on the basis of network quality rather than of who offers the coolest phones. Obviously, phone companies would prefer not to have to compete on these grounds; if you have to pay for a new phone whenever you want to switch carriers this disincentivizes switching. 1 One technique for stopping switching is to SIM lock the phone. The carrier (or more likely the vendor) programs the phone so it only works with a SIM from that carrier. However, generally the information about how to unlock the phone leaks somehow and it's pretty common for there to be third-party unlocking services. Sometimes the carrier will even do it for you; T-Mobile will if you've had the phone for more than 90 days.

This brings us to the topic of the iPhone. The iPhone is sold at the Apple store (and, of course, the AT&T store, but you have to be kind of nuts to go to the AT&T store) but SIM locked to AT&T. Naturally there's been some interest in unlocking it. An unlocked iPhone could also be used with T-Mobile in the US (a modest advantage in terms of coverage but a big advantage in terms of price) but could also be used with a non-US carrier.

A number of different techniques have been found for unlocking the iPhone (summary here) but all the readily available ones are either expensive (requiring some new hardware) or somewhat scary (opening it up and soldering some stuff). As noted above, there have been claims of software-only solutions but as of yet there doesn't appear to be any such software publicly available. Obviously something like this would be better than having to screw with the hardware.

This is all a basically separate issue from the question of running arbitrary software on the iPhone. As everyone knows, the iPhone is a closed platform, so, unlike your computer, you can't (officially) just load whatever software you want onto it. That protection has been broken for some time now (see here) and I have several friends who are running arbitrary software on their iPhones. Of course, it may be the case that being able to break that protection is important to making a software unlocking solution work. I don't think we'll know that till we see such a solution in action.

Oh, one more thing: the only people who claim to be offering unlocking software intend to sell you the software. However, I would expect that very shortly after such software is released, it will be reverse engineered and a free solution will be produced.

1. An additional complication is that in the US, at least, many carriers subsidize the initial purchase of the cell phone and require a contract with a cancellation fee, but that's just another way of making you pay to switch.

Posted by ekr at 7:42 AM | Comments (1)

August 31, 2007

Good thing I don't bank at Bank of India

Computerworld reports that the Bank of India Web site was attacked and seeded with a rather excessive amount of malware:
Although the bank's site had been scoured of all malware by Friday morning, it's currently offline. "This site is under temporary maintenance and will be available after 09:00 IST on 1.09.07," a prominent message currently reads.

Researchers at Sunbelt Software Inc. first posted details of the hack yesterday afternoon after finding rogue code embedded in the site's HTML. That code, actually an IFRAME exploit, silently redirected users to a hacker server, which pushed 22 different pieces of malware onto vulnerable PCs. By Sunbelt's tally, the malware included one worm, three rootkits, five Trojan downloaders, and several password stealers. "The biggest issue is the sheer volume of malware we've had to analyze," said Alex Eckelberry, Sunbelt's CEO, in a blog posting yesterday.

I guess if something's worth doing it's worth doing right. Outstanding!

Posted by ekr at 9:42 PM

August 20, 2007

More on the Skype outage

Here's Skype's official word on what caused their outage:
In an update to users on Skype's Heartbeat blog, employee Villu Arak said the disruption was not because of hackers or any other malicious activity.

Instead, he said that the disruption "was triggered by a massive restart of our users' computers across the globe within a very short timeframe as they re-booted after receiving a routine set of patches through Windows Update," Arak wrote.

Microsoft Corp. released its monthly patches last Tuesday, and many computers are set to automatically download and install them. Installation requires a computer restart.

"The high number of restarts affected Skype's network resources. This caused a flood of log-in requests, which, combined with the lack of peer-to-peer network resources, prompted a chain reaction that had a critical impact," Arak wrote.

Arak did not blame Microsoft for the troubles and said the outage ultimately rested with Skype. Arak said Skype's network normally has an ability to heal itself in such cases, but a previously unknown glitch in Skype's software prevented that from occurring quickly enough.

Some thoughts:

Posted by ekr at 9:46 PM | Comments (3)

August 8, 2007

Infrant SSH backdoor

Infrant (makers of ReadyNAS, now owned by Netgear) just released a security advisory for remote root SSH access to their box:
NETGEAR has released an add-on to toggle SSH support for the ReadyNAS systems based on a potential exploit to obtain root user access to the ReadyNAS RAIDiator OS. Each ReadyNAS system incorporates a different root password that can be used by NETGEAR Support to understand and/or fix a ReadyNAS system remotely using the ReadyNAS serial number as a key. An attacker that has obtained the algorithm (and your serial number) to generate the root password would be able to remotely access the ReadyNAS and view, change, or delete data on the ReadyNAS.

ReadyNAS installation most vulnerable to this attack is in an unsecure LAN and where the ReadyNAS SSH port (22) is accessible by untrusting clients. Typical home environments are safe if a firewall is utilized and port 22 is not forwarded to the ReadyNAS from the router. We do advise that all ReadyNAS users perform this add-on installation regardless.

Installation of the ToggleSSH add-on will disable remote SSH access and thus close the vulnerability. At the same time, if you need remote access assistance from NETGEAR Support, you can install the ToggleSSH add-on again to re-enable SSH access during the time when the remote access is needed.

In other words, NETGEAR support can remotely log into any ReadyNAS box as root and manage it. A few notes:

Oh, and what were they thinking having this on by default? Outstanding!

Posted by ekr at 9:45 PM | Comments (5)

August 5, 2007

More on gun-toting robots

While we're on the subject of armed robots, it's sort of worth asking the question of what sorts of inputs caused them to "spin out of control". Are these the kind of inputs that could potentially be presented by attackers? If so, I hope they were actually fixed, not just covered up with a kill switch.

Posted by ekr at 4:46 PM

Oh good, a kill switch

Wired reports that the DoD has taken delivery of three "special weapons observation remote reconnaissance direct action system" (SWORDS) robots. (Pretty tricky with those acronyms, guys!). Anyway, these are remote-controlled robots armed with M-249 machine guns.

Apparently these robots were uh, a bit flakey, but the manufacturers say they've got all the bugs worked out now:

The SWORDS -- modified versions of bomb-disposal robots used throughout Iraq -- were first declared ready for duty back in 2004. But concerns about safety kept the robots from being sent over the the battlefield. The machines had a tendency to spin out of control from time to time. That was an annoyance during ordnance-handling missions; no one wanted to contemplate the consequences during a firefight.

So the radio-controlled robots were retooled, for greater safety. In the past, weak signals would keep the robots from getting orders for as much as eight seconds -- a significant lag during combat. Now, the SWORDS won't act on a command, unless it's received right away. A three-part arming process -- with both physical and electronic safeties -- is required before firing. Most importantly, the machines now come with kill switches, in case there's any odd behavior. "So now we can kill the unit if it goes crazy," Zecca says.

OK, so ignoring the wisdom of starting from a platform which used to "spin out of control", I'm sort of interested in how the "kill switch" works. As far as I know, there are two basic ways to build a system like this:

It should be pretty clear that if what you think there's a high likelihood that the robot's going to go nuts and you want to minimize the chance that it kills your own people, random civilians, their pets, etc., you probably want something that fails safe. This is especially true in view of the implication in this article that signal strength isn't always what you might like. You really don't want to have a situation where the robot is busy slaughtering innocent bystanders and you can't shut it down because your control unit is showing zero bars.

On the other hand, a fail-safe system is also much easier to DoS—it's probably more important when the system being DoSed is shooting your enemies than when it's serving up copies of Girls Gone Wild. All the attacker has to do is somehow jam your signal (and remember that since you probably want to have a cryptographically secured control channel, they only need to introduce enough errors to make the integrity checks fail). This makes the problem of designing the control channel a lot more difficult. I'd definitely be interested in hearing more about the design of the protocol for these gizmos.

Posted by ekr at 10:32 AM | Comments (4)

August 3, 2007

What I did on my summer vacation

For the past couple months I've been spending most of my time working on California's Top-to-Bottom Review of electronic voting systems certified for use in California.

The overall project was performed under the auspices of UC and led by Matt Bishop (UC Davis) and David Wagner (UC Berkeley), who did a great job of negotiating a wide variety of organizational obstacles to get the project going and keep it on track.

This project reviewed the systems of three manufacturers:

Each company makes both an optical scanner for paper ballots and a computerized direct recording electronic (DRE) (these are often called touchscreen, but the Hart system actually uses a clickwheel), as well as a back-end election management system.

Each system was assigned to three teams:

There was also an accessibility team for all the systems.

I led the Hart source code team, consisting of me, Srinivas Inguva, Hovav Shacham, and Dan Wallach, and sited at an undisclosed location which can now be disclosed as SRI International in Menlo Park. Our report was just published yesterday, just ahead of the statutory deadline for the State to decide on whether these systems will continue to be certifed (more detail here). You can get it here and all the reports here.

I wasn't planning on saying much about this on EG. Most of what I have to say is already said better in our report. I did want to say a word about my team, who put in extraordinary amounts of effort under an extremely tight timeline; just over a month from the time we got the Hart source to the delivery of the final report. Thanks, guys, and I look forward to working with you again, hopefully next time in a room with 24x7 air conditioning.

Posted by ekr at 9:00 AM | Comments (1)

June 24, 2007

More on iPhone sandboxing

Nick Weaver suggests that the real "security" motivation for the sandboxing in the iPhone is to preserve the security of Apple (and Cingular's revenue stream):
The sandboxing depends on the objective...

Since the objective is to allow the cellphone company to keep charging discrimatory pricing based on traffic intent (EG, ~80 Mb/$ for bulk best-effort data, but .2 Mb/$ for SMS messages which can actually be worse-than-best-effort), the same origin sandboxing is the perfect policy.

After all, an IM client, at 80 Mb/$ would really hurt the income of the phone company when they could have you sending SMS instead.

Admittedly, this is a fairly plausible-sounding theory (though it's worth noting that AT&T does seem to offer an unlimited messaging plan), unifying, as it does, the sandboxing, and the various pieces of functionality (IM, Flash, turning MP3s into ringtones, etc.) that Apple seems to have decided to omit. But let's imagine for the moment that Apple isn't just trying to extract maximum revenue, but merely to make the iPhone work as well as possible. What sort of sandboxing would be most appropriate then?

In that case, you'd be mostly looking to ensure that 3rd-party apps (henceforth 3PA) interfere with the smooth functioning of the phone native apps (NAs). At minimum, you want 3PAs not to be able to crash the phone. Of course, this functionality is provided by pretty much any modern multiprocessing operating system, and is all you'd really need for most of the apps one the iPhone (Web browser, address book, maps, etc.) But for real-time apps (especially telephony), you probably want better guarantees. In particular, you want to avoid:

Note that in all of these cases you don't want to deny the 3PA access to the network, just to ensure that the NA gets priority when it needs it. This can be sort of a tricky engineering problem at times but is far from insoluble.

Posted by ekr at 8:40 PM | Comments (3)

June 20, 2007

A very sweet solution?

It appears that at least initially the iPhone will not have instant messaging, though SMS will "look like" instant messaging (cf. bacon juice vs. lemonade). Because the iPhone is semi-extendable, people are working to close this gap. Unfortunately, since all you can do is write Web apps, this has some limitations. The most important of which is, well, let him tell it:

Log in with your AOL IM account. No data is logged, but all of your information does pass through my server. I am not harvesting any information. This app is server intensive, so I'm limiting sessions to 10 minutes for now.

Obviously, having all my IMs go through somebody's server is pretty weak. Yeah, yeah, I know. I should be using crypto, and I already trust AOL, etc., but that doesn't mean I want to bring another person I have to trust into the loop. Unless I've missed something, this is a pretty inherent limitation of the design decision to only let you write Webapps and to sandbox them in the usual Webapp way. It works fine as long as your goals are limited, but as soon as you want to write something that (for instance) is a generic network client, you're hosed.

Here's Steve Jobs from WWDC:

And so you can write amazing Web 2.0 and AJAX apps that look and behave exactly like apps on the iPhone, and these apps can integrate perfectly with iPhone services. They can make a call, check email, look up a location on Gmaps... don't worry about distribution, just put 'em on an internet server. They're easy to update, just update it on your server. They're secure, and they run securely sandboxed on the iPhone. And guess what, there's no SDK you need! You've got everything you need if you can write modern web apps...

It's probably worth taking the time to unpack the sandboxing issue a bit. The sandboxing used in Java (and Javascript) has two major purposes: (1) to stop the applet from being a threat to your computer and (2) to stop the applet from being a threat to your network. So, when Java won't let an applet write to the disk, that's protecting your computer. When it won't let you connect to anyone other than the originating host (the same origin policy), that's to stop your computer being used to attack other computers on the network. The classic example of this is some applet which you download to your computer (behind the firewall) and then connects to hosts which would be firewalled off from a host on the public Internet.

But of course, if you want to write a real app (an IM or mail client, say), connecting to hosts other than the one you downloaded from is an absolute necessity—unless, that is, you think it's really cool that when you download Exchange you can only send mail to people at Microsoft. So, the idea with sandboxing is that there are a large (surprisingly large, actually) class of tasks that don't need quite so much functionality and that you can then connect to sites that do those tasks without having to think "should I give this program the right to write files onto my disk". But it should also be clear that this isn't the only class of tasks that people want their software to perform. which is why people want to be able to load applications on their computers, even if that whole code signing thing didn't work out as well as we hoped. It's just that you want to have to take positive action before allowing a more powerful app onto your computer (or phone). To the extent to which 3rd party iPhone apps are restricted to the Webapp sandbox, the device is only marginally extensible and that's not really that sweet.

Next: what sort of sandboxing makes sense for a device of this type?

Posted by ekr at 8:06 AM | Comments (3)

May 20, 2007

Steelcape and Firewall Traversing VPNs

A while back, I received a spam with the following contents:
Send data without opening your ports.

Steelcape has taken an innovative approach to security, instead of trying to repair TCP/IP, we have built a solution inside the TCP/IP protocol. This method allows Steelcape to secure environments without opening ports on the firewall.

The packets are encrypted at 256 bits and signed with a 48 bit digital signature. Also works with IPv6. Please take a look at our website www.steelcape.com

This rang in at about 10W40 on my snake-oil-ometer, but seeing as they'd been kind enough to give me their information, I figured I'd check it out and if it was snake oil, make fun of them publicly.

First, you can check out their Web site, which reiterates their basic claims:

This doesn't really tell you how the thing works, though. Points 2-4 are easily understood, but what does point 1 mean? Not opening any ports? It's not TCP/IP? How does the data get through? Figuring that out required reading their somewhat confusing WP (link omitted because you don't want to give them your name and email address any more than I do), an exchange of emails, and finally a con call with one of the sales/marketing guys and some technical guys.

Making sense of this requires some background on how Enterprise networks, firewalls, and VPNs work. Figure 1 shows the world's simplest firewalled Enterprise network.


Figure 1: A basic firewall configuration

You've got a bunch of hosts on an internal network separated from the Internet via a firewall, which also doubles as the Internet access router. The firewall prevents all connections to the internal hosts from the Internet. Defining what an internal connection is turns out to be a bit tricky, so, let's just talk about TCP here. Your classic firewall forbids incoming TCP connections but allows outgoing ones, at least to some ports. This works fine if you only want to have client machines, but if you want to have servers (e.g., a Web server), you need to do something else. To a first order, you can either punch a hole in your firewall or put the mail server outside your firewall. Actually, people often do both; they run two firewalls, with the web server in between them in what's called the DMZ. The outside firewall has a hole punched in it to allow access to the Web server, but because it's outside the inner firewall there's no need to punch a hole there. Figure 2 shows what I'm talking about.


Figure 2: Firewall with DMZ

This DMZ strategy of course works less well if you want to allow VPN access to your network, since the whole point of a VPN is to allow remote—albeit secured;access to the internal network. Either you make the firewall and VPN access router one and the same or you place the VPN access router inside the firewall, i.e.,


Figure 3: Firewall with VPN router

And, of course you need to have a hole in the firewall in order to let packets to/from the VPN router.

So, this gives us the background for understanding the "no holes in the firewall" claim. The first thing you need to understand is that this is a VPN-only solution: you can't use it to secure access to your public mail server or Web server. Those need to have open firewall ports. So, the idea is that you install Steelcape's stuff on both sides of the system, for instance as an appliance on your home network and then on the laptops of your remote users.

But I've just said that the VPN server needs to be able to talk directly to the Internet. So, how does Steelcape work? There WP says:

In TCP/IP, data is sent though ports, over a network, to a firewall or other network device, and sent on to listening hosts within a businesses infrastructure. This a potential point of exposure, since unwanted packets could end up on host systems. Steelcape leaves hostile data behind at the firewall as enabled by a "pull" architecture. Steelcape-enabled hosts pull packets from the firewall, validate them, and route them on to host systems. If Steelcape does not qualify the packets, they are kept at arm's length from the system and dropped at the firewall. This is accomplished without any sacrifice network bandwidth.

This description sounds initially coherent, but doesn't make sense in light of the claim (in e-mail) that it works with commodity firewalls, which don't have any such buffering or pull built into them. You can't really get this out of the WP, but it turns out that what's going on is that you have a topology like that shown in Figure 4.


Figure 4: Basic Steelcape installation

Whereas your classic VPN installation requires one box at each site, the Steelcape design requires two, one inside and one outside the firewall. The way that this works is that the gateway has a permanent connection tied up to the enterprise server (ES). This connection traverses the firewall. When a remote user wants to VPN in, he contacts the ES and authenticates. The ES sends a message to the gateway over this permanent signalling channel telling the ES that a client wants to come in and the client's IP address. The gateway then uses NAT/firewall hole-punching techniques (like ICE but the Steelcape guys say it's not ICE) to let the remote agent talk to the VPN server (it helps here that Steelcape pushes their traffic over UDP). If this strategy sounds familiar to you, it should. It's exactly the topology used by VoIP systems, with the SIP proxy taking the place of the ES.2 It should also now be clear why this can't work with generic Internet services: they're not set up to contact Steelcape's ES.

This approach has two claimed advantages: security and ease of installation (the other claimed advantages of Steelcape's stuff come from different techniques). In terms of security, it doesn't require that the VPN server be accessible from arbitrary Internet hosts all the time. Holes only get punched for hosts which have been authorized by the ES. Think of this as decreasing the surface area of attack. Of course, the flip side of this is that the ES does have to be accessible from any host. However, it's true that in order to attack the internal network you do need to compromise two hosts instead of one, so if implemented properly this could give you a measure of defense in depth. I'm not really confident it's that enormous, but all other things being equal (i.e., Steelcape's software being equally secure to other people's software), it probably does give you a measure of defense in depth.

In terms of ease of installation, it's certainly true that you should be able to install a Steelcape system without the cooperation of the firewall administrator. This is of course the kind of feature that users love and firewall administrators hate, because (from their perspective) it's far too often used to bypass enterprise security policies.1. Certainly, I would think that most enterprises would want any VPN appliances to have the approval of the firewall admin, so getting him to punch a hole hardly seems that onerous. And on the downside, of course, now you have two machines to maintain, which increases your maintenance effort.

The other major claim, increased performance, derives from Steelcape's use of a proprietary protocol which is allegedly faster than TCP. It was a little hard to work out what the optimizations were, but it sounded like principally it was that they didn't use compression and maybe that they had more aggressive congestion control3 It's certainly the case that you can get improved network performance via link-layer compression, so that sounds plausible, though hardly proprietary. That can of course be done within standard TCP/IP (see IPComp) so there's not likely to be anything proprietary there. And of course as soon as you are doing TCP/IP translation on Steelcape's boxes rather than TCP end-to-end there's lots of opportunity for things to go wrong. So, the "replaces TCP/IP" stuff looks mostly like marketing special sauce to me.

The other thing that probably should make you seriously nervous here is that Steelcape isn't using a standard security protocol (e.g., IPsec, SSL/TLS) but rather something they designed themselves. I didn't drill down on this too far, but apparently it uses Blowfish (a fine algorithm, but generally not a sign of crypto sophistication; the pros use AES) with (according to their product overview) a "48 bit digital signature") which is "randomized every few milliseconds". Since the security of a VPN system fundamentally depends on the crypto in use, using an unevaluated protocol isn't exactly confidence inspiring.

It should be obvious here that it's possible to design a standards-based system that uses the same firewall/NAT traversal techniques used by Steelcape. That would have some advantages and disadvantages vis-a-vis ordinary VPN approaches, plus you'd have a high level of confidence that the security protocol was secure. It doesn't look to me like that's what Steelcape is providing, however.

1. See also draft-saito-mmusic-sdp-ike-00 for a very similar standards-based approach.
2. It's interesting to note that in this case there's no requirement that the ES actually be in the DMZ. It could be some entirely different third party server on the network—after all, this is how SIP works—which puts a somewhat different spin on the above security argument.
3. They also told me that they eliminate the TCP checksum computation so that this sped up intermediate routers. As far as I know, checksum computatations are not a significant part of packet processing overhead.

UPDATE: Ed Felten hypothesizes that the 48-bit "digital signature" is actually a MAC. Another possibility is that it's not data dependent at all; it's just a secret value that gets appended to the packet. That would be consistent with the "randomized every few milliseconds" claim, since a MAC would be different for every packet. Needless to say, if that's what it is, it's not adequate.

Posted by ekr at 8:37 AM | Comments (2)

May 6, 2007

AOL and 8-character passwords

Washington Post's Security blog claims that AOL only verifies the first eight characters of the password:
A reader wrote in Friday with an interesting observation: When he went to access his AOL.com account, he accidentally entered an extra character at the end of his password. But that didn't stop him from entering his account. Curious, the reader tried adding multiple alphanumeric sequences after his password, and each time it logged him in successfully.

It turns out that when someone signs up for an AOL.com account, the user appears to be allowed to enter up to a 16-character password. AOL's system, however, doesn't read past the first eight characters.

How is this a bad set-up, security-wise? Well, let's take a fictional AOL user named Bob Jones, who signs up with AOL using the user name BobJones. Bob -- thinking himself very clever -- sets his password to be BobJones$4e?0. Now, if Bob's co-worker Alice or arch nemesis Charlie tries to guess his password, probably the first password he or she will try is Bob's user name, since people are lazy and often use their user name as their password.

I don't use AOL, so I have no idea if this is true or not, but if it is, it's pretty clearly bad. As suggested above, it's actually worse than just allowing 8 character passwords. In order to resist password search it's important to have a high entropy password, but the shorter the password the more random-looking the password has to be, and of course users have trouble remembering random-looking strings, which is why people are often encouraged to use passphrases because they're easier to remember. But of course each bit of the passphrase typically has fairly low entropy. So, if users think they can use long passwords and actually can't the situation is worse than if they just were told to use short passwords.

That said, when people talk about the need for high entropy passwords, the attack they're usually concerned with is dictionary attacks on the encrypted password file. If some attacker can get their hands on AOL's password file then there are much bigger problems than this. So, the relevant attack is one where people's passwords are really easy to guess (like their username). It's not clear that people who use passwords that bad are going to use passwords longer than 8 characters.

Posted by ekr at 9:25 PM | Comments (1)

March 14, 2007

Back doors and Open Source

As you may have heard, someone recently inserted a back door into WordPress 2.1.1. What appears to have happened is that the attacker broke into WordPress's servers and modified the distribution:
Longer explanation: This morning we received a note to our security mailing address about unusual and highly exploitable code in WordPress. The issue was investigated, and it appeared that the 2.1.1 download had been modified from its original code. We took the website down immediately to investigate what happened.

It was determined that a cracker had gained user-level access to one of the servers that powers wordpress.org, and had used that access to modify the download file. We have locked down that server for further forensics, but at this time it appears that the 2.1.1 download was the only thing touched by the attack. They modified two files in WP to include code that would allow for remote PHP execution.

What's interesting about this incident is how it was detected. In many such incidents, what's detected is that there is something funny on the systems hosting the code (e.g., the CVS repository in the 2003 Linux kernel backdoor attempt. The relevant change then gets tracked down and studied very carefully. According to the WordPress people, however, what happened here was that someone detected the vulnerability and then they tracked it to an intrusion.

This is interesting because there are two major ways for someone to insert a back door into some piece of open source software:

The first is easier to do because most systems aren't very well secured and so all you need to do is break in and replace the distribution. However, it's also a lot easier to detect. First, breaking in often leaves signs. Second, the source code typically exists in multiple copies and so eventually the inconsistency gets noticed, especially because it's typically the download servers that are easiest to attack but they can be compared with the main source repository.

The second is harder to do but can be much more effective. You just submit a fair-sized patch to the project that happens to contain a security vulnerability. Most patches don't undergo particularly thorough review, especially on non-security projects, and it's quite easy to hide a buffer overflow or other vulnerability in your code once you get above a hundred lines or so. This is a little more work since you actually have to implement a semi-useful feature, but the bar for that is pretty low on most projects as well. I don't think I've ever heard of a backdoor being inserted this way. It's hard to know if that reflects that nobody does this or just that nobody catches it.

Posted by ekr at 8:11 AM | Comments (2)

February 20, 2007

A parking virus

I was in SFO short-term parking today and as I pulled up to get my ticket, I saw something interesting:

Regrettably I bungled my cell phone camera and was unable to get a photo.

Obviously, I'm unsurprised that these machines run Windows (though I wouldn't have been surprised with Linux or QNX). I'm a little surprised that they're networked since a lot of this kind of industrial automation tech was manufactured and installed before ubiquitous local networking command and control. However, given that they are running Windows and are networked, we shouldn't be surprised if they get infected. I guess the next question is: what could you do with a zombied parking ticket machine?

Posted by ekr at 10:53 PM | Comments (3)

February 15, 2007

You're a script kiddie, not an information warrior

Mordaxus argues that we should stop using cutesy names for attacks on information systems:
This is the term that has set me off on the present rant. The person who just used it in a meeting I'm in said "pharming" and then screwed up his face when he perceived a blank look or three and said, "Well, pharming is a name for a number of attacks, which are all DNS spoofing attacks." I bit my tongue and did not say, "Then why didn't you say 'DNS attacks'?" and then sat down to this rant.

Pharming has both of the faults Orwell mentions. It's stale (being a back-formation from phishing) and imprecise. It's so imprecise that one can't imagine what it is just from the name. I could complain about phishing itself, but it is at least poetic and suggestive of the actual criminal activity, and that particular spelling appeared as early as 1996 in an AOL password-stealing scam. However, the word forgery was created for this very case.

I'm not fond of "phishing" or "pharming", but the ones that bug me are wardialing and friends. Wardialing is using an automatic dialer to scan for open modems. According to Wikipedia, the name comes from the use of the technique in the movie Wargames, so while it's a stupid name at least you can see where it came from. Then we got "wardriving", driving around looking for an open wireless access point, which is bad enough, but then (and I'm not making this up), warchalking, marking the area where there's an open AP. Is there any human who can the say the word "warchalking" unironically and not feel like a complete fool? And that's not all. There's also warbiking, warwalking, and warspying. I'd write more but it's late and time for me to do some warsleeping.

Posted by ekr at 11:10 PM | Comments (2)

February 3, 2007

Julie Amero, malware, etc.

Julie Amero, a substitute teacher in Norwich CT, has been convicted of "four counts of risk of injury to a minor, or impairing the morals of a child" and faces up to 40 years in prison. The facts of the case seem to be this (this post has a bunch of useful links):

So, let's take a step back here. It seems to me that this set of facts is consistent with three theories from most to least innocuous.

Her machine was (innocuously) infected with malware and she froze.
This certainly is possible. It's certainly not hard to get your machine infected with malware and pornographic websites do try to trap you with popups so that you can't leave. Turning off your computer of course solves the problem, but it's easy to imagine someone computer illiterate, especially as Amero was reportedly told not to turn off her computer. Clearly, in retrospect this would have been pretty stupid, but then people in shock sometimes freeze.

The prosecution's argument against this theory appears to be that links to inappropriate websites were highlighted by the browser, presumably indicating that she had visited them. This could of course be a result of her doing so intentionally, but as far as I know browsers record visits, not mouse clicks, so if you really were infected with malware intended to redirect you to this kind of site it could create this kind of trail. There's also the possibility that someone else was using the computer and went to such sites.

She was visiting inappropriate web sites, got stuck in a popup loop, and then froze.
If you believe the previous theory, then certainly you ought to believe this one. It's possible to get infected during ordinary web sites, but it's even easier to get infected visiting porn sites which aren't notoriously safe. And when confronted with the frankly embarassing evidence of your malfeasance you would probably want to hide it by shutting off the computer, but again it's not crazy to believe that she would freeze.

She deliberately displayed porn to her class.
In this theory either her computer started to display porn for one of the previous two reasons and she decided to let it play it for her class or she intentionally put the computer in a state where it played porn for them. Obviously this is possible at some technical level, but it seems pretty implausible to me. Certainly teachers occasionally do inappropriate things (telling your students that if they don't accept Jesus they'll go to hell, for instance) but it's hard to understand what Amero's motivation for showing porn to her students in public would be. Even if we assume that for some unfathomable reason she wanted to "corrupt" them wouldn't it be smarter to do it in some setting where she was less likely to get caught, fired, and prosecuted? Absent some explanation (for instance that she's completely crazy) this strikes me as a fairly implausible explanation.

So, at the end of the day it seems to me that we have two plausible explanations: a completely innocent woman froze or someone who had been misusing school computers in a way that people misuse their employer's computers (I'm not making a moral judgement here, but most employers do prohibit use of their computers and network for viewing porn so this is technically misuse) every day got caught. In either case, it's pretty hard to see how this merits a 40 year prison sentence. I don't know of any evidence that this caused any of the children any long term harm, but even if it did, consider that in CT if you got in your car drunk and killed somebody, the sentence would be more like 10 years.

Posted by ekr at 9:37 PM

January 27, 2007

Some additional thoughts on attacking AACS

Ed Felten and Alex Haldeman have a nice series of posts about AACS, the content control system on HD-DVD and Blu-Ray. You should really go read the posts, but here's what you need to know (somewhat simplified)

Given the title key, BackupHDDVD can decrypt the content of a disk. If you can compromise a single player and recover its key, you can use that to recover title keys which, of course you can use to decrypt disks.

Where this all went wrong with CSS was there were only a small number of keys, so once you compromised one player and published the key the game was pretty much over. But with AACS each player has a unique set of keys and the AACS includes a scheme for revoking compromised players. When a player is revoked you stop encrypting disks under its key, so it's useless for all future disks, but all disks printed before that time are (at least potentially) compromised. So, if you compromise a player and publish its key, it has a finite window of usefulness.

However, if software players are widely available, the situation is different. There's a large population of keys already available to people and all the attacker needs to do is release a piece of software which extracts the player keys from a player or patches an authorized player to either disclose title keys or the unencrypted data on a disk (as Felten observes), WinDVD already more or less is such a player, but that's presumably a somewhat temporary situation). There are of course techniques you can use to make it harder to hack software, but as far as I can tell none of them stand up to dedicated attack.

It's of course possible for the manufacturers to revoke all the players by a particular manufacturer and force them to download a new player with better tamperproofing. This has two drawbacks. First, the cost is much higher than just revoking the compromised unit because you're not just inconveniencing the attacker but everyone who happens to have a vulnerable player and most of those people are totally innocent. Second, because it's comparatively easy to break the tamperproofing the attacker can force you to incur this cost more or less whenever he wants.

It's hard to see how the studios can really solve this problem as long as purely software players are allowed.

Posted by ekr at 8:55 PM | Comments (12)

January 20, 2007

iPhone and lockin

OK, I have to admit that the Not Yet Released Device Potentially To Be Known As The iPhone (NYRDPTBKATi) looks pretty sweet, but the level of lockin significantly detracts from the overall coolness. There are actually two issues here, one bogus and one real.

DRM
The bogus one, raised by Randall Stross in the Times is the FairPlay DRM:

Here is how FairPlay works: When you buy songs at the iTunes Music Store, you can play them on one and only one line of portable player, the iPod. And when you buy an iPod, you can play copy-protected songs bought from one and only one online music store, the iTunes Music Store.

The only legal way around this built-in limitation is to strip out the copy protection by burning a CD with the tracks, then uploading the music back to the computer. If youre willing to go to that trouble, you can play the music where and how you choose the equivalent to rights that would have been granted automatically at the cash register if you had bought the same music on a CD in the first place.

This is, of course true, but sort of irrelevant. First, you're quite free to buy physical CDs and rip them yourself. iTunes will even rip them for you. At least with the iPod and presumably with the NYRDPTBKATi, there won't be any copy protection on them at all. It's true that the iPod file format obfuscates the locations of the files on the disk, but they're all there and you can get 3rd party programs which know how to read the format. The vast majority of music gets into iPods by being ripped, not downloaded.

Second, the issue isn't the iPod or NYRDPTBKATi, but rather iTMS, which imposes the DRM on the way out the door. Stross says this in the article but some misses the implication:

This claim requires willful blindness to the presence of online music stores that eschew copy protection. For example, one online store, eMusic, offers two million tracks from independent labels that represent about 30 percent of worldwide music sales.

Unlike the four major labels Universal, Warner Music Group, EMI and Sony BMG the independents provide eMusic with permission to distribute the music in plain MP3 format. There is no copy protection, no customer lock-in, no restrictions on what kind of music player or media center a customer chooses to use the MP3 standard is accommodated by all players.

In other words, it's quite possible to play non-DRMed files (what else is a podcast, after all?), it's just that (1) the music users want isn't available (2) the users don't know where to get it or (3) the UIs for getting it are too annoying. if it's really true that the major labels are willing to go non-DRM than this sounds like a great marketing opportunity for someone to make a really good non-DRM online music store. In any case, Stross's quarrel isn't with the iPod but with iTMS.

Programmability
This brings us to the real issue: programmability. According to this article the NYRDPTBKATi isn't going to be an open platform. I.e., you won't be able to load your own applications onto it. Apple has advanced two major arguments for why this is OK: protecting the network from rogue applications and protecting the stability of the device.

Here's Jobs advancing the first reason:

But its not like the walled garden has gone away. You dont want your phone to be an open platform, meaning that anyone can write applications for it and potentially gum up the provider's network, says Jobs. You need it to work when you need it to work. Cingular doesnt want to see their West Coast network go down because some application messed up.

Look, this is mostly nonsense. Yes, it's true that programmable computers can do damage to the Internet (cf. zombies, spam, DDoS, etc.) but this isn't primarily an issue of people installing the wrong third party software but rather of their machine being remotely compromised via vulnerabilities in the existing software—primarily stuff installed by the OS manufacturer. I should mention that Apple isn't giving out SDKs for the iPhone, so it's going to be harder for malware authors to program to it than (say) Windows, but that's only a temporary obstacle if it becomes an attractive attack target. There are of course ways to stop third-party malware from being loaded on at all (e.g., signed code) but the level of defense that Apple employs on the iPod doesn't suggest that they're too likely to have done anything like that here. I'd imagine they're just hiding the specs and the SDK and maybe churning the API/ABI occasionally to make it more inconvenient to write a real product.

More importantly, the danger in rogue applications isn't primarily to the access network but rather to machines other places on the Internet. It's actually very easy for Cingular to detect when a device is doing something dangerous to their network and shut it down. And to the extent to which it's not easy, Cingular has much bigger problems since they're already quite willing to sell you Windows Mobile and Palm smartphnes, which are programmable.

The second argument Apple is advancing is that letting end-users run arbitrary third-party apps will potentially destabilize the handset, contributing to a bad user experience.

We define everything that is on the phone, he said. You dont want your phone to be like a PC. The last thing you want is to have loaded three apps on your phone and then you go to make a call and it doesnt work anymore. These are more like iPods than they are like computers.

The iPhone, he insisted, would not look like the rest of the wireless industry.

These are devices that need to work, and you cant do that if you load any software on them, he said. That doesnt mean theres not going to be software to buy that you can load on them coming from us. It doesnt mean we have to write it all, but it means it has to be more of a controlled environment.

So, this is vaguely more reasonable, especially considering Apple's well-known fetish for the providing the optimal UI experience. Still, it's not particularly convincing. I've loaded several 3rd party apps on my Treo and haven't noticed it destabilizing the phone functionality. A modern O/S like OSX should be quite capable of protecting applications from each other—that kind of process isolation is one of the major functions of the OS. I haven't noticed any of the 3rd-party apps I run on my OS/X boxes being a source of massive instability.

Does it matter?
I'm probably unusual in that I'd actually like to be able to do some development on a handheld device, which would obviously be a problem if there's no SDK. That would be a big motivator for getting something based on a real operating system rather than PalmOS. But even ordinary users may find this kind of lockin inconvenient. I don't know what applications Apple intends to provide on the NYRDPTBKATi, and the truth is that they provide a pretty reasonable set on your Mac, but even so I've installed Firefox, MS Office, the Palm software suite, and Windows Media Player. Apple offers their own versions of some of this stuff and it will be interesting to see if they decide you should have to run Safari instead of Firefox or Keynote instead of PowerPoint. One of the nice things about having a general purpose computer is that you get to make these decisions for yourself rather than having Steve Jobsa make them for you.

Posted by ekr at 10:39 AM | Comments (6)

January 12, 2007

You don't mind that my mail goes to Gmail, right?

The NYT reports that a lot of users forward their corporate e-mail to external Webmail accounts:
A growing number of Internet-literate workers are forwarding their office e-mail to free Web-accessible personal accounts offered by Google, Yahoo and other companies. Their employers, who envision corporate secrets leaking through the back door of otherwise well-protected computer networks, are not pleased.

...

Corporate networks, which typically have several layers of defenses against hackers, can require special software and multiple passwords for access. Some companies use systems that give employees a security code that changes every 60 seconds; this must be read from the display screen of a small card and typed quickly.

That is too much for some employees, especially when their computers can store the passwords for their Web-based mail, allowing them to get right down to business.

I'm sure annoying authentication schemes are part of the problem—though most of the organizations I know about only require you to use your SecureID card to make a VPN connection. Not that that's not annoying enough...

In my experience, the problem isn't security but rather usability. Probably the most important factor is remote access. People want to read their e-mail on their Blackberries and the companies often haven't been that good about installing the connecting software that the employees would need to do that. So, the employees install their own connectors on their desktop. Actually, remote access in general is a problem. Webmail is super-convenient and lots of companies don't or won't offer it. But you can help yourself by just forwarding your e-mail to Gmail.

Finally, there's the usability issue. Many enterprises run Exchange and expect their employees to use the matching MS e-mail clients. The reports I've heard from people who've tried are not exactly encouraging. On the other hand, Gmail's interface is actually pretty good, and you can also use Gmail with more or less any e-mail client of your choice.

Lawyers in particular wring their hands over employees using outside e-mail services. They encourage companies to keep messages for as long as necessary and then erase them to keep them out of the reach of legal foes. Companies have no control over the life span of e-mail messages in employees Web accounts.
This is absolutely a real concern, but it's a mistake to focus on e-mail here. It's actually incredibly difficult to avoid creating archival copies of sensitive information. First, many (most?) e-mail systems make copies to the local disk to enable offline work. At this point, it tends to end up in scheduled backups. Even if you manage to suppress this by forcing everyone to work offline or implementing local expire, employees routinely save data to disk and then it gets backed up onto permanent backups. Creating access control and retention policies that stick with the data through this kind of transformation is nigh-impossible with any operating system in common use (there's a close relationship between this problem and multi-level security, by the way). And this is if you control the systems people use. It's of course massively harder when you don't.1

"If employees are just forwarding to their Web e-mail, we have no way to know what they are doing on the other end," said Joe Fantuzzi, chief executive of the information security firm Workshare. "They could do anything they want. They could be giving secrets to the K.G.B."
OK, but this doesn't make any sense. First, if your employees want to give your secrets to the KGB , what they need isn't e-mail, it's a time machine. Second, if they want to give out your secrets, they're not going to forward them to Gmail, they'll bring a flash drive to work and copy all their data onto it. It makes some sense to be concerned about inadvertant information disclosure by employees, but once you assume that you're in an adversarial relationship then you've pretty much lost.

Paul Kocher, president of the security firm Cryptography Research, said the real issue for companies was trust. "If you can't trust employees enough to use services like Gmail, they probably shouldn't be working for you," he said.

I certainly agree that if you can't trust your employees not to intentionally give out your confidential information you're in big trouble, but I don't think it's right to extend this to whether you can trust them to comply with all your corporate IT policies. Just from reading this article (and from my personal experience) it's clear that if you followed that policy you'd have to fire a lot of your employees, including good ones—people who are at least to some extent trying to act in the best interests of the company by working more efficiently.

At a higher level, the relationship between corporate IT departments and individual users is often quite adversarial. The IT departments want to standardize everyone on a particular set of software and services and the users want to use software and services of their choice. When the official IT offerings become too restrictive (in the minds of the users) they often resort to self-help, as in this case.

1. There was some interest for a while in using various kinds of cryptographic techniques for this, but it never really took off and was still hard to get right.

Posted by ekr at 9:21 AM | Comments (2)