Errata Security

A quick review of the BIND9 code

noreply@blogger.com (Robert Graham) — Thu, 30 Jul 2015 11:29:00 +0000

BIND9 is the oldest and most popular DNS server. Today, they announced a DoS vulnerability was announced that would crash the server with a simply crafted query. I could use my "masscan" tool to blanket the Internet with those packets and crash all publicly facing BIND9 DNS servers in about an hour. A single vuln doesn't mean much, but if you look at the recent BIND9 vulns, you see a pattern forming. BIND9 has lots of problems -- problems that critical infrastructure software should not have.

Its biggest problem is that it has too many feature. It attempts to implement every possible DNS feature known to man, few of which are needed on publicly facing servers. Today's bug was in the rarely used "TKEY" feature, for example. DNS servers exposed to the public should have the minimum number of features -- the server priding itself on having the maximum number of features is automatically disqualified.

Another problem is that DNS itself has some outdated design issues. The control-plane and data-plane need to be separate. This bug is in the control-plane code, but it's exploited from the data-plane. (Data-plane is queries from the Internet looking up names, control-plane is zones updates, key distribution, and configuration). The control-plane should be on a separate network adapter, separate network address, and separate port numbers. These should be hidden from the public, and protected by a firewall.

DNS should have hidden masters, servers with lots of rich functionality, such as automatic DNSSEC zone signing. It should have lightweight exposed slaves, with just enough code to answer queries on the data-plane, and keep synchronized with the master on the control-plane.

But what this post is really about is looking at BIND9's code. It's a nicer than the OpenSSL code and some other open-source projects, but there do appear to be some issues. The bug was in the "dns_message_findname()" function. The function header looks like:

isc_result_t

dns_message_findname(dns_message_t *msg, dns_section_t section,

dns_name_t *target, dns_rdatatype_t type,

dns_rdatatype_t covers, dns_name_t **name,

dns_rdataset_t **rdataset);

The thing you should notice here is that none of the variables are prefixed with const, even though all but one of them should be. A quick grep shows that lack of const correctness is pretty common throughout the BIND9 source code. Every quality guide in the world strongly suggests const correctness -- that's it's lacking here hints at larger problems.

The bug was an assertion failure on the "name" parameter in the code above, as you can see in the picture. An assertion is supposed to double-check internal consistency of data, to catch bugs early. But this case, there was no bug being caught -- it was the assertion itself that was the problem. The programmers are confused by the difference between in, out, and in/out parameters. You assert on the expected values of the in and in/out parameters, but not on write-only out parameters. Since the function doesn't read them, their value is immaterial. If the function wants it to be NULL on input, it can just set it itself -- demanding that the caller do this is just bad.

By the way, assertions are normally enabled only for testing, but not for production code. That's because they can introduce bugs (as in this case), and have performance problems. However, in the long run, aggressive double-checking leads to more reliable code. Thus, I'm a fan of such aggressive checking. However, quickly glancing at the recent BIND9 vulns, it appears many of them are caused by assertions failing. This may be good, meaning that the code was going to crash (or get exploited) anyway, and the assertion caught it early. Or, it may be bad, with the assertion being the bug itself, or at least, that the user would've been happier without the assertion triggering (because of a memory leak, for example). If the later is the case, then it sounds like people should just turn off the assertions when building BIND9 (it's a single command-line switch).

Last year, ISC (the organization that maintains BIND9) finished up their BIND10 project, which was to be a re-write of the code. This was a fiasco, of course. Rewrites of large software project are doomed to failure. The only path forward for BIND is with the current code-base. This means refactoring and cleaning up technical debt on a regular basis, such as fixing the const correctness problem. This means arbitrarily deciding to drop support for 1990s era computers when necessary. If the architecture needs to change (such as separating the data-plane from the control-plane), it can be done within the current code-base -- just create a solid regression test, then go wild on the changes relying upon the regression test to maintain the quality.

Lastly, I want to comment on the speed of BIND9. It's dog slow -- the slowest of all the DNS servers. That's a problem firstly because slow servers should not be exposed to DDoS attacks on the Internet. It's a problem secondly because slow servers should not be written in dangerous languages like C/C++ . These languages should only be used when speed is critical. If your code isn't fast anyway, then you should be using safe languages, like C#, Java, or JavaScript. A DNS server written in these languages is unlikely to be any slower than BIND9.

Conclusion

The point I'm trying to make here is that BIND9 should not be exposed to the public. It has code problems that should be unacceptable in this day and age of cybersecurity. Even if it were written perfectly, it has far too many features to be trustworthy. It's feature-richness makes it a great hidden master, it's just all those feature get in the way of it being a simple authoritative slave server, or a simple resolver. They shouldn't rewrite it from scratch, but if they did, they should choose a safe language and not use C/C++.

Example#2: strcpy()

BIND9 has 245 instances of the horribly unsafe strcpy() function, spread through 94 files. This is unacceptable -- yet another technical debt they need to fix. It needs to be replaced with the strcpy_s() function.

In the file lwresutil.c is an example of flawed thinking around strcpy(). It's not an exploitable bug, at least not yet, but it's still flawed.

lwres_getaddrsbyname(...)

{ unsigned int target_length;

target_length = strlen(name);
if (target_length >= sizeof(target_name))
return (LWRES_R_FAILURE);
strcpy(target_name, name); /* strcpy is safe */

}

The problem here, which I highlighted in bold. The problem is that on a 64-bit machine, an unsigned int is only 32-bits, but string lengths can be longer than a 32-bit value can hold. Thus, a 4-billion byte name would cause the integer to overflow and the length check to fail. I don't think you can get any name longer than 256 bytes through this code path, so it's likely not vulnerable now, but the "4-billion bytes of data" problem is pretty common in other code, and frequently exploitable in practice.

The comment /* strcpy is safe */ is no more accurate than those emails that claim "Checked by anti-virus".

Modern code should never use strcpy(), at all, under any circumstances, not even in the unit-test code where it doesn't matter. It's easy to manage projects by simply grepping for the string "strcpy()" and whether it exists or not, it's hard managing project with some strcpy()s. It's like being some pregnant.

Infosec's inability to quantify risk

noreply@blogger.com (Robert Graham) — Wed, 22 Jul 2015 17:18:00 +0000

Infosec isn't a real profession. Among the things missing is proper "risk analysis". Instead of quantifying risk, we treat it as an absolute. Risk is binary, either there is risk or there isn't. We respond to risk emotionally rather than rationally, claiming all risk needs to be removed. This is why nobody listens to us. Business leaders quantify and prioritize risk, but we don't, so our useless advice is ignored.

An example of this is the car hacking stunt by Charlie Miller and Chris Valasek, where they turned off the engine at freeway speeds. This has lead to an outcry of criticism in our community from people who haven't quantified the risk. Any rational measure of the risk of that stunt is that it's pretty small -- while the benefits are very large.

In college, I owned a poorly maintained VW bug that would occasionally lose power on the freeway, such as from an electrical connection falling off from vibration. I caused more risk by not maintaining my car than these security researchers did.

Indeed, cars losing power on the freeway is a rather common occurrence. We often see cars on the side of the road. Few accidents are caused by such cars. Sure, they add risk, but so do people abruptly changing lanes.

No human is a perfect driver. Every time we get into our cars, instead of cycling or taking public transportation, we add risk to those around us. The majority of those criticizing this hacking stunt have caused more risk to other drivers this last year by commuting to work. They cause this risk not for some high ideal of improving infosec, but merely for personal convenience. Infosec is legendary for it's hypocrisy, this is just one more example.

Google, Tesla, and other companies are creating "self driving cars". Self-driving cars will always struggle to cope with unpredictable human drivers, and will occasionally cause accidents. However, in the long run, self-driving cars will be vastly safer. To reach that point, we need to quantify risk. We need to be able to show that for every life lost due to self-driving cars, two have been saved because they are inherently safer. But here's the thing, if we use the immature risk analysis from the infosec "profession", we'll always point to the one life lost, and never quantify the two lives saved. Using infosec risk analysis, safer self-driving cars will never happen.

In hindsight, it's obvious to everyone that Valasek and Miller went too far. Renting a track for a few hours costs less than the plane ticket for the journalist to come out and visit them. Infosec is like a pride of lions, that'll leap and devour one of their members when they show a sign of weakness. This minor mistake is weakness, so many in infosec have jumped on the pair, reveling in righteous rage. But any rational quantification of the risks show that the mistake is minor, compared to the huge benefit of their research. I, for one, praise these two, and hope they continue their research -- knowing full well that they'll likely continue to make other sorts of minor mistakes in the future.

My BIS/Wassenaar comment

noreply@blogger.com (Robert Graham) — Tue, 21 Jul 2015 00:47:00 +0000

This is my comment I submitted to the BIS on their Wassenaar rules:

----
Hi.

I created the first “intrusion prevention system”, as well as many tools and much cybersecurity research over the last 20 years. I would not have done so had these rules been in place. The cost and dangers would have been too high. If you do not roll back the existing language, I will be forced to do something else.

After two months, reading your FAQ, consulting with lawyers and export experts, the cybersecurity industry still hasn’t figured out precisely what your rules mean. The language is so open-ended that it appears to control everything. My latest project is a simple “DNS server”, a piece of software wholly unrelated to cybersecurity. Yet, since hackers exploit “DNS” for malware command-and-control, it appears to be covered by your rules. It’s specifically designed for both the distribution and control of malware. This isn’t my intent, it’s just a consequence of how “DNS” works. I haven’t decided whether to make this tool open-source yet, so therefore traveling to foreign countries with the code on my laptop appears to be a felony violation of export controls.

Of course you don’t intend to criminalize this behavior, but that isn’t the point. The point is that the rules are so vague that they become impossible for anybody to know exactly what is prohibited. We therefore have to take the conservative approach. As we’ve seen with other vague laws, such as the CFAA, enforcement is arbitrary and discriminatory. None of us would have believed that downloading files published on a public website would be illegal until a member of community was convicted under the CFAA for doing it. None of us wants to be a similar test case for export controls. The current BIS rules are so open-ended that they would have a powerful chilling effect on our industry.

The solution, though, isn’t to clarify the rules, but to roll them back. You can’t clarify the difference between good/bad software because there is no difference between offensive and defensive tools -- just the people who use them. The best way to secure your network is to attack it yourself. For example, my “masscan” tool quickly scans large networks for vulnerabilities like “Heartbleed”. Defenders use it to quickly find vulnerable systems, to patch them. But hackers also use my tool to find vulnerable systems to hack them. There is no solution that stops bad governments from buying “intrusion” or “surveillance” software that doesn’t also stop their victims from buying software to protect themselves. Export controls on offensive software means export controls on defensive software. Export controls mean the Sudanese and Ethiopian people can no longer defend themselves from their own governments.

Wassenaar was intended to stop “proliferation” and “destabilization”, yet intrusion/surveillance software is neither of those. Human rights activists have hijacked the arrangement for their own purposes. This is a good purpose, of course, since these regimes are evil. It’s just that Wassenaar is the wrong way to do this, with a disproportionate impact on legitimate industry, while at the same time, hurting the very people it’s designed to help. Likewise, your own interpretation of Wassenaar seems to have been hijacked by the intelligence community in the United States for their own purposes to control “0days”.

Rather than the current open-end and vague interpretation of the Wassenaar changes, you must do the opposite, and create the narrowest of interpretations. Better yet, you need to go back and renegotiate the rules with the other Wassenaar members, as software is not a legitimate target of Wassenaar control. Computer code is not a weapon, if you make it one, then you’ll destroy America’s standing in the world. On a personal note, if you don’t drastically narrow this, my research and development will change. Either I will stay in this country and do something else, or I will move out of this country (despite being a fervent patriot).

Robert Graham
Creator of BlackICE, sidejacking, and masscan.
Frequent speaker at cybersecurity conferences.

Software and the bogeyman

noreply@blogger.com (Robert Graham) — Wed, 15 Jul 2015 19:30:00 +0000

This post about the July 8 glitches (United, NYSE, WSJ failed) keeps popping up in my Twitter timeline. It's complete nonsense.

What's being argued here is that these glitches were due to some sort of "moral weakness", like laziness, politics, or stupidity. It's a facile and appealing argument, so scoundrels make it often -- to great applause from the audience. But it's not true.

Legacy

Layers and legacies exist because working systems are precious. More than half of big software projects are abandoned, because getting new things to work is a hard task. We place so much value on legacy, working old systems, because the new replacements usually fail.

An example of this is the failed BIND10 project. BIND, the Berkeley Internet Name Daemon, is the oldest and most popular DNS server. It is the de facto reference standard for how DNS works, more so than the actual RFCs. Version 9 of the project is 15 years old. Therefore, the consortium that maintains it funded development for version 10. They completed the project, then effectively abandoned it, as it was worse in almost every way than the previous version.

The reason legacy works well is the enormous regression testing that goes on. In robust projects, every time there is a bug, engineers create one or more tests to exercise the bug, then add that to the automated testing, so that from now on, that bug (or something similar) can never happen again. You can look at a project like BIND9 and point to the thousands of bugs it's had over the last decade. So many bugs might make you think it's bad, but the opposite is true: it means that it's got an enormous regression test system that stresses the system in peculiar ways. A new replacement will have just as many bugs -- but no robust test that will find them.

A regression test is often more important than the actual code. If you want to build a replacement project, start with the old regression test. If you are a software company and want to steal your competitors intellectual property, ignore their source, steal their regression test instead.

People look at the problems of legacy and believe that we'd be better off without it, if only we had the will (the moral strength) to do the right thing and replace old system. That's rarely true. Legacy is what's reliable and working -- it's new stuff that ultimately is untrustworthy and likely to break. You should worship legacy, not fear it.

Technical debt

Almost all uses of the phrase "technical debt" call it a bad thing. The opposite is true. The word was coined to refer to a good thing.

The analogy is financial debt. That, too, is used incorrectly as a pejorative. People focus on the negatives, the tiny percentage of bankruptcies. They don't focus on the positives, what that debt finances, like factories, roads, education, and so on. Our economic system is "capitalism", where "capital" just means "debt". The dollar bills in your wallet are a form of debt. When you contribute to society, they are indebted to you, so give you a marker, which you can then redeem by giving back to society in exchange something that you want, like a beer at your local bar.

The same is true of technical debt. It's a good thing, a necessary thing. The reason we talk about technical debt isn't so that we can get rid of it, but so that we can keep track of it and exploit it.

The Medium story claims:

A lot of new code is written very very fast, because that’s what the intersection of the current wave of software development (and the angel investor / venture capital model of funding) in Silicon Valley compels people to do.

This is nonsense. Every software project of every type has technical debt. Indeed, it's open-source that overwhelmingly has the most technical debt. Most open-source software starts as somebody wanting to solve a small problem now. If people like the project, then it survives, and more code and features are added. If people don't like it, the project disappears. By sheer evolution, that which survives has technical debt. Sure, some projects are better than others at going back and cleaning up their debt, but it's something intrinsic to all software engineering.

Figuring out what user's want is 90% of the problem, how the code works is only 10%. Most software fails because nobody wants to use it. Focusing on removing technical debt, investing many times more effort in creating the code, just magnifies the cost of failure when your code still doesn't do what users want. The overwhelmingly correct development methodology is to incur lots of technical debt at the start of every project.

Technical debt isn't about bugs. People like to equate the two, as both are seen as symptoms of moral weakness. Instead, technical debt is about the fact that fixing bugs (or adding features) is more expensive the more technical debt you have. If a section of the code is bug-free, and unlikely to be extended to the future, then there will be no payback for cleaning up the technical debt. On the other hand, if you are constantly struggling with a core piece of code, making lots of changes to it, then you should refactor it, cleaning up the technical debt so that you can make changes to it.

In summary, technical debt is not some sort of weakness in code that needs to be fought, but merely an aspect of code that needs to be managed.

Complexity

More and more, software ends up interacting with other software. This causes unexpected things to happen.

That's true, but the alternative is worse. As a software engineer building a system, you can either link together existing bits of code, or try to "reinvent the wheel" and write those bits yourself. Reinventing is sometimes good, because you get something tailored for your purpose without all the unnecessary complexity. But more often you experience the rewriting problem I describe above: your new code is untested and buggy, as opposed to the well-tested, robust, albeit complex module that you avoided.

The reality of complexity is that we demand it of software. We all want Internet-connected lightbulbs in our homes that we can turn on/off with a smartphone app while vacationing in Mongolia. This demands a certain level of complexity. We like such complexity -- arguing that we should get rid of it and go back to a simpler time of banging rocks together is unacceptable.

When you look at why glitches at United, NYSE, and WSJ happen, it because once they've got a nice robust system working, they can't resist adding more features to it. It's like bridges. Over decades, bridge builders get more creative and less conservative. Then a bridge fails, because builders were to aggressive, and the entire industry moves back into becoming more conservative, overbuilding bridges, and being less creative about new designs. It's been like that for millennia. It's a good thing, have you even seen the new bridges lately? Sure, it has a long term cost, but the thing is, this approach also has benefits that more than make up for the costs. Yes, NYSE will go down for a few hours every couple years because of a bug they've introduced into their system, but the new features are worth it.

By the way, I want to focus on the author's quote:

Getting rid of errors in code (or debugging) is a beast of a job

There are two types of software engineers. One type avoids debugging, finding it an unpleasant aspect of their job. The other kind thinks debugging is their job -- that writing code is just that brief interlude before you start debugging. The first kind often gives up on bugs, finding them to be unsolveable. The second type quickly finds every bug they encountered, even the most finicky kind. Every large organization is split between these two camps: those busy writing code causing bugs, and the other camp fixing them. You can tell which camp the author of this Medium story falls into. As you can tell, I have enormous disrespect for such people.

"Lack of interest in fixing the actual problem"

The NYSE already agrees that uptime and reliability is the problem, above all others, that they have to solve. If they have a failure, it doesn't mean they aren't focused on failures as the problem.

But in truth, it's not as big a problem as they think. The stock market doesn't actually need to be that robust. It's more likely to "fail" for other reasons. For example, every time a former President dies (as in the case of Ford, Nixon, and Reagan), the markets close for a day in mourning. Likewise, wild market swings caused by economic conditions will automatically shut down the market, as they did in China recently.

Insisting that code be perfect is absurd, and impossible. Instead, the only level of perfection the NYSE needs is so that glitches in code shut down the market less often than dead presidents or economic crashes.

The same is true of United Airlines. Sure, a glitch grounded their planes, but weather and strikes are a bigger problem. If you think grounded airplanes is such an unthinkable event, then the first thing you need to do is ban all unions. I'm not sure I disagree with you, since it seems every flight I've had through Charles de Gaulle airport in Paris has been delayed by a strike (seriously, what is wrong with the French?). But that's the sort of thing you are effectively demanding.

The only people who think that reliability and uptime are "the problem" that needs to be fixed are fascists. They made trains "run on time" by imposing huge taxes on the people to overbuild the train system, then putting guns to the heads of the conductors, making them indentured servants. The reality is that "glitches" are not "the problem" -- making systems people want to use is the problem. Nobody likes it when software fails, of course, but that's like saying nobody likes losing money when playing poker. It's a risk vs. reward, we can make software more reliable but at such a huge cost that it would, overall, make software less desirable.

Conclusion

Security and reliability are tradeoffs. Problems happen not because engineers are morally weak (political, stupid, lazy), but because small gains in security/reliability would require enormous sacrifices in other areas, such as features, cost, performance, and usability. But "tradeoffs" are a complex answer, requiring people to thinki. "Moral weakness" is a much easier, and more attractive answer that doesn't require much thought, since everyone is convinced everyone else (but them) is morally weak. This is why so many people in my Twitter timeline keep mentioning that stupid Medium article.

More ProxyHam stuff

noreply@blogger.com (Robert Graham) — Wed, 15 Jul 2015 16:37:00 +0000

Somebody asked how my solution in the last post differed from the "ProxyGambit" solution. They missed my point. Just because I change the tires on the car doesn't mean I get credit for inventing or building the car. The same thing with this ProxyHam nonsense: nobody is "building a solution". Instead, we are all just using existing products the way they are intended. We are all just choosing a different mix of components.

People get all excited when they see a bare Raspberry Pi board, but the reality is that there's nothing interesting going on here, no more than lifting the hood/bonnet on your car. This is photograph from ProxyGambit:

What ProxyGambit is doing here is using cellular data on the far end rather stealing WiFi from Starbucks or the local library. Their solution looks fancy, but you can do the same thing with off-the-shelf devices for a lot cheaper. Here is the same solution with off-the-shelf products:

This is just a TL-WR703N ($26) router with a 3G USB dongle. You can get these dongles cheap off eBay used, or new for around $17. Combined, they are cheaper than a Raspberry PI. If you want to customize this, you can replace the firmware on the router with dd-wrt/OpenWRT Linux.

Like my solution, they chose Ubquiti's NanoStation. However, they went with the 2.4 GHz version (locoM2 for $49) rather than my choice of 900 MHz (locoM9 for $125). There's also a 5 GHz version one could choose from (locoM5 for $62).

The 900 MHz, 2.4 GHz, and 5 GHz are all unregulated ISM bands. They all require relatively direct line-of-sight. The 5 GHz band requires absolutely no obstructions -- you have to be able to see the other end of the connection with binoculars. The 2.4 band allows some light foliage to be in the way. The 900 MHz band is very forgiving, allowing heavy foliage and possibly a house in the way.

The upshot is that the difference between "ProxyGambit" and my solution is the use of a cellular modem on the far end rather than hitching a ride with Starbucks, and the choice of a 2.4 GHz for the long distance connection rather than 900 MHz. But don't be limited by these choices -- there is a huge range of choices that can be made here. ProxyGambit made some interesting choices -- give it a try yourself and make some different ones.

How to build your own ProxyHam

noreply@blogger.com (Robert Graham) — Tue, 14 Jul 2015 19:23:00 +0000

"ProxyHam" created controversy because the talk was supposedly suppressed by the US government. In this post, I'll describe how you can build your own, with off-the-shelf devices, without any code.

First, head on over to NewEgg. For a total of $290.96, buy two locoM9 repeaters (for $125.49 each), and two WiFi routers, like the TL-WR700N for $19.99 each.

Grab your first WiFi device. Configure it in "client" mode, connecting it to the "Starbucks" SSID. In this mode, you can then connect your laptop via Ethernet to this device, and you'll have access to the Internet via your WiFi device to Starbucks. In other words, it acts as a WiFi dongle, but one that you attach via Ethernet instead of USB.

Now grab your two locoM9 devices and configure them for "transparent bridging". In this mode, whatever Ethernet packets that are received on one end get sent over the air to the other end. Connect each localM9 via the TL-WR700N via the supplied Ethernet cable.

Now grab the second WiFi device and configure it as a normal WiFi router.

Now, assuming you aim the localM9's correct toward each other with reasonable line-of-sight, you've got a "ProxyHam".

The reason this works so easily is that everything has been designed to work this way. Bands like 900 MHz, 2.4 GHz, and 5 GHz are the "ISM bands" that are largely unregulated by the government. Unregulated means that if somebody is causing interference in those bands, you can't complain to the government to make them stop.

The 900 MHz band is attractive because the signal will go a lot further than 2.4 GHz. On the other hand, it's a smaller band, so can't carry the same speed as 2.4 GHz band or the 5 GHz band.

Industrial equipment use the 900 MHz band extensively. There are an enormous number of devices that'll bridge two wires in this band. Most of them are for simple serial protocols like RS232. Some are for Ethernet, like the locoM9. They tend be industrial grade things that cost a lot more. The locoM9 is the cheapest device that does this from Ubiquiti, but they have a lot of more expensive stuff to choose from, often with better directional antennas that'll go farther.

WiFi, too, is supposed to work this way. When you buy a WiFi router, you normally set it up in "access-point" mode. But virtually every router supports other modes, such as the "client" or "bridging" mode described above. It's supposed to work this way.

The point of "ProxyHam" isn't that there is some new magic out there, but that hackers can take existing stuff, for their expected purpose, but achieving an unexpected outcome.

ProxyHam conspiracy is nonsense

noreply@blogger.com (Robert Graham) — Mon, 13 Jul 2015 22:31:00 +0000

This DEF CON conspiracy theory is about a canceled talk about "ProxyHam", which has been canceled under mysterious circumstances. It's nonsense.

The talk was hype to begin with. You can buy a 900 MHz bridge from Ubquiti for $125 (or MicroTik device for $129) and attach it to a Raspberry Pi. How you'd do this is obvious. It's a good DEF CON talk, because it's the application that important, but the technical principles here are extremely basic.

If you look careful at the pic in the Wired story on ProxyHam, it appears they are indeed just using the Ubuiti device. Here is the pic from Wired:

And here is the pic from Ubquiti's website:

I don't know why the talk was canceled. One likely reason is that the stories (such as the one on Wired) sensationalized the thing, so maybe their employer got cold feet. Or maybe the FBI got scared and really did give them an NSL, though that's incredibly implausible. The feds have other ways to encourage people to be silent (I've personally been threatened to cancel a talk), but it wouldn't be an NSL.

Anyway, if DEF CON wants a talk on how to hook up a Raspberry Pi to a UbiQuiTi NanoStation LOCOM9 in order bridge WiFi, I'll happily give that talk. It's just basic TCP/IP configuration, and if you want to get fancy, some VPN configuration for the encryptions. Just give me enough lead time to actually buy the equipment and test it out. Also, if DEF CON wants to actually set this up in order to get long distance WiFi working to other hotels, I'll happily buy a couple units and set them up this way.

Update: Accessing somebody's open-wifi, like at Starbucks, is (probably) not a violation of the CFAA (Computer Fraud and Abuse Act). The act is vague, of course, so almost anything you do on a computer can violate the CFAA if prosectors want to go after you, but at the same time, this sort of access is far from the original intent of the CFAA. Public WiFi at places like Starbucks is public.

This is not a violation of FCC part 97 which forbids ham radios from encryption data. It's operating in the unlicensed ISM bands, so is not covered by ham rules, despite the name "ProxyHam".

Update: An even funner talk, which I've long wanted to do, is to do the same thing with cell phones. Take a cellphone, pull it apart, disconnect the antenna, then connect it to a highly directional antenna pointed at a distant cell tower -- several cells away. You'd then be physically nowhere near where the cell tower thinks you are. I don't know enough about how to block signals in other directions, though -- radio waves are hard.

Update: There are other devices than those I mention:

@ErrataRob Also, the Mikrotik Metal 9HPn is a better radio for this stuff http://t.co/12ljqeuF7H
— Mark Burnett (@m8urnett) July 14, 2015

Some notes when ordering Google's Project Fi

noreply@blogger.com (Robert Graham) — Thu, 02 Jul 2015 18:04:00 +0000

I just ordered my "Project Fi" phone. You probably should, too. Here are some notes (especially near the bottom on getting a new phone number).

Project Fi is Google's MVNO. An "MVNO" is a virtual mobile phone company -- they don't have any of their own network backbone or cell towers, but just rent them from the real mobile phone companies (like AT&T or T-Mobile). Most mobile phone companies are actually MVNOs, because building a physical network is expensive.

What makes Google's MVNO interesting:

Straightforward pricing. It's $20 a month for unlimited calling/texting, plus $10 per gigabyte of data used during the month. It includes tethering.
No roaming charges, in 120 countries. I can fly to Japan, Australia, and France, and still use email, Google maps, texting -- for no extra charge.

The pricing is similar to other phone companies, a little less or a little more depending on exactly what you want. For around 3 gigs a month, Project Fi is cheaper than AT&T, but for 30 gigs, it's more expensive.

There are more and more MVNOs providing easy international roaming (like Ultra.me), and your own phone company is increasingly solving the problem. T-Mobile, for example, provides free roaming at 2G speeds, enough to check email and maybe enough to navigate.

In-country phone calls are free, but international phone calls still cost $0.20 a minute -- unless you are on WiFi, in which case it's free. Again, this is a feature provided by other mobile phone companies and MVNOs.

In short, Google is really doing nothing new. They are just providing what you'd expect of a 21st century phone service without all the pricing shenanigans that other companies go through in order to squeeze extra money out of you.

One of the big things is which number you will use. In the United States, you can now take your phone number with you when you switch phone companies. But there are other options. For example, you can get a new phone number with the phone in order to try out the service, then switch numbers later. Or, you can switch your current number to Google Voice, and then simply forward it to the new phone. I'm choosing the third option -- using both phones for a while, and if I decide to keep my new Google phone, switch my old number over using Google Voice.

If you plan on getting a new phone number, there is a trick to it. In most areas, you'll just get a recycled phone number that was previously used by somebody else. You'll spend the next several years getting phone calls for that person. In particular, you'll get phone calls from collection agencies trying to collect money from dead beats that used to have your number. That's because people with credit problems go through a lot of phone numbers, either because they run up phone debt they can't pay, or because they deliberately change phones to avoid creditors. Consequently, on average, any recycled phone number you get will have one time been used by somebody with credit problems. Collection firms will then aggressively go through all the former numbers of a target and call you many times, sometimes in the middle of the night.

The way to fix this is to choose an area code without recycled numbers. In the United States, several new area codes are created every year for areas of the country that are growing, when they exhaust their existing area codes. Since long distance is free in the US, it doesn't really matter which area code you have anymore, so pick one of these new area codes for your number.

The way I did this with Project Fi was to first go to this website that documents new area codes. I then went to Google Voice to create a new number. I had to go about 10 area codes down the list to find one that Google Voice supports. I chose a number in that area, and to be certain, Googled it to make sure nobody had used it before. When I get my new Project Fi phone, the number will transfer over, becoming a real phone number instead of a virtual Google Voice number.

Thus, I get a virgin telephone number, albeit one from another state, rather than a recycled number that has been used by somebody else.

The main reason I'm getting a Project Fi phone is to hack it. The WiFi calling looks interesting, so I want to see how much I can mess with it, such as fuzzing the WiFi stack, or intercepting and decrypting my own communications. I suppose the Nexus 6 is necessary for the WiFi calling feature, but otherwise it should be possible to just stick the SIM in an iPhone. If anybody has any suggestions on what to play with, please tweet me @ErrataRob.

CyberUL is a dumb idea

noreply@blogger.com (Robert Graham) — Tue, 30 Jun 2015 19:47:00 +0000

Peiter “mudge” Zatko is leaving Google, asked by the White House to create a sort of a cyber “Underwriter Laboratories” (UL) for the government. UL is the organization that certifies electrical devices, so that they don’t short out and zap you to death. But here’s the thing: a CyberUL is a dumb idea. It’s the Vogon approach to the problem. It imagines that security comes from a moral weakness that could be solved by getting “serious” about the problem.

It’s not the hacking problem

According to data-breach reports, 95% of all attacks are simple things, like phishing, SQL injection, and bad passwords – nothing related to software quality. The other 5% is because victims are using old, unpatched software. When exploits are used, it’s overwhelmingly for software that has remained unpatched for a year.

In other words, CyberUL addresses less than 0.1% of real-world attacks.

It’s not the same quality problem

UL is about accidental failures in electronics. CyberUL would be about intentional attacks against software. These are unrelated issues. Stopping accidental failures is a solved problem in many fields. Stopping attacks is something nobody has solved in any field.

In other words, the UL model of accidents is totally unrelated to the cyber problem of attacks.

Security is a tradeoff

Security experts ignore the costs of fixing security. They assume that it due to moral weakness, and that getting tough is all that’s needed.

That’s not true. Improving security comes at great cost, in terms of price, functionality, or usability. Insecurity happens not because people are weak, but because the tradeoffs aren’t worth it. That’s why you have an iPhone, which can get hacked, instead of a 1980s era feature-phone that can do little more than make phone calls – you find the added risk worth the tradeoffs.

The premise of a CyberUL is that people are wrong, that more tradeoffs must be imposed against their will in order to improve cybersecurity, such as increasing the price, removing features, or making products hard to use.

Rules have a cost

Government already has the “Common Criteria” rules. They are all for obviously good things, like masking a password with **** when users type it in. But here’s the thing: while the actual criteria are easy and straightforward, it’s buried in layers of bureaucracy. It costs at least $1 million to get a product certified with Common Criteria.

OPM invested millions in dealing with similar bureaucratic regulations. It’s not that they had no security – it’s that their security people spent all their time with bureaucracy. They ignored basic problems like SQLi, phishing, bad passwords, and patches because compliance consumed all their budget and time.

Do you even government?

People believe that wise CyberUL administrators will define what’s right based on their own expertise. This is nonsense – rules will be designed according to whoever spends the most on lobbyists. It’s same thing that happens in every industry.

As soon as the White House starts a CyberUL, Oracle, Microsoft, and Cisco will show up offering to help. Whatever rules are created will be those that favor those three companies at the expensive of smaller companies.

Government doesn’t follow the rules, anyways

Government agencies don’t follow the rules anyway. There are so many impossibly onerous rules in government anyway that complaining and getting an exception is the norm. That’s why, for example, the Navy just gave Microsoft $20 million to continue to support WinXP – a 15 year old operating-system – which is otherwise against the rules.

Conclusion

A CyberUL is an absurd idea, being unrelated to the problem it purports to solve. The only reason people take it seriously is that they are secretly fascist at heart. They aren’t interested in solving the problem of cybersecurity, because that’s hard. Instead, they want to tell other people what to do, because that’s easy.

SQLi, phishing, bad passwords, and lack of patches are the Four Horseman of the cybersecurity apocalypse, not software quality. Unless you are addressing those four things, then you are doing essentially nothing to solve the problem.

How would you use Lua scripting in a DNS server?

noreply@blogger.com (Robert Graham) — Wed, 17 Jun 2015 17:57:00 +0000

I'm currently putting Lua into a DNS server, and I'm trying to figure out how people would use it.

A typical application would be load-balancing. How I would do this is to create a background Lua thread that frequently (many times a second) queried an external resource to discover current server utilitzation, then rewrote the RRset for that server to put the least utilized server first. This would technically change the zone, but wouldn't be handled as such (i.e. wouldn't trigger serial number changes, wouldn't trigger notification of slave zones).

Such a thread could be used for zone backends. Right now, DNS servers support complex backends like SQL servers and LDAP servers. Instead of making the server code complex, this could easily be done with a Lua thread, that regularly scans an SQL/LDAP server for changes and updates the zone in memory with the changes.

Both these examples are updating static information. One possible alternative is to execute a Lua script on each and every DNS query, such as adding a resource record to a zone that would look like this:

*.foo.example.com. TXT $LUA:my_script

Every query would cause the script to be executed. There are some issues with this, of course, but for a lot of typical uses, such limitations wouldn't matter. For example, there's complex thread synchronization issues, but I could simply force any use of this feature to go into single threaded mode -- whatever narrow use you'd have for this feature could probably accept the performance hit.

The specific use for this would be, of course, to setup a DNS communication channel. Captive portals forward DNS, but redirect other TCP/UDP packet. Sending messages back and forth through DNS would allow you to do things like tunnel Twitter messages through even without "real" Internet access. As well know, people in the past have written entire VPNs through DNS this way, with custom DNS stacks.

These are my ideas. Maybe you could post some other ideas. I'm looking for either a problem you want solved (without necessarily dictating the precise solution), or a nifty way of integrating Lua (without necessarily any specific problem in mind).

Because dossiers

noreply@blogger.com (Robert Graham) — Tue, 16 Jun 2015 21:26:00 +0000

Here's the thing about computers -- even your laptop can support "big-data" applications. There are only 300-million people in the united states. At 1-kilobyte per person, that's still only 300-gigabytes -- which fits on my laptop hard-drive.

Building dossiers is becoming a thing in the hacking underground. Every time they break into a retail chain, hospital, insurance company, or government agency, they correlate everything back to the same dossier, based on such things as social security numbers, credit card numbers, email addresses, and even IP addresses. Beyond hacked secrets, public sources of information are likewise scanned in order to add to the dossier. Tools such as Maltego make it surprisingly easy to combine your own private information with public sources in order to build such dossiers.

When even the small hacking groups are focused on this effort, you can bet the big guys like China and Russia are even more interested in this.

This is one explanation behind the OPM hack. The hackers may have had something specific in mind, such as getting the personal information from SF86 forms where those seeking clearance are forced to disclose their various addictions and perversions. It may be used to blackmail people -- while the government knows their secrets, their friends won't.

Or it may have been as simple as the fact that the OPM was an easy target, and had useful information for building dossiers -- without any particular designs on what to do with the information.

I point this out because Occam's Razor. People are postulating complex scenarios for what the hackers wanted with the information. I think the more likely answer is simply because it was there, it wasn't hard to get, and it's something you ought to get now in case you need it for somebody's dossier later.

Should I panic because Lastpass was hacked?

noreply@blogger.com (Robert Graham) — Tue, 16 Jun 2015 06:19:00 +0000

Maybe, maybe not. Lastpass uses 100000 iterations in its PBKDF2 algorithm. If you chose a long, non-dictionary password, nobody can crack it. Conversely, if you haven't, then yes, you need to change it.

I benchmarked this on my computer using "oclHashcat". It's not an exact match with the Lastpass algorithm, but it's close enough to show the performance.

As you can see, my machine is getting 2577 (two and a half thousand) random password guesses per second. This may sound like a lot, but it's not not, because cracking passwords is exponentially difficult.

Consider normal hashes, not the stronger ones used by Lastpass. My desktop can crack 1 billion of those per second. Consider that a password can be built from UPPER and lower case letters, numbers, and punctuation marks -- or about 64 variations per character.

In this case, a 5 letter password has 1 billion combinations, so a fast computer can guess it in a second. Adding one letter, with it's 64 different possibilities, makes this 64 times harder, meaning it'll take a minute. Another letter (7), and it becomes an hour. Another letter (to 8), and it becomes several days. Another letter (9), and it becomes a year. Another letter (10), and it becomes 64 years. Another letter (11), and it's thousands of years, and another letter (12) and its millions of years.

Lastpass re-hashes the password 100,000 times, which slows this down dramatically. What I could've hashed in an hour now takes a decade. On the other hand, consider an adversary like the NSA or a hacker with a botnet that controls 100,000 computers, that would speed things back up to the normal rate. But even with 100,000 computers, the NSA won't be able to brute-force a 12 letter password.

Unfortunately, brute-force isn't the only option. Hackers may instead use a dictionary attack, where they use word lists and common password choices (like GoBroncos!), and then mutate them with common patterns, like adding numbers on to the end. This speeds things up dramatically, making it easy to crack even 12 letter passwords in minutes.

In between the two are Markov chains, which is sort of like brute-forcing, but which follows the logic humans use to construct passwords. If a password letter is lower-case, it's overwhelmingly likely that the next letter will also be lower case, for example.

The upshot is that your 12 character password is a lot weaker than you assume. Your passwords not only have to be long, but also fairly random and not based much on dictionary words, and random in ways that Markov chains can't easily guess.

NSA leaker Edward Snowden recent suggested that a strong password would look like "MargaretThatcheris110%SEXY". he's been criticized for this, but actually, it indeed pretty strong. Yes, there are lots dictionary and Markov weakness, but they are compensated for by length. All else being equal, longer is better. Indeed, whatever password you have now, simply adding "xxxxxxxxxxx" onto the end of it it likely to make it unbreakable, and it's extremely easy for you to remember. A password like "MaThis110%SX" is a 12 character password such that even the NSA is unlikely to be able to break it if it were your Lastpass password -- Snowden's longer form doens't make it worse. (Note, some people claim this Snowden example isn't so secure, but they are wrong).

The downside of password complexity is that you have to both remember the password and type it in frequently. There's really no getting around this -- but that's tools like Lastpass or 1Password are for. They allow you to choose one strong pasword once, then have the system use secure random passwords for all the websites you visit. I don't use such services, I just get use to typing long strings very fast (and write down passwords), but it's a solution used by many others.

How to code: lesson 27

noreply@blogger.com (Robert Graham) — Mon, 15 Jun 2015 02:27:00 +0000

I was reading some code on the Internet today and came across this:

The thing to notice is the hang & symbols in front of the variables, instead of just making things line up. It's a stylistic quirk of the author of this code. It's a good lesson on what not to do.

There is only one important style rule and it is this: make your code look like everyone else's. The question isn't whether it's good or bad, only that it's unusual. Yes, this quick is relatively insignificant, but I point it out is that you should not be tempted, even on the smallest of things.

You see this with the evolution of programmers. In the beginning, their code is quirky as hell. Over time, as they they are exposed to more and more source by others, they start to see how these quirks are irritating, and stop doing them in their own code. The style becomes blander and blander -- but at the same time, the greatness of their construction of the code starts to shine.

When you start writing great code, you'll eventually have to break this rule and do something big and strange. For example, I do this with my "state-machine parsers". It's a programming pattern unfamiliar to most programmers, yet I have to do it because the scalability and performance are huge. Save your quirks for the big things -- exorcise them in the small things.

By the way, I meant this as the only important style rule. It really is. A lot of companies spend a great deal of time, and politically gnashing of teeth among developers, in order to draft style guidelines. This is garbage -- it truly does not matter where you put braces, for example. Experienced coders have to be accustomed to reading various styles anyway. Here's what you should do. Start a program asking anybody who is interested to come in after work in order to draft a new set of style guidelines. Fire everyone who shows up -- they are political animals who are likely deadweight anyway. Then just pick a style guideline at random, like the Linux kernel style doc or the WebKit style. Or, pick no style at all -- your project is going to pull in a lot of open-source with varying styles anyway, so it's pointless trying to make it conform.

BTW, when I invested all my money in a startup consisting of a team of programmers, when my entire life's saving depending on quality code being produced, I imposed this guideline on the team: stop with the nonsense, make it look normal. Each programmer had different styles, but yet the code produced was high quality anyway. It really can work.

How we really know the Sunday Times story is bogus

noreply@blogger.com (Robert Graham) — Sun, 14 Jun 2015 22:21:00 +0000

Stories sourced entirely from "anonymous senior government officials" are propaganda, not journalism. The identities of the sources are hidden not to protect them from speaking out against the government, since they are in fact delivering exactly the message the government wants to get out. Instead, their identities are kept secret so that their message cannot be challenged.

It's not just me claiming this. Every journalistic organization criticizes the practice. Every set of journalistic ethics guidelines calls this unethical.

Yet, somehow it keeps happening. The latest example is the The Sunday Times, Britains largest newspaper, reporting government officials critical of Snowden. We know the story is bogus, because it quotes solely government official spouting the party line. Moreover, even if that weren't the case, it's obvious propaganda, arguing one side of the story, and not even attempting to get the other point of view from Russia, China, or Snowden himself. Snowden is often quoted in newspapers, he can't be that hard to get a hold of. Not contacting Snowden for his side is also a violation of journalistic ethics.

I point this out because there are lots of good criticisms of the story, for example, pointing out that the correct term is "MI6 officers" not "agents", and no knowledgeable government expert would make that error. But a detailed analysis of that piece isn't needed. The pure fact that it tramples all over journalistic ethics is proof enough that the story is bogus.

Intel has 4 processor lines

noreply@blogger.com (Robert Graham) — Thu, 11 Jun 2015 23:13:00 +0000

Just a quick note: Intel has four different processor lines -- or four different "microarchitectures". All Intel processors support the x86 instruction set externally, but have very different microarchitectures internally.

To start with is their mainstream processor in desktops, notebooks, servers, and supercomputers. This accounts for the bulk of their business, and what we think of as an "Intel processor". The latest version of this microarchitecture is "Broadwell". Previous versions have been Haswell, Ivy Bridge, Sandy Bridge. It's sold as the Xeon, Core i7/i5/i3, Pentium, Celeron, etc.

Then there is the low power processor to compete against ARM in cellphone devices known as the "Atom". There are have been two radically different versions of this processor. The older version of the microarchitecture from 2008 was known as "Bonnel", and it kinda sucked (dual-issue, but in-order). The newer version of the microarchitecture, "Silvermont", is out-of-order, and is much better. Atom processors are just as power efficient as ARM processors. Indeed, many phones use them without people really being aware of the difference. I point this out because there is a widespread misconception that ARM processors are more power efficient than Intel processors. Note that all these processors are 64-bit internally, though some are sold as 32-bit processors with the 64-bit feature disabled.

Then there is the ultra low power processor for markets where even cellphone processors are too large. Intel sells the "Quark" processor for this. It's actually just a 486 processor from the early 1990s running at 400 MHz. It's sometimes called a "Pentium-class" processor, but it's really just been updated with some Pentium instructions like CMOV so that it can run the latest Linux kernel. It's actually pretty worthless -- at this stage in technology, RISC really was better, and ARM equivalents will perform faster using less power. Also, Silvermont processors clocked down to the same 400 MHz use much the same low power -- although they are much bigger chips. These processors are of course only 32-bit, whereas all the other processors are 64-bit.

Finally, there is graphics processor markets which Intel addresses with it's Xeon Phi product (not to be confused with normal Xeons). This competes against GPUs from nVidia and AMD/ATI. GPUs are designed to be massively parallel computers, designed originally for games, but which also work well for many supercomputer applications. Since they have been encroaching on Intel's supercomputer business, they've responded with a GPU-like chip. This chip puts 72 Silvermont Atom cores on a chip, where the cores have been tweaked to support 512-bit SIMD (i.e. eight 64-bit floating point calculations per instruction). This is the same 512-bit AVX that will be appearing in the next desktop/laptop/server processors. This means such floating point intensive software can be written on a desktop, then run on a much faster super computer. The current Xeon Phi is used in the Tianhe-2 supercomputer -- which has been the fastest supercomputer in the world for almost 2 years.

Intel has defeated all other processors over the last couple decades by making their single processor line address all markets. Competitors, namely ARM and nVidia/ATI have therefore optimized for targets Intel can't go. These additional processor lines are therefore in response to these threats.

The Atom line is going badly -- Intel essentially gives them away for free. They are technically an excellent product, beating most ARM processors in power efficiency and speed, but that doesn't matter, because in the mobile space, ARM compatibility is already more important than x86. Also, Intel doesn't have the supporting hardware infrastructure of other chips that ARM has. Intel thus gives mobile phone developers a lot of "development" money to build products -- which in the end means they are essentially giving away Atom processors.

On the flip side, Intel's mainstream server processors are still more power efficient than ARM (or Atom) processors. Those processors work better in cellphones by simply being slower, but once you speed up processor for massive computation, Intel's mainstream processors are still more power efficient. That's why you hear a lot of bluster about people building ARM servers, but when those systems are eventually shipped (such as HP's Moonshot), they come with Intel.

What's the state of iPhone PIN guessing

noreply@blogger.com (Robert Graham) — Mon, 08 Jun 2015 23:02:00 +0000

I think even some experts have gotten this wrong, so I want to ask everyone: what's the current state-of-the-art for trying to crack Apple PIN codes?

This is how I think it works currently (in iOS 8).

To start with, there is a special "crypto-chip" inside the iPhone that holds your secrets (like a TPM or ARM TrustZoneSecurCore). I think originally it was ARM's TrustZone, but now that Apple designs its own chips, that they've customized it ("Secure Enclave"). I think they needed to add stuff to make Touch ID work.

All the data (on the internal flash drive) is encrypted with a random AES key that nobody, not even the NSA, can crack. This random AES key is stored on the crypto-chip. Thus, if your phone is stolen, the robbers cannot steal the data from it -- as long as your phone is locked properly.

To unlock your phone, you type in a 4 digit passcode. This passcode gets sent to the crypto-chip, which verifies the code, then gives you the AES key needed to decrypt the flash drive. This is all invisible, of course, but that's what's going on underneath the scenes. Since the NSA can't crack the AES key on the flash drive, they must instead get it from the crypto-chip.

Thus, unlocking the phone means guessing your 4 digit PIN.

This seems easy. After all, it's only 4 digits. However, offline cracking is impossible. The only way to unlock the phone is to send guesses to the crypto-chip (a form of online cracking). This can be done over the USB port, so they (the NSA) don't need to sit there trying to type every possible combination -- they can simply write a little script to send commands over USB.

To make this more difficult, the crypto-chip will slow things down. After 6 failed guesses, the iPhone temporarily disables itself for 1-minute. Thus, it'll take the NSA a week (6.9 days), trying all 10,000 combinations, once per minute.

Better yet, you can configure your phone to erase itself after 10 failed attempts ([Erase Data] Passcode setting). This isn't the default configuration, but it's how any paranoid person (like myself) configures their phone. This is a hard lock, preventing even the NSA from ever decrypting the phone. It's the "going dark" problem that the FBI complains about. If they get the iPhone from a terrorist, drug dealers, or pedophile, they won't be able to decrypt it (well, beyond the 0.1% chance of guessing 10 random numbers). (Note: I don't think it actually erases the flash drive, but simply erases the secret AES key -- which is essentially the same thing).

Instead of guessing PIN numbers, there may be a way to reverse-engineer such secrets from the crypto-chip, such as by using acids in order to remove the top from the chip then use an electron microscope to read the secrets. (Physical possession of the phone is required). One of the Snowden docs implies that the NSA can sometimes do this, but that it takes a month and a hundred thousand dollars, and has a 50% chance of destroying the chip permanently without being able to extract any secrets. In any event, that may have been possible with the older chips, but the latest iPhones now include custom chips designed by Apple where this may no longer be possible.

There may be a a physical exploit that gets around this. Somebody announced a device that would guess a PIN, then immediately power down the device before the failed guess could be recorded. That allows an infinite number of guesses, requiring a reboot of the phone in between. Since the reboot takes about a minute, it means hooking up the phone to the special device and waiting a week. This worked in phones up to iOS 8.1, but presumably it's something Apple has since patched (some think 8.1.1 patched this).

There may be other exploits in software. In various versions of iOS, hackers have found ways of bypassing the lock screen. Generally, these exploits require the phone to still be powered on since it was stolen. (Coming out of sleep mode is different than being powered up, even though it looks like the same unlocking process to you). However, whenever hackers disclose such techniques, Apple quickly patches them, so it's not a practical long term strategy. On the other hand, they steal the phone, the FBI/NSA may simply hold it powered on in storage for several years, hoping an exploit is released. The FBI is patient, they really don't care if it takes a few years to complete a case. The last such exploit was in iOS 7.0, and Apple is about to announce iOS 9. They are paranoid about such exploits, I doubt that a new one will be found.

If the iPhone owner synced their phone with iTunes, then it's probable that the FBI/NSA can confiscate both the phone and the desktop in order to grab the data. They can then unlock the phone from the desktop, or they can simply grab the backup files from the desktop. If your desktop computer also uses disk encryption, you can prevent this. Some desktops use TPMs to protect the disk (requiring slow online cracking similar to cracking the iPhone PIN). Others would allow offline cracking of your password, but if you chose a sufficiently long passwords (mine is 23 characters), even the NSA can't crack it -- even at the rate of billions of guesses per second that would be possible with offline cracking.

The upshot is this. If you are a paranoid person and do things correctly (set iPhone to erase after 10 attempts, either don't sync with desktop or sync with proper full disk encryption), then when the FBI or NSA comes for you, they won't be able to decrypt your phone. You are safe to carry out all your evil cyber-terrorist plans.

I'm writing this up in general terms because I think this is how it works. Many of us general experts glance over the docs and make assumptions about how we think things should work, based on our knowledge of crypto, but we haven't paid attention to the details, especially the details as the state-of-the-art changes over the years. Sadly, asking general questions gets general answers from well-meaning, helpful people who really know only just as much as I do. I'm hoping those who are up on the latest details, experts like Jonathan Zdziarski, will point out where I'm wrong.

Response: So Jonathan has written a post describing this in more detail here: http://pastebin.com/SqQst8CV

He is more confident the NSA has 0days to get around everything. I think the point wroth remembering is that nothing can be decrypted without 0days. and that if ever 0days become public, Apple patches them. Hence, you can't take steal somebody phone and take it to the local repair shop to get it read -- unless it's an old phone that hasn't been updated. It also means the FBI is unlikely to get the data -- at least without revealing that they've got an 0da.

Specifics: Specifically, I think this is what happens.

Unique-id (UID): When the CPU is manufactured, it's assigned a unique-identifier. This is done with hardware fuses, some of which are blown to create 1 and 0s. Apple promises the following:

that UIDs are secret and can never be read from the chip, but anybody, for any reason
that all IDs are truely random (nobody can guess the random number generation)
that they (or suppliers) keep no record of them

This is the root of all security. If it fails, then the NSA can decrypt the phone.

Crypto-accelerator: The CPU has a built-in AES accelerator that's mostly separate from the main CPU. One reason it exists is to quickly (with low power consumption) decrypt/encrypt everything on the flash-drive. It's the only part of the CPU that can read the UID. It can therefore use the UID, plus the PIN/passcode, to encrypt/decrypt something.

Special flash: Either a reserved area of the flash-drive, or a wholly separate flash chip, is used to store the rest of the secrets. These are encrypted using the UID/PIN combo. Apple calls this "effaceable" storage. When it "wipes" the phone, this area is erased, but the rest of the flash drive isn't. Information like your fingerprint (for Touch ID) is stored here.

So the steps are:

iOS boots
phone asks for PIN/passcode
iOS sends PIN/passcode to crypto-accelerate to decrypt flash-drive key (read from the "effaceable" storage area)
uses flash-drive key to decrypt all your data

I'm skipping details. This is just enough to answer certain questions.

FAQ: Where is the unique hardware ID stored? On the flash memory? The answer is within the CPU itself. Flash memory will contain further keys, for example to unlock all your data, but they have to be decrypted using the unique-id plus PIN/passcode.

Uh, the only reform of domestic surveillance is dismantling it

noreply@blogger.com (Robert Graham) — Tue, 02 Jun 2015 22:50:00 +0000

A lot of smart people are cheering the reforms of domestic surveillance in the USA "FREEDOM" Act. Examples include Timothy Lee, EFF, Julian Sanchez, and Amie Stepanovich. I don't understand why. Domestic surveillance is a violation of our rights. The only acceptable reform is getting rid of it. Anything less is the moral equivalent of forcing muggers to not wear ski masks -- it doesn't actually address the core problem (mugging, in this case).

Bulk collection still happens, and searches still happen. The only thing the act does is move ownership of the metadata databases from the NSA to the phone companies. In no way does the bill reform the idea that, on the pretext of terrorism, law enforcement can still rummage through the records, looking for everyone "two hops" away from a terrorist.

We all know the Patriot Act is used primarily to prosecute the War on Drugs rather than the War on Terror. I see nothing in FREEDOM act that reforms this. We all know the government cloaks its abuses under the secrecy of national security -- and while I see lots in the act that tries to make things more transparent, the act still allows such a cloak.

I see none of the reforms I'd want. For example, I want a law that requires the disclosure, to the public, of the total number of US phone records the government has grabbed every month, regardless of which law enforcement or intelligence agency grabbed them, regardless of which program or authority was used to grab them. After Snowden caught the government using wild justification for it's metadata program -- any law that doesn't target such all such collection regardless of justification will work to reign it in.

A vast array of other things need to be reformed regarding domestic surveillance, such as use of "Stingray" devices, the "third party doctrine" allowing the grabbing of business records even without terrorism as a justification, parallel construction, the border search exemption, license plate readers, and so on.

Bulk collection happens. our lives are increasingly electronic. We leave a long trail of "business records" behind us whatever we do. Consider Chris Roberts, "Sindragon", who joked about hacking a plane on Twitter and is now under investigation by the FBI. They can easily rummage through all those records. While they might not find him guilty of hacking, they may find he violated an obscure tax law or export law, and charge him with that sort of crime. That everything about our lives is being collected in bulk, allowing arbitrary searches by law enforcement, is still a cyber surveillance state, that the FREEDOM act comes nowhere close to touching.

The fact of the matter is that the NSA's bulk collection was the least of our problems. Indeed, the NSA's focus on foreign targets meant, in practice, it really wasn't used domestically. The FREEDOM act now opens up searches of metadata to all the other law enforcement agencies. Instead of skulking in secret occasionally searching metadata, the FBI, DEA, and ATF can now do so publicly, with the blessing of the law behind them.

Understanding TSA Math

noreply@blogger.com (Robert Graham) — Tue, 02 Jun 2015 00:27:00 +0000

At the end of every year, the TSA blogs about the weapons and explosives it prevented from getting on board airplanes. They are trying to brag about all the dangers they've stopped. But the opposite is true, when you do the math, you realize that they are stopping no dangers at all. The TSA stops less than half the bombs that get on board airplanes -- yet airplanes are not falling out of the sky due to the bombs that do get on board. Thus, mathematically, bombs aren't a danger. It therefore doesn't matter if the TSA stops bombs or not.

We know the TSA stops less than 50% of bad stuff from various sources. The first is the government's own tests, such as that described in a recent story where the TSA failed a shockingly 95% of the time.

Another is a statistic reported by the TSA where the number of firearms they stop every year is rapidly increasing. This does not match any other trend in society, such as the number of people carrying firearms. The only reason for such rapid growth is that the TSA gets better every year at detection. That means, historically, the TSA is letting an enormous number of firearms through. Since the graph isn't tapering off, we can assume they are still far from reaching 100%.

Lastly, there is anecdotes. I hear frequent stories of people arriving at their destination with knives and guns that they've accidentally carried through TSA security. Asking on twitter reveals many more. Lots of people admit to having carried loaded weapons through TSA security. Such stories are common -- but I've never heard of somebody getting caught -- being one of those counted in the TSA statistics in there charts. Anecdotal, albeit from small sample size, this seems to confirm that you have a less than 50% chance of getting caught.

This leads to a counter-intuitive result that the TSA is really not stopping any danger. If guns and bombs are getting on planes, but planes aren't falling out of the sky, it must mean that they aren't a danger.

I point this out because in the end, safety is an emotional thing rather than logical. No matter how much I do the math, people do not believe it. They believe bombs are a danger to airplanes in much the same way many don't believe the safety statistics compared to driving.

Of course, this does not necessarily prove the TSA is ineffective. The security theater may discourage terrorist wannabes. Also, racist profiling may be more effective at stopping certain weapons than for the general population. I have an Iranian friend who apparently gets felt up every flight [which, separate from math, makes we want to say "fuck you TSA"].

But I suspect the TSA really is useless. I suspect the real reason that terrorists haven't taken planes out of the sky is that it frankly isn't that great of a threat, and that the existence of the TSA is simply because police-states gonna police-state.

Ulbricht's judge punished him for political dissent; you should find this outrageous

noreply@blogger.com (Robert Graham) — Mon, 01 Jun 2015 07:35:00 +0000

Silk Road operator Ross Ulbricht was sentenced to life in prison without parole. Maybe this is a fair sentence for selling $200 million in illegal drugs. Or, since all the lawyers I talk to think it's excessive (worse than what even the prosecutors asked for), maybe it's within the normal range of excess in the War on Drugs. I'm not a lawyer, so I can't judge this.

But, I'm interested in the comments the judge made justifying her harsh sentence. According to Andy Greenberg at WIRED, the judge said:

“The stated purpose [of the Silk Road] was to be beyond the law. In the world you created over time, democracy didn’t exist. ... Silk Road’s birth and presence asserted that its…creator was better than the laws of this country. This is deeply troubling, terribly misguided, and very dangerous.”

This is silly on the face of it. The stated purpose of all crime is to "be beyond the law". I mean, when I go above the speed limit in my BMW, my stated purpose is to go beyond the legal limit. I'm not sure I understand the logic here.

I'm being disingenuous, of course, because I do understand. What the judge is really upset about is that Silk Road was not simply criminal but also political dissent. Ulbricht quite clearly said the laws governing drugs and marketplaces were wrong.

In other words, the judge expressly stated that she is using the power of the court in order to punish political dissent. She labeled Ulbricht and enemy of the state. This is Orwellian -- and stands against everything we believe about justice in this country. I'm a bit flabbergasted not simply that she said this, but that it has gone unremarked.

It's like punishing the vandals of the Boston Tea Party for more than mere vandalism, but for striking a revolutionary blow against the British Parliament. Or it's like throwing Rosa Parks in jail, not simply for the minor infraction of sitting in the wrong location, but for being uppity and challenging the social order. Whether or not you agree with Ulbricht's politics, they should in no way harshen his sentence.

This is especially true since the country is rapidly moving in the direction of Ulbricht's politics. Since the Silk Road case began, numerous states have legalized marijuana (which accounted for a quarter of Silk Road's sales). Presidential candidates on both the right and the left this season are remarking on the inherent unfairness of the War on Drugs, both that it incarcerates 1% of our population (a rate ten times higher than Europe), but that it's obviously racially biased. Ulbricht's politics aren't isolated -- they are part of a movement.

Many in our community go the other way, claiming that since the crimes from Manning to Hammond were political, that the law should be lenient. This is wrong, of course, but so is the idea that political actions deserve harsher sentences.

A similar problem exists with the statements made by both the judge and the prosecutors about the need to "set an example". The idea is that Ulbricht created some new model of crime, and that in order to discourage others from copying him, that the punishment needs to be especially harsh.

But think this through. What hackers do is innovate. Whether it's Aaron Swartz, Weev, Ulbricht, or a long parade of other hackers, these people challenged the system. Prosecutors had to stretch old laws to fit new actions in cyberspace -- often past their breaking point (they sometimes weren't crimes). Ulbricht clearly committed crimes, but in new ways.

Therefore, the effect of "setting an example" is this: hackers usually get extra punishments. Hackers innovate, innovation is bad. In other words, this is a symptom of the government's War on Hackers. We not only have to contend with new laws, emergency decrees, exports controls, and a vast array of rules that constrain our actions. We also have to contend with additional punishments when we break those rules.

I want to point these two things out because while lots of people are saying the punishment was excessive, I haven't seen anybody point out a discussion why. I think the War on Drugs has made us numb, since so many people get extreme punishments. But those two comments are important. That hackers deserve extra punishment for the crime of innovating seems wrong. That political dissent deserves special punishment is absolutely wrong, and should be the focus of much outrage.

Some notes about Wassenaar

noreply@blogger.com (Robert Graham) — Wed, 27 May 2015 05:29:00 +0000

So #wassenaar has infected your timeline for the past several days. I thought I'd explain what the big deal is.

What's a Wassenaar?

It's a town in Europe where in 1996 a total of 41 nations agreed to an arms control treaty. The name of the agreement, the Wassenaar Arrangement, comes from the town. The US, Europe, and Russia are part of the agreement. Africa, Middle East, and China are not.

The primary goal of the arrangement is anti-proliferation, stopping uranium enrichment and chemical weapons precursors. Another goal is to control conventional weapons, keeping them out of the hands of regimes that would use them against their own people, or to invade their neighbors.

Historically in cybersec, we've complained that Wassenaar classifies crypto as a munition. This allows the NSA to eavesdrop and decrypt messages in those countries. This does little to stop dictators from getting their hands on strong crypto, but does a lot to prevent dissidents in those countries from encrypting their messages. Perhaps more importantly, it requires us to jump through a lot of bureaucratic hoops to export computer products, because encryption is built-in to virtually everything.

Why has this become important recently?

Last year, Wassenaar added cyberweapons to the list. On May 20th, the United States Bureau of Industry and Security (BIS) proposed US rules to comply with the Wassenaar additions. They are currently accepting comments about these rules.

The proposed BIS rules go beyond the simpler Wassenaar rules, affecting a large number of cybersecurity products, and cybersecurity research. These rules further restrict anything that may be used to develop a cyberweapon, which therefore make a wide number of innocuous product export-restricted, such as editors and compilers.

It's not that these rules will necessarily block the export of legitimate products, but that it creates a huge bureaucracy that will apply the rules prejudicial and arbitrarily. It's easy to make mistakes -- and a mistake can cost a person 20 years in jail and $1 million. This will create a huge chilling effect even among those who don't intend to export anything.

What specific cyber-weapons is Wassenaar trying to restrict?

The arrangement added three categories of cyber-weapons.

The first is "intrusion malware". The specific example is malware sold by FinFisher to governments like Bahrain, which has been found on laptops of Bahraini activists living in Washington D.C.

The second is "intrusion exploits". These are tools, including what's known as "0-days", that exploit a bug or vulnerability in software in order to hack into a computer, usually without human intervention.

The third is "IP surveillance" products. These are tools, like those sold by Amesys, that monitor Internet backbones in a country, spy on citizen's activities, and try to discover everyone activists/dissents talk to.

Wassenaar includes both intrusion malware and intrusion exploits under the single designation "intrusion software", but while they are both related, they are significantly different from each other. The BIS rules clarifies this difference more.

Haven't I heard about 0-days/zero-days before?

The bulk of cyber-security research is into vulnerabilities, which are software bugs that hackers can exploit in order to break into computer. Over the last 15 years, the relentless pursuit of these vulnerabilities has made computers dramatically safer.

When such bugs are first discovered, before anybody else knows about them, they are known as 0-days. Almost always, researchers give those 0-days to the appropriate company so that they can fix the bug.

Sometimes, however, a researcher may sell the 0-day to the NSA, so that they can secretly hack into computers using a bug nobody knows about. Selling 0-days has been a big controversy in the community, especially since the Snowden affair.

It's perfectly legal for American researchers to sell 0-days to the Chinese government instead of the NSA -- which would presumably then use them to hack American computers. One goal of the Wassenaar agreement is to close this obvious loophole.

One of the controversial provisions of the export license is that companies/individuals may have to share their secret 0-days with the NSA in order to get a license.

Isn't stopping intrusion and surveillance software a good thing?

Maybe. Certainly companies like FinFisher and Amesys are evil, knowingly selling to corrupt governments that repress their people.

However, good and evil products are often indistinguishable from each other. The best way to secure your stuff is for you to attack yourself.

That means things like bug bounties that encourage people to find 0-days in your software, so that you can fix them before hackers (or the NSA) exploit them. That means scanning tools that hunt for any exploitable conditions in your computers, to find those bugs before hackers do. Likewise, companies use surveillance tools on their own networks (like intrusion prevention systems) to monitor activity and find hackers.

Thus, while Wasenaar targets evil products, they inadvertently catch the bulk of defensive products in their rules as well.

Isn't stopping intrusion and surveillance software a good thing? (part 2)

Maybe. Here's the thing, though: the cyberspace has no borders.

Normal arms control works because they are physical things. They require a huge industrial base to produce. Not only the weapons themselves, but the equipment and materials used to produce weapons can be tracked. Even if the bad guys sneak through the original weapons, they will still struggle to keep smuggling the parts needed to keep them working.

None of this argument applies to cyberspace. A single hacker working out of their mom's basement can create the next devastating 0-day. Right now, e-commerce sites block the IP addresses from restricted countries. But, those countries can simply call up their ambassador in an unblocked country in order to purchase a product.

That's not to say export controls would have no leverage. For example, these products usually require an abnormally high degree of training and technical support that can be tracked. However, the little good export controls provide is probably outweighed by the harm -- such as preventing dissidents in the affected countries from being able to defend themselves. We know they do little good know because we watch Bashar Al Assad brandish the latest iPhone that his wife picked up in Paris. Such restrictions may stop the little people in his country getting things -- but they won't stop him.

Isn't there an exception for open-source?

Yes and no. Wassenaar explicitly exempts open-source code in theory. That means you can publish your code to GitHub knowing that corrupt governments will use it, without getting in trouble with the law.

However, there are situations where this doesn't apply. When security researchers discover 0-day, they typically write a proof-of-concept exploit, then present their findings at the next conference. That means they have unpublished code on their laptop, code that they may make public later, but which is not yet technically open-source. If they travel outside the country, they have technically violated both the letter and the spirit of the export restrictions, and can go to jail for 20 years and be forced to pay a $1 million fine.

Thus, make sure you always commit your latest changes to GitHub before getting on a plane.

What's the deal with security research?

One of the most vocal groups in opposition to Wassenaar is security researchers. That's because they are under attack by a wide variety of proposals in the current administration's "War on Hackers".

Proposed changes to the anti-hacking law, the CFAA, would technically make security research into 0days illegal. Copyright law, the DMCA, is frequently exploited for the non-copyright purpose of suppressing researchers. The recent of State of Emergency declaration would allow the government to unilaterally seize a security researcher's assets if the government believed they helped Chinese hackers. And lastly, these proposed BIS rules would impose export restrictions on all security research.

Discovering vulnerabilities in products, especially products from prickly companies like Oracle and Microsoft, embarrasses them. They see the security researchers, rather than the hackers, as their primary threat. They put a lot of pressure on government to do something about those pesky researchers.

What's the penalty for improperly exporting something?

Nobody knows, because the BIS gets to arbitrarily impose penalties. They could decide to send you a warning letter, or they could decide to send you to jail for 20 years with a $1 million fine. It's described somewhat here.

It seems good that the BIS can decide to simply warn you if you make a mistake, but the opposite is true. Such warnings go to people who play along, such as by sharing their 0-days with the NSA. Harsher punishments go to those who stand up against the system.

That's been a frequent criticism of anti-hacking laws: their punishments are unreasonably severe, and meted out in a prejudicial and arbitrary fashion. Those who annoy the powerful are the ones who get punished most.

Why this anger toward privacy groups?

Because they got precisely what they asked for.

Privacy groups have long attacked companies like FinFisher and Amesys. They have pushed for regulations to stop these companies, sometimes explicitly for export restrictions. Now that these regulations are here, and their impact obvious, these privacy activists are complaining the rules go too far -- and that they aren't responsible.

But cybersecurity experts have long warned of this, specifically that good and bad products are technically indistinguishable. Privacy groups have ignored these warnings. A good example is this post from Privacy International where they consider, then reject, the warning.

The feuding between privacy/rights organizations and cybersecurity researchers predates the Wassenaar debate. For example, Chris Soghoian, the Principal Technologist at the ACLU, calls 0-day sellers "merchants of death". 0-day sellers in turn call Soghoian a "fascist" for his attack on their free speech rights.

Smarter organizations like the EFF have consistently warned that technical distinctions in regulations were nearly impossible. However, they still have championed the cause that "something must be done" about FinFisher and Amesys without taking a principled stand against government regulation -- at least not the same stand as cybersecurity researchers.

Are there other issues besides cybersecurity?

Yes. For example, only software used by corrupt governments is controlled. Software used to enforce copyright, or track users for advertising, is explicitly allowed. Likewise, far from restricting software that the NSA can use to spy on people, one of the provision suggests that the NSA should get a copy of the source code before an export license will be granted.

There's a couple First Amendment issues. Code is speech, and in many ways this restricts code (though open-source code is untouched by the rules). Separately, the way restrictions and punishments can be arbitrarily applied gives the government leeway to punish those who speak up.

Conclusion

The BIS proposal is not yet fixed in stone. The comment period ends July 20. You can submit comments here.

One thing to note is that the comments we want to make don't precisely match up with the questions they are asking. For example, they ask "How many additional license applications would your company be required to submit per year?" This has nothing to do with why people are up in arms over this proposal.

Update: The original version said that the DMCA was recently changed to attack researchers. The reverse is true -- it's long been used to attack researchers. Some are trying to clarify the rules to allow vulnerability research, but there is strong pushback from various quarters, like car companies.

EFF and intrusion software regulation

noreply@blogger.com (Robert Graham) — Tue, 26 May 2015 21:22:00 +0000

To its credit, the EFF is better than a lot of other privacy groups like the ACLU or Privacy International. It at least acknowledges that regulating "evil" software can have unintended consequences on "good" software, that preventing corrupt governments from buying software also means blocking their dissidents from buying software to protect themselves. An example is this piece from several years ago that says:

"First and foremost, we want to make sure we do not leave activists with fewer tools than they already have. Parliament must be mindful of legislation just based on types of technology because broadly written regulations could have a net negative effect on the availability of many general-purpose technologies and could easily harm very people that the regulations are trying to protect."

But that does not stop the EFF from proposing such regulations.

In that same piece, the EFF first proposes rules for transparency. This will not stop the bad companies, but will be a burden on the legitimate companies that have no interesting in dealing with corrupt governments anyway. Most of this stuff is sold by small companies, like FinFisher, who focus on the "corrupt regime" market. They would not be embarrassed by transparency -- indeed it was just serve as advertising. These pieces outing FinFisher, Amesys, Area SpA, and Trovicor are essentially advertisements that help their business.

The EFF next proposes rules for know your customer. This is so burdensome as to effectively be a ban. Products are sold through middlemen, though distributers and resellers. Companies wish they could know their customer, because they'd like to cut out the middleman. But at the same time, the middleman provides access to markets they could not otherwise touch. A know your customer requirement would break most company's marketing and sales channels.

There's no satisfactory way to know a customer. If a small ISP in one of those countries wants to buy my "intrusion prevention" product, in order to defend against intrusion from their own government or the NSA, there is no way I can sell it to them. Intrusion prevention products do deep-packet that is indistinguishable from surveillance products. There is no way they can prove to me that they aren't a front for a government agency that wants to buy my product for surveillance.

The EFF says knowing customers is easy, because companies have to be able to do it already for the Foreign Corrupt Practices Act. This is a misunderstanding -- companies largely bypass that Act by selling through middlemen. India is a huge, but corrupt market. Everyone sells products to India. Nobody does it directly, through, because large sales always require bribes. Therefore, they sell through middlemen, washing their hands clean of corrupt practices. Companies don't always do this intentionally -- if they write off a country because it's too corrupt, some middleman somewhere will buy product and import it to that country anyway. (This has happened to me -- I scan the entire Internet and sometimes find my own product that countries aren't supposed to have).

The point is that the EFF does not stand for the principle that such regulations are bad. Instead, they stand for the principle that there should be proper regulation. This is like getting only a little bit pregnant -- it's not realistic. It's at least better than other privacy organizations, but it's still far from the ideal. The EFF's call for regulation is at least partly responsible for the bad regulations that we get.

This is how we get ants

noreply@blogger.com (Robert Graham) — Mon, 25 May 2015 23:53:00 +0000

Today's Wassenaar proposal to limit 0days -- and thereby virtually all cybersecurity products -- is partly the result of lobbying by the ACLU and EFF. The principle technologist of the ACLU called 0day sellers "merchants of death". The EFF called for 0day sales to governments to be the center of any policy debate on cybersecurity.

Yet, they deny responsibility for Wassenaar -- because the regulations go too far, and appear to restrict virtually all cybersecurity software and any free-speech on the topic. These groups now back off and claim they never called for 0day restrictions in the first place.

For example, when the EFF said "exploit sales should be key point in cybersecurity debate", nowhere in the article does it explicitly call for a ban on exploit sales. Their focus was on limiting the actions of the NSA in buying exploits, not so much those who would sell the exploits.

This is true, but only technically. There's no conceivable situation where the US Government would unilaterally disarm itself of cyberweapons while allowing everyone else to purchase them. It's also not conceivable that when you've put that much work into calling 0days evil and unethical, that a reasonable person wouldn't interpret this as a call to ban them. If you say the issue of governments (plural, not just the US) buying 0days should be at the center of policy debates, that means Wassenaar -- the primary international arrangement for arms control.

But more importantly, the EFF never clarified its remarks. After the EFF published the document, the cybersecurity community quickly responded. Critics pointed out that the EFF was implicitly calling for a ban on 0day. The EFF responded by pointing out the technicality that their call for regulation wasn't explicit. They did not respond by publishing a document explicitly supporting 0day.

That's likely to continue to be the case. The EFF is going to publish a response to the US Wassenaar proposals. While the EFF may point out that Wassenaar goes too far, the EFF is unlikely to defend the rights of 0day coders. The EFF may tacitly agree that proper 0day restrictions are a good thing -- just deny that the currently proposed restrictions are proper.

The debate between researchers and the EFF/ACLU has raged for three years now. The EFF/ACLU can end this debate at any time by publishing an official document in support of 0day research. Until that happens, the only reasonable way to interpret their position (as demonstrated in the above link) is that they want 0day bans.

I point this out because this is how you get totalitarianism. Strident populism leads to regulation. Each one looks good when viewed in isolation, but there's always unexpected consequences. Populists deny they are responsible for those unintended consequences -- but they are. 0days are just speech and standard cybersecurity practice. There's no way to split the baby, to separate out the bad stuff you want to prevent without also limiting good speech and good cybersecurity products. The current attempt by the EFF to split the baby just won't work. If the EFF were serious about principle instead of populism, the only tenable position is an absolute support for free-speech, coder's rights, and cybersecurity research -- and thus absolute support for 0day.

Our Lord of the Flies moment

noreply@blogger.com (Robert Graham) — Sun, 17 May 2015 00:23:00 +0000

In its war on researchers, the FBI doesn't have to imprison us. Merely opening an investigation into a researcher is enough to scare away investors and bankrupt their company, which is what happened last week with Chris Roberts. The scary thing about this process is that the FBI has all the credibility, and the researcher none -- even among other researchers. After hearing only one side of the story, the FBI's side, cybersecurity researchers quickly turned on their own, condemning Chris Roberts for endangering lives by taking control of an airplane.

You cannot promote the (true) idea that security research benefits humanity while defending research that endangered hundreds of innocents
— Alex Stamos (@alexstamos) May 16, 2015

As reported by Kim Zetter at Wired, though, Roberts denies the FBI's allegations. He claims his comments were taken out of context, and that on the subject of taking control a plane, it was in fact a simulator not a real airplane.

I don't know which side is telling the truth, of course. I'm not going to defend Chris Roberts in the face of strong evidence of his guilt. But at the same time, I demand real evidence of his guilt before I condemn him. I'm not going to take the FBI's word for it.

We know how things get distorted. Security researchers are notoriously misunderstood. To the average person, what we say is all magic technobabble anyway. They find this witchcraft threatening, so when we say we "could" do something, it's interpreted as a threat that we "would" do something, or even that we "have" done something. Important exculpatory details, like "I hacked a simulation", get lost in all the technobabble.

Likewise, the FBI is notoriously dishonest. Until last year, they forbad audio/visual recording of interviews, preferring instead to take notes. This inshrines any misunderstandings into official record. The FBI has long abused this, such as for threatening people to inform on friends. It is unlikely the FBI had the technical understanding to understand what Chris Roberts said. It's likely they willfully misunderstood him in order to justify a search warrant.

There is a war on researchers. What we do embarrasses the powerful. They will use any means possible to stop us, such as using the DMCA to suppress publication of research, or using the CFAA to imprison researchers. Criminal prosecution is so one sided that it rarely gets that far. Instead, merely the threat of prosecution ruins lives, getting people fired or bankrupted.

When they come for us, the narrative will never be on our side. They will have constructed a story that makes us look very bad indeed. It's scary how easily the FBI convict people in the press. They have great leeway to concoct any story they want. Journalists then report the FBI's allegations as fact. The targets, who need to remain silent lest their words are used against them, can do little to defend themselves. It's like how in the Matt Dehart case, the FBI alleges child pornography. But when you look into the details, it's nothing of the sort. The mere taint of this makes people run from supporting Dehart. Similarly with Chris Roberts, the FBI wove a tale of endangering an airplane, based on no evidence, and everyone ran from him.

We need to stand together on or fall alone. No, this doesn't mean ignoring malfeasance on our side. But it does mean that, absent clear evidence of guilt, that we stand with our fellow researchers. We shouldn't go all Lord of the Flies on the accused, eagerly devouring Piggy because we are so relieved it wasn't us.

P.S. Alex Stamos is awesome, don't let my bitch slapping of him make you believe otherwise.

Those expressing moral outrage probably can't do math

noreply@blogger.com (Robert Graham) — Sat, 16 May 2015 03:35:00 +0000

Many are discussing the FBI document where Chris Roberts ("the airplane hacker") claimed to an FBI agent that at one point, he hacked the plane's controls and caused the plane to climb sideways. The discussion hasn't elevated itself above the level of anti-vaxxers.

It's almost certain that the FBI's account of events is not accurate. The technical details are garbled in the affidavit. The FBI is notorious for hearing what they want to hear from a subject, which is why for years their policy has been to forbid recording devices during interrogations. If they need Roberts to have said "I hacked a plane" in order to get a search warrant, then that's what their notes will say. It's like cops who will yank the collar of a drug sniffing dog in order to "trigger" on drugs so that they have an excuse to search the car.

Also, security researchers are notorious for being misunderstood. Whenever we make innocent statements about what we "could" do, others often interpret this either as a threat or a statement of what we already have done.

Assuming this scenario is true, that Roberts did indeed control the plane briefly, many claim that this is especially reprehensible because it endangered lives. That's the wrong way of thinking about it. Yes, it would be wrong because it means accessing computers without permission, but the "endangered lives" component doesn't necessarily make things worse.

Many operate under the principle that you can't put a price on a human life. That is false, provably so. If you take your children with you to the store, instead of paying the neighbor $10 to babysit them, then you've implicitly put a price on your children's lives. Traffic accidents near the home are the leading cause of death for children. Driving to the store is a vastly more dangerous than leaving the kids at home, so you've priced that danger around $10.

Likewise, society has limited resources. Every dollar spent on airline safety has to come from somewhere, such as from AIDS research. With current spending, society is effectively saying that airline passenger lives are worth more than AIDS victims.

Does pentesting an airplane put passenger lives in danger? Maybe. But then so does leaving airplane vulnerabilities untested, which is the current approach. I don't know which one is worse -- but I do know that your argument is wrong when you claim that endangering planes is unthinkable. It is thinkable, and we should be thinking about it. We should be doing the math to measure the risk, pricing each of the alternatives.

It's like whistleblowers. The intelligence community hides illegal mass surveillance programs from the American public because it would be unthinkable to endanger people's lives. The reality is that the danger from the programs is worse, and when revealed by whistleblowers, nothing bad happens.

The same is true here. Airlines assure us that planes are safe and cannot be hacked -- while simultaneously saying it's too dangerous for us to try hacking them. Both claims cannot be true, so we know something fishy is going on. The only way to pierce this bubble and find out the truth is to do something the airlines don't want, such as whistleblowing or live pentesting.

The systems are built to be reset and manually overridden in-flight. Hacking past the entertainment system to prove one could control the airplane introduces only a tiny danger to the lives of those on-board. Conversely, the current "security through obscurity" stance of the airlines and FAA is an enormous danger. Deliberately crashing a plane just to prove it's possible would of course be unthinkable. But, running a tiny risk of crashing the plane, in order to prove it's possible, probably will harm nobody. If never having a plane crash due to hacking is your goal, then a live test on a plane during flight is a better way of doing this than the current official polices of keeping everything secret. The supposed "unthinkable" option of live pentest is still (probably) less dangerous than the "thinkable" options.

I'm not advocating anyone do it, of course. There are still better options, such as hacking the system once the plane is on the ground. My point is only that it's not an unthinkable danger. Those claiming it is haven't measure the dangers and alternatives.

The same is true of all security research. Those outside the industry believe in security-through-obscurity, that if only they can keep details hidden and pentesters away from computers, then they will be safe. We inside the community believe the opposite, in Kerckhoff's Principle of openness, and that the only trustworthy systems are those which have been thoroughly attacked by pentesters. There is a short term cost of releasing vulns in Adobe Flash, because hackers will use them. But the long term benefit is that this leads to a more secure Flash, and better alternatives like HTML5. If you can't hack planes in-flight, then what you are effectively saying is that our believe in Kerckhoff's Principle is wrong.

Each year, people die (or get permanently damaged) from vaccines. But we do vaccines anyway because we are rational creatures who can do math, and can see that the benefits of vaccines are a million to one times greater than the dangers. We look down on the anti-vaxxers who rely upon "herd immunity" and the fact the rest of us put our children through danger in order to protect their own. We should apply that same rationality to airline safety. If you think pentesting live airplanes is unthinkable, then you should similarly be able to do math and prove it, rather than rely upon irrational moral outrage.

I'm not arguing hacking airplanes mid-flight is a good idea. I'm simply pointing out it's a matter of math, not outrage.

Revolutionaries vs. Lawyers

noreply@blogger.com (Robert Graham) — Fri, 15 May 2015 01:00:00 +0000

I am not a lawyer; I am a revolutionary. I mention this in response to Volokh posts [1, 2] on whether the First Amendment protects filming police. It doesn't -- it's an obvious stretch, and relies upon concepts like a protected "journalist" class who enjoys rights denied to the common person. Instead, the Ninth Amendment, combined with the Declaration of Independence, is what makes filming police a right.

The Ninth Amendment simply says the people have more rights than those enumerated by the Bill of Rights. There are two ways of reading this. Some lawyers take the narrow view, that this doesn't confer any additional rights, but is just a hint on how to read the Constitution. Some take a more expansive view, that there are a vast number of human rights out there, waiting to be discovered. For example, some wanted to use the Ninth Amendment to insist "abortion" was a human right in Roe v. Wade. Generally, lawyers take the narrow view, because the expansive view becomes ultimately unworkable when everything is a potential "right".

I'm not a lawyer, but a revolutionary. For me, rights come not from the Constitution. Bill of Rights, or Supreme Court decision. They come from the Declaration of Independence, the "natural rights" assertion, but also things like the following phrase used to justify the colony's revolution:

...when a long train of abuses and usurpations, pursuing invariably the same Object evinces a design to reduce them [the people] under absolute Despotism, it is their right, it is their duty, to throw off such Government...

The state inevitably strives to protect its privilege and power at the expense of the people. The Bill of Rights exists to check this -- so that we don't need to resort to revolution every few decades. The First Amendment protects free speech not because this is a good thing, but because it's the sort of the thing the state wants to suppress to protect itself.

In this context, therefore, abortion isn't a "right". Abortion neither helps nor harms the despot's power. Whether or not it's a good thing, whether it should be legal, or even whether the constitution should mention abortion, isn't the issue. The only issue here is how it relates to government power.

Thus, we know that "recording police" is a right under the Declaration of Independence. The police want to suppress it, because it challenges their despotism. We've seen this in the last year, as films of police malfeasance has led to numerous protests around the country. If filming the police were illegal in the United States, this would be an usurpation that would justify revolt.

Everyone knows this, so they struggle to fit it within the constitution. In the article above, a judge uses fancy rhetoric to try to shoehorn it into the First Amendment. I suggest they stop resisting the Ninth and use that instead. They don't have to accept an infinite number of "rights" in order to use those clearly described in the Declaration of Independence. The courts should simply say filming police helps us resist despots, and is therefore protected by the Ninth Amendment channeling the Declaration of Independence.

The same sort of argument happens with the Fourth Amendment right to privacy. The current legal climate talks about a reasonable expectation of privacy. This is wrong. The correct reasoning should start with a reasonable expectation of abuse by a despot.

Under current reasoning about privacy, government can collect all phone records, credit card bills, and airline receipts -- without a warrant. That's because since this information is shared with a third party, the company you are doing business with, you don't have a "reasonable expectation of privacy".

Under my argument about the Ninth, this should change. We all know that a despot is likely to abuse these records to maintain their power. Therefore, in order to protect against a despot, the people have the right that this information should be accessible only with a warrant, and that all accesses by the government should be transparent to the public (none of this secret "parallel construction" nonsense).

We all know there is a problem here needing resolution. Cyberspace has put our "personal effects" in the cloud, where third parties have access to them, that we still want to be "private". We struggle with how that third party (like Facebook) might invade that privacy. We struggle with how the government might invade that privacy. It's a substantial enough change that I don't thing precedence guides us, not Katz, not Smith v Maryland. I think the only guidance comes from the founding documents. The current state of affairs means that cyberspace has made personal effects obsolete -- I don't think this is correct.

Lastly, this brings me to crypto backdoors. The government is angry because even if Apple were to help them, they still cannot decrypt your iPhone. The government wants Apple to put in a backdoor, giving the police a "Golden Key" that will decrypt any phone. The government reasonably argues that backdoors would only be used with a search warrant, and thus, government has the authority to enforce backdoors. The average citizen deserves the protection of the law against criminals who would use crypto to hide their evil deeds from the police. When an evil person has kidnapped, raped, and murdered your daughter, all data from their encrypted phone should be available to the police in order to convict them.

But here's the thing. In the modern, interconnected world, we can only organize a revolution against our despotic government if we can send backdoor-free messages among ourselves. This is unlikely to be much of a concern in the United States, of course, but it's a concern throughout the rest of the world, like Russia and China. The Arab Spring was a powerful demonstration of how modern technology mobilized the populace to force regime change. Despots with crypto backdoors would be able to prevent such things.

I use Russia/China here, but I shouldn't have to. Many argue that since America is free, and the government under the control of the people, that we operate under different rules than those other despotic countries. The Snowden revelations prove this wrong. Snowden revealed a secret, illegal, mass surveillance program that had been operating for six years under the auspices of all three branches (executive, legislative, judicial) and both Parties (Republican and Democrat). Thus, it is false that our government can be trusted with despotic powers. Instead, our government can only be trusted because we deny it despotic powers.

QED: the people have the right to backdoor-free crypto.

I write this because I often hang out with lawyers. They have a masterful command of all the legal decisions and precedent, such as the Katz decision on privacy. It's not that I disrespect their vast knowledge on the subject, or deny their reasoning is solid. It's that I just don't care. I'm a revolutionary. Cyberspace, 9/11, and the war on drugs has led to an alarming number of intolerable despotic usurpations. If you lawyer people believe nothing in the Constitution or Bill of Rights can prevent this, then it's our right, even our duty, to throw off the current system and institute one that can.