Ben Laurie - SSL MitM Attack, Part 2
A lot can happen in a day. Yesterday the news broke that SSL was compromised. We immediately (OK, it took about 10 hours) released a new version of OpenSSL, 0.9.8l, which mitigates the problem by completely disabling renegotiation. Obviously this will break some sites, and so is not a full fix, so the next step is to implement Eric Rescorla’s TLS extension. However, before I get on with that, it seems I have a few questions to answer.
Firstly, I must thank the anonymous poster who said “OpenSSL is written by monkeys”. But dude, you should’ve included the link. I’ve been meaning to link to that for ages. Well, days.
Secondly, as Marsh said, there is a better answer for people who need renegotiation. This is the extension mentioned above. It won’t work unless clients also implement that, but we are working on that, too (and clearly any client that uses OpenSSL will get it for free as soon as I get the next version out).
To the bloke who asked about ISA and OWA: I have no idea what either of those are.
Does this affect SGC (Server-Gated Cryptography)? I don’t actually know. I think it does, because I think SGC uses renegotiation, but I am not sure. If anyone knows, comment!
To the “but this is just XSRF” (Cross-site request forgery) guy:
- XSRF does not give the attacker control over headers.
- Your attack didn’t work on me: I didn’t click the link.
- HTTP is not the only protocol that uses SSL.
Though the fact that this attack doesn’t actually make HTTP much worse is a pretty damning indictment of HTTP (and HTML)!
Will this patch break session resumption? No – and nor will the 0.9.8l release, which does the same thing more elaborately and correctly.
Finally, even once we’ve implement the extension it seems to me this is not really the true fix – really applications should be aware of renegotiations and not carry trust across their boundaries. But more on that later, I’ve got code to write.
Ben Laurie - Another Protocol Bites The Dust
For the last 6 weeks or so, a bunch of us have been working on a really serious issue in SSL. In short, a man-in-the-middle can use SSL renegotiation to inject an arbitrary prefix into any SSL session, undetected by either end.
To make matters even worse, through a piece of (in retrospect) incredibly bad design, HTTP servers will, under some circumstances, replay that arbitrary prefix in a new authentication context. For example, this is what happens if you configure Apache to require client certificates for one directory but not another. Once it emerges that your request is for a protected directory, a renegotiation will occur to obtain the appropriate client certificate, and then the original request (i.e. the stuff from the bad guy) gets replayed as if it had been authenticated by the client certificate. But it hasn’t.
Not that the picture is all rosy even when client certificates are not involved. Consider the attacker sending an HTTP request of his choosing, ending with the unterminated line “X-Swallow-This: “. That header will then swallow the real request sent by the real user, and will cause any headers from the real user (including, say, authentication cookies) to be appended to the evil request.
It’s obviously going to take a little while for the world to patch this – and since the news is spreading like wildfire I’ve put up a patch to OpenSSL that bans all renegotiation. I’m sure an official release will follow very shortly.
Note that the patch is against the head of the OpenSSL 0.9.8 development tree (that is, it is against 0.9.8l-dev). You may have to do a little work to patch against other versions. And if you intend to deploy this patch permanently, please change at least the textual version of the version number, which you can find in crypto/opensslv.h. Also note that if you need renegotiation for your site to work, I have no solution for you, other than you redesign your site. Sorry.
ShmooCon News - Reserved Tickets
An overwhelming majority of folks who were able to reserve tickets yesterday have already come back to purchase - thank you! The rest of you have until Noon EST tomorrow (Tuesday) to redeem your reservation codes. After that, those tickets will be released and added into the numbers for the December sales date.Also, yesterday was the early submission deadline for the CFP. We received a record 86 talks by midnight. We will be choosing a small number of talks from submissions received up to this point. If you're not selected this round, don't worry - you're still in the running. Haven't submitted yet? There's still time. You still have until the 20th to turn something in.
ShmooCon News - And so this stays at the top
Reposted:Once you get your ticket, think about getting a room. Already booked a room? We know some of you have. Call back and get it moved into the ShmooCon Block.
Rooms at the Wardman Park Marriott will run $179/night for a single/double. Enter or reference code OCTOCTA when making your reservation to get this rate.
ShmooCon News - Round One Sold Out
In record time, at least for November ticket sales. Next round of tickets will be up for grabs on December 1st.ShmooCon News - Link to Ticket Sales
It really was there folks...at the bottom of the page. Yes, we should have top posted and made it easier on all of you. It was an inadvertent overlook on our part and we're sorry.That being said, it is a hacker con. Maybe next time we'll put the link in the middle. ;)
Also, there are still a small number of tickets in the system that age out as people don't complete the reservation process. You can continue to try to get a reservation code, but type fast as you'll be racing with others to try and get the same tickets. We'll notify you here when tickets are actually sold out.
One more mea culpa. We're aware we need to change the text that pops up when all tickets are in the reserve process and, at that moment, unavailable. While that won't really change anything, we feel it should be more informative than simply "come back in December."
ShmooCon News - Ticket Sales
Are live...get 'em while they're hot.ShmooCon News - Hotel Code
Once you get your ticket, think about getting a room. Already booked a room? We know some of you have. Call back and get it moved into the ShmooCon Block.Rooms at the Wardman Park Marriott will run $179/night for a single/double. Enter or reference code OCTOCTA when making your reservation to get this rate.
ShmooCon News - Important information regarding ticket sales
Folks, it's less than 24 hours until the first round of ticket sales. We've implemented some major changes this year and it's important that you understand the process prior to the rush tomorrow. Please visit and read the information on the registration page followed by the information on the cart page.ShmooCon News - Contest/Event updates
Just keeping you in the know - updated information has been posted to the following:ShmooCon Labs
Hacker Arcade
TF2 Lan Party
Hack-or-Halo
ShmooCon News - Dates to Remember
Call for Papers:- Nov. 1 - Papers for first round early consideration due
- Nov. 20 - CFP closes
- Nov. 1 - First round of sales is scheduled to go live at noon EST. There's a pesky thing involving saving daylight happening that day, so be aware.
Now is the time to contact us if you or your company is interested in sponsoring ShmooCon. Thanks again to those of you who have already contacted us.
Ben Laurie - Just How Bad are IDNs?
IDN, in case you didn’t know, stands for “Internationalised Domain Name”. Or something like that. In short it is the highly dubious idea that you should be able to define domain names in any script you like. I thought I’d written before about how this leads to homograph attacks, but I can’t find the post. Perhaps it was so long ago it was before I was blogging?
Anyway, this problem didn’t go away and I was recently pointed at this rather fine slide deck explaining all the problems with IDNs. Well worth a read if you want to see why IDN should be eradicated.
Unfortunately the uselessness that is ICANN thinks that IDNs are politically super-important, and are all tied up with control of the root. So the hell with security, making sure DNS stays in the hands of the US, err, I mean ICANN, is far more important.
Ben Laurie - “We Used To Be More Secure”
A couple of days ago I went to my bank to do a CHAPS transfer for a great deal of money. Buy-a-house kind of money. I didn’t want to have any problems when I got there, so I called them to find out what I should take. Of course, I can’t talk to my bank (Barclays) anymore, so I got a call centre in India. They told me I’d need ID and a utility bill – this one amuses me since these days no-one gets utility bills: it’s all electronic. And anyway, all my utilities are in my wife’s name. I called them again a while later to try to make an appointment (I can’t, apparently) and this time they told me two forms of ID and no mention of the utility bill. So, I headed off to the bank with passport, driving licence and a TV licence (hey, TV is a utility, isn’t it?) in hand.
When I got there we sat down with a bank employee who asked me for my cash card. He stuck it into a PINsentry and asked me to type my PIN. On that evidence alone, we proceeded to transfer enough money to fund a small country. I find this a little scary. Anyway, when I reviewed the documentation, which I had to sign, it had a little box about ID verification, into which he’d typed “PIN xxxx + SRS” – “xxxx” was (part of?) the code from the PINsentry. I asked him what “SRS” meant and he explained it meant he’d checked my signature. In fact, he hadn’t, but he proceeded to do so at that point, commenting that he already knew what my signature looked like, presumably to explain away why he hadn’t done the check before…
Anyway, at this point my wife mentioned that we were rather expecting them to check ID and stuff, to which he responded in a way I feel sure was not authorised by the bank: “well, we used to be more secure but now the bank believes that PINs are the highest level of verification”. I explained to him why I disagreed with the bank. He didn’t argue with me.
Oh yes, the signature check? He wasn’t even in the room when I signed. For all he knew I carefully copied it from a crib sheet. So, all that’s standing between me and complete emptying of my bank account is my PIN. But hey, the only way anyone other than me could know that is if I told them, isn’t it? So it would serve me right, obviously.
Ben Laurie - seL4
In response to my not-so-recent rants on formal methods I was told to go and read up on seL4.
I’m glad I did, it’s really quite fascinating. To set the stage a little, L4 is a microkernel architecture with various implementations. Last time I looked it was mostly used by academics and was not very mature, but it seems to have moved on – for example, L4Linux is a version of it with Linux hosted on top, providing benefits like driver isolation.
seL4 is a variant of L4 that is based around a capability architecture (I confess I don’t know enough about L4 to understand how one variant can be capability-based without them all being, pointers welcome), which would be interesting in itself. But far more interesting than that – seL4 has been formally verified.
The approach is somewhat convoluted. First of all, they write a prototype of the kernel in Haskell, including all of the low-level hardware control (note that because this is a microkernel, this does not include most of the device drivers). This prototype is then linked to an emulator derived from QEMU, which allows user code to run in a binary compatible simulated environment. When user code calls the kernel, the emulator instead branches into the Haskell code, runs it, and then returns to the user code. This in itself would be pretty cool, but there’s more.
Next, there’s the abstract specification of the kernel. This describes the binary layout of arguments to system calls, the effect of each system call and of interrupts and traps (e.g. page faults), without describing the implementation. From the Haskell, they generate what they call an executable specification. This is done by an automatic translation from the subset of Haskell they use into a theorem proving language. They then prove that the executable specification is a refinement of the abstract specification. Which means, informally, that everything that is true of the abstract specification is also true of the executable specification. In other words, the executable specification implements what the abstract specification specifies.
However, we’re not there yet. The real kernel is written in C, by hand. This is required if you want a kernel that is appropriately optimised – automatic generation of C code from the Haskell would be possible, but unlikely to run fast. The C implementation is then verified by automatically translating it into the theorem proving language once more, and showing that this is a refinement of the executable specification. This automatic translation is another remarkable achievement, though they do not claim to be able to translate arbitrary C: it must be written to conform with some rules – for example, no passing addresses of local variables to functions. Clearly these rules are not too onerous: they manged to write a whole kernel that conformed to them.
Note that this does not rely on the correctness of the Haskell code! Since that is only used to generate the executable specification, which stands between the abstract specification and the C implementation, all we really care about is the correctness of the executable specification, which is proved. Although this strongly implies that the Haskell code is correct, it is in no way relied upon.
So, the end result of all this is a number of fun things.
- Most importantly, a kernel written in C that has a formal proof of correctness.
- A Haskell prototyping environment for the kernel (I guess I’d like this part even more if I could figure out how to learn Haskell without sitting next to a Haskell guru).
- The tools needed to adopt this approach for other code.
- A nice write-up of the whole thing.
- Detailed costs for doing this kind of proof, and the costs of making changes. See the paper for more, but the big picture is the whole thing took 20 man-years, of which 9 were development of (presumably reusable) tools and 11 were the formal seL4 proof itself.
Ben Laurie - AES Explained
AES in cartoon form – a really nice explanation. Example code to go with it, too.
Ben Laurie - FreeBSD Chromium, Part 2
Over the weekend I got chromium building and linking on FreeBSD. It doesn’t run for long, but this seems like a major milestone! I also got commit and submitted the first round of patches, by the way.
However, I discovered in the process that I wasn’t building with debugging info. Now that I am, I can’t link on my FreeBSD machine, because ld runs out of RAM. If someone out there has a nice big (and fast would be nice, it takes a really long time to build) box that I could ssh or, even better, VNC or NX into, now’s the time to let me know! Mine is dying with a dataseg limit of 716800 – which I could increase, I guess, but its a pretty old box, so probably not by much before I get into thrashing…
Anyway, for anyone who wants to try, the primary patch is here:
http://codereview.chromium.org/199105
There are a couple of other patches referenced there (for V8 and WebCore – they’re tiny so I hope I can push them upstream soon), and you still need to build as specified here.
ShmooCon News - ShmooCon 2010 - Call for Papers
That's right - ShmooCon's CFP is finally out and we can't wait to hear from you.We're slowly updating the rest of the website as well. Major changes will be announced here in the news section but here's a quick run down of what's to come:
Ticket Sales - As in previous years there will be three sales dates: Nov 1, Dec 1 and Jan 1
Contests - Look for some changes here (not posted yet). There's always something new and exciting.
Sponsorship Opportunities - Lots of inquiries already, thank you! That info should be up this weekend.
Ben Laurie - Why Open Is Better Than Proprietary?
First of all watch this fascinating TED talk by Dan Pink. Watch it all the way to the end: I promise it is worth it. Then consider this…
I’ve long argued that open source provides a clear economic benefit (and hence incentive). However, I’ve always had a bit of a nagging feeling that there’s more to it than that but have never been satisfied by sociologists’ lame attempts at explanations. Perhaps Dan Pink’s observations fill in that missing piece. Autonomy, mastery and purpose – open source development provides all three of these to developers, in copious quantities.
- Autonomy: you choose what you work on, when you work on it, and how you work on it.
- Mastery: putting all your work out there in public view gets you great feedback – and many studies have shown that people don’t improve without external feedback. Furthermore, seeing what other people have done is a fantastic learning resource.
- Purpose: most open source projects have a purpose that goes beyond the mere development of the software – for example, Apache exists to serve up web pages better than anything else does – and the higher purpose is greater democratisation and freedom for everyone. not just the developers. OpenSSL exists to protect people from invasions of the privacy and theft of their data. It’s not just a geek toy, it’s critical infrastructure for the new world we are moving into.
It seems that economics is not the only thing that makes open source better.
Ben Laurie - Kim Cameron Explains Why Hoarding Is Not Hoarding
I’ve been meaning for some time to point out that it’s been well over a year since Microsoft bought Credentica and still no sign of any chance for anyone to use it. Kim Cameron has just provided me with an appropriate opportunity.
Apparently the lack of action is because Microsoft need to get a head start on implementation. Because if they haven’t got it all implemented, they can’t figure out the appropriate weaseling on the licence to make sure they keep a hold of it while appearing to be open.
if you don’t know what your standards and implementations might look like, you can’t define the intellectual property requirements.
Surely the requirements are pretty simple, if your goal is to not hoard? You just let everyone use it however they want. But clearly this is not what Microsoft have in mind. They want it “freely” used on their terms. Not yours.
Ben Laurie - Porting Chromium to FreeBSD
In my copious spare time, I’ve started work on a FreeBSD port of Chromium. So far it doesn’t even build, but I’ve identified a few problem areas people might like to pitch in on.
- NSS port: the FreeBSD NSS port needs to be upgraded to at least NSS 3.12. Ideally to the latest version because it fixes some security holes.
- Sound: mostly whatever Linux does it likely to be the right thing for FreeBSD, too, so much of the porting work at this stage is pretty mechanical. But sound isn’t – the Linux port uses ALSA, which FreeBSD has no truck with. I am informed that the right thing to use on FreeBSD is OSS. But someone needs to do that.
- Build farm: building this sucker is slow. I wouldn’t mind having access to a nice big build farm.
So far none of the work has been committed, but I am optimistic that some will be soon. In the meantime, you’ll be needing some patches.
- http://codereview.chromium.org/171086 fixes a bug in gyp, and stops it from assuming we’re running on Linux if we want to use make, which we do.
- http://codereview.chromium.org/180037 is one chunk of porting.
- http://codereview.chromium.org/172032 is another.
There’ll probably be another patch soon – I’m going through the rest of the code right now getting the parts that don’t need NSS or ALSA building.
In order to build this lot, you’ll need to configure like this:
cd src && GYP_GENERATORS=make python tools/gyp/gyp_chromium -D 'OS=freebsd' -D 'use_system_libxml=1' build/all.gyp
and build using gmake:
cd src && gmake chrome
Right now anything that fails on NSS or ALSA I’m just manually removing from the .mk files.
You’ll also need a bunch of ports installed, here’s what my notes currently say
Python >= 2.4 (lang/python24, lang/python25, lang/python26, lang/python30)
Perl >= 5.x (lang/perl5.6, lang/perl5.8, lang/perl5.10)
gcc/g++ >= 4.2 (lang/gcc42, lang/gcc43, lang/gcc44, lang/gcc45)
g++-multilib >=4.2 (?)
bison >= 2.3 (devel/bison == 2.4.1)
flex >= 2.5.34 (base system: 2.5.4 - oops?)
gperf >= 3.0.3 (lang/gperf - NB: base system has /usr/bin/gperf == 2.7.2, port installs /usr/local/bin/gperf)
pkg-config >= 0.20 (devel/pkg-config == 0.23)
libnss3-dev >= 3.12 (security/nss == 3.11.9_2 - hand install?)
libgconf2-dev (devel/gconf2)
libglib2.0-dev (devel/glib20)
libgtk2.0-dev (x11-toolkits/gtk20)
libnspr4-0d >= 4.7.1+1.9-0ubuntu0.8.04.5 (ubuntu0.8.04.1 causes duplicate dtoa references) (devel/nspr?)
libnspr4-dev >= 4.7.1+1.9-0ubuntu0.8.04.5 (devel/nspr)
msttcorefonts (Microsoft fonts)
freetype-dev (print/freetype)
libcairo2-dev (no port!)
libdbus-1-dev (devel/dbus)
Get in touch if you want to help. Or join the chromium-dev mailing list and pitch in.
Ben Laurie - I Hope You’re Not In A Hurry
The aforementioned Felix just pointed me at this superb comic art, by someone who is learning to how to make a comic by making a comic. In my opinion, this guy is a graphic novel god.
He thinks it might take him some time. If it’s going to look this good, I can wait.
Ben Laurie - Japanese Curry
Last night I cooked an absolutely delicious (if I say so myself) Japanese curry for my guests – no recipe, because just copying out somebody else’s seems uncool, though I believe it is technically permitted. You can, however, find the recipe in Madhur Jaffrey’s Ultimate Curry Bible
I had no idea the Japanese even ate curry until I came across this recipe but anyway, some comments…
Firstly, it was fantastically quick to cook, 10 minutes from start to end – far, far faster than any other curry I know how to make. It did take a while to prepare, mostly because slicing enough beef for eight people into 1/8 inch thick pieces takes quite some time. Even with a ceramic knife.
Secondly, its not really a Japanese curry, it’s Madhur’s guess at how to cook one without the specialist Japanese ingredients.
Thirdly, I served it with plain boiled rice and hot and sour aubergine (my older son, Felix, cooked it), which comes from another masterpiece of Madhur Jaffrey’s: “World Vegetarian Cookbook”
Fourthly, Felix and I were of the opinion that just stir-frying the marinated meat would make a pretty fine dish, too. I haven’t tried it yet, but I intend to.
Fifthly, my younger son informs me that this recipe is highly unauthentic because it contains garlic, which is practically banned in Japan, he claims. I don’t care, it was lovely.
Finally, I used double cream instead of whipping cream, since that’s what I had. Seemed to work just fine.
Ben Laurie - Useful Security
A while back, I had a bash at formal methods. Reasonably enough, some people had a bash back. I feel I should respond.
Michael asked “what about Tokeneer?”
The description on that page makes some great points for me. Firstly, and I think most importantly
At each stage in the process verification activities were undertaken to ensure that no errors had been introduced. These activities included review and semi-formal verification techniques applicable to the entities being developed.
In other words: “we can’t actually apply formal methods to the entire process, so we did some ad hoc stuff, too”. Core to this problem is that you have to somehow describe what it is you are trying to do. In order to disguise the problem, formal methods folk like to call this a specification – but when you get down to it, it’s a program. Which can have bugs in it. Which you can only diagnose by thinking about it and testing.
Next, from the overview, section 5
Since release 7.4, SPARK has included an “accept” annotation that can be used to justify expected warnings and errors. These annotations have been added as appropriate.
In other words, verification fails, but these failures are “justified”. Hmmm.
Again from the overview (section 5.3) even after formal verification a bug was found, which was an elementary integer overflow bug. I would hope any competent programmer would have spotted this as they were writing the code, but apparently it was beyond all this expensive and painful infrastructure.
Finally (there’s more, but I have other things to write about, so I’ll stop here), again from the summary
# lines of code: 9939
# total effort (days): 260
Wow. That’s a lot of days for not very much code.
Toby asked “how would you feel about a proposal that asked for a range of standard software modules whose design had been subjected to formal analysis, at some semi-useful and reasonable level of abstraction, of some of its key functional/security properties?”
I guess I feel about this rather as Gandhi felt about Western civilisation: it would be a good idea.
More positively, I imagine there are actually some modules that are sufficiently small in scope that one could convince oneself that the specification was actually correct, and maybe even prove that the implementation matched the specification. For example, things like arrays, sets and maps might be implementable correctly. Where it all falls apart, in my view, is when you try to make a system that actually does something useful: then you get into the realm where debugging the specification is the hard problem.
Ian Brown asked “do you think a formally verified microkernel that enforces security controls within an OS is achievable/desirable?”
I think this actually might be achievable, and perhaps even desirable. But I’m not so sure it would be truly useful. A microkernel architecture inherently punts on all the interesting security questions and simply enforces whatever incorrect decisions you have made outside the kernel. So, you are still left with all the real-world security problems, but at least you have a place to stand when you claim you are enforcing whatever security properties you think your code implements (that is, you can discount the microkernel as a source of problems and only have to worry about the other 99% of the code).
I also strongly suspect that a team of skilled engineers could carefully write a secure microkernel that was just as robust without any need for formal verification. More quickly and with less swearing.
Finally, Anil Madhavapeddy writes “Modern type systems spring from a solid formal footing, and mainstream languages are adopting functional features”.
This is a great point, and I actually agree. I’m a big fan of type safety, as anyone who’s seen some of the hoops I jumped through in both the Apache module system and more recently in OpenSSL will know. I really like things to break at compile-time rather than run-time if at all possible, and type safety is one way to achieve this (this is one reason I prefer C++ to C, despite its many defects). I guess functional languages also have interesting properties from that point of view but I feel like I understand them less. I really must learn Erlang (or Haskell, I suppose, but I’ve tried and failed a few times already – it seems there are no good tutorials out there).
Anil also says “Even for C, static analysis is increasingly used to track down bugs (with products like Coverity which are very effective these days)”.
Sorry, but no. I thought for quite a while that there was a future in static analysis. But the more I am exposed to it, the less I think it is true. The false positive rate is still fantastically high, even in Coverity, which is probably the best system I’ve played with, and even correct hits tend to be on the “academically correct but not actually useful” side.
I do continue to suspect that static analysis combined with annotation might be useful, though (e.g. as in Deputy). But really, this is just trying to bolt on strong typing to weakly typed languages and isn’t truly static analysis is we hoped it might be.
Finally, he says “If things continue like they have been, then we’ll continue to cherry pick the practical developments from the formal methods community into mainstream languages, and reap the benefits.”
I certainly hope so, and I don’t want to discourage further research into formal methods. I just object to the notion that they are practical to the extent that we should be trying to use them wholesale to build real systems. They really aren’t.
I was intending to also talk a bit about things I think actually are useful for security, but I think I’ll leave that for a later post.
Ben Laurie - Ceramic Knife
I’ve been lusting after a ceramic knife for ages now. I finally got around to buying a Kyocera 16cm knife
Ben Laurie - Rigour
I know this is ancient history now, but I was busy, OK?
A while back, Schneier said something that really annoyed me
Commenting on Google’s claim that Chrome was designed to be virus-free, I said:
Bruce Schneier, the chief security technology officer at BT, scoffed at Google’s promise. “It’s an idiotic claim,” Schneier wrote in an e-mail. “It was mathematically proved decades ago that it is impossible — not an engineering impossibility, not technologically impossible, but the 2+2=3 kind of impossible — to create an operating system that is immune to viruses.”
What I was referring to, although I couldn’t think of his name at the time, was Fred Cohen’s 1986 Ph.D. thesis where he proved that it was impossible to create a virus-checking program that was perfect. That is, it is always possible to write a virus that any virus-checking program will not detect.
Now, if what you’re interested in is PR, then it seems you can get away with these kinds of statements; certainly I have not seen a single public challenge. But if you care about rigour, you have to do rather better, since Schneier’s claim is demonstrably wrong. Why? Well, here goes … Cohen’s proof relies on computer science’s only trick: diagonalisation[1]. Basically, I assume that I have some perfect virus detector, V. If I give V a program, p, it returns true or false, depending on whether p is a virus or not. Let’s be charitable and assume that we can define what a virus is well enough to allow such a program to exist. Let’s also define what is meant by “perfect” - by that we mean that any program that exhibits virus behaviour will be classified as a virus and any that does not will be classified as not a virus.
Then Cohen says: fine, write a program, c like this:
if(V(c))
do_nothing();
else
be_evil();
Now, if V(c) returns true (i.e. c is a virus), then c does nothing, and therefore V is wrong. Similarly, if it returns false, then c behaves evilly, and once more V is wrong. QED, no perfect virus checker is possible. So far, we are in agreement.
Can we go from this to “it is always possible to write a virus that any virus-checking program will not detect”. No, because the proof only talks about perfect virus-checking programs. If the virus checker is allowed to be wrong sometimes, then the proof no longer works. In particular, if the virus checker can return false positives (i.e. claim that innocent programs are viruses) but is not allowed to return false negatives, then we can, indeed, have a virus checker that would keep our system free of viruses. Why? Because the virus checker will always detect a virus, by definition, but the diagonalisation proof no longer works - in particular, the case where V(c) is true no longer leads to a contradiction.
If we want to go a little further and show that such a program can, in fact, exist, we can actually do that quite easily. For example, consider the program V that always returns true: this would prevent any programs at all from running, so our OS wouldn’t be all that useful, but it would be virus-free. Less frivolously, we could have a list of non-virus programs, and V could return false for any program in the list and true for all others. Even less frivolously, it is possible to imagine an analysis that’s thorough enough for some restricted set of cases to permit reasonably general programs to pass the test without allowing any viruses (obviously we would also disallow many perfectly innocent programs, too), but at this point we’d have to define “virus” to drill down into what that analysis might be - but it could, for example, require that the program be written in some restricted, easily-analyzed language, and avoid constructs that are hard to deal with.
So, sorrry, Schneier. It has not been shown that it is impossible, in the 2 + 2 = 3 sense, to write a virus-free OS. Indeed, it has been shown that it is, in fact, possible - though I would certainly agree that it is an open question how hard it would be to create an OS that’s both useful and virus-free.
[1] Don’t get me wrong; it’s a good trick.
ShmooCon News - ShmooCon 2010 Dates Announced
The Shmoo Group is pleased to announce that ShmooCon 2010 will be held February 5-7 at the Wardman Park Marriott in Washington DC. Website updates to follow. CFP will be released by the end of August. Look forward to seeing you at ShmooCon VI.Ben Laurie - ID Cards: Catch 22?
Apparently, ID cards will not be compulsory after all. Also…
Mr Johnson even admitted the suggestion the cards would help combat terrorism was exaggerated as he accepted the Government should never have allowed “the perception to go around that they were a panacea for terrorism”.
No, really? Anyway, the thing that amuses me is this
It will remain compulsory for foreign nationals staying the UK long term to have an ID cards but Britons will only have one now if they request it.
OK, so when I get stopped in the street, how do I prove that I am not a foreign national staying long term?
Ben Laurie - More Security Pie In The Sky
The Institute for Public Policy Research have a report called “A national security strategy for the UK”. They want money for it, though, so you might prefer the executive summary, even if you aren’t an executive.
Recommendation 60: The Government should also approach the European Commission and the incoming Swedish Presidency to sponsor a programme for the creation of a range of secure and reliable standard software modules (such as simple operating systems, database management systems and graphical user interfaces). These modules should be developed using formal methods and be made available free of charge through an open source licence to encourage their widespread use.
I’m with them on a range of secure and reliable standard software modules. I’m with them on the free/open source front. I’m even mostly with them on their example modules, though I would say that a secure GUI is less of a software engineering problem and more of an HCI problem. But formal methods? We have essentially zero examples of useful systems that have been shown to be secure using formal methods, so why make this recommendation? Are these things written entirely by people looking for funding? Clearly they’re not written by people who want to solve the problem, or they’d make suggestions that might actually lead to a solution.
Ben Laurie - Phormlessness
BT have canned Phorm. I don’t really have anything to add to that, except … yay!
Ben Laurie - Who Pwns The Internet? (Take Two, Part Two)
I actually got these done over the weekend, but I’ve been kinda busy. After taking a more, ahem, principled approach, France seems less dramatic
but still pretty impressive. If you take a close look you’ll see I’ve also had a crack at adding the AS’ owner as well (not 100% reliable, if anyone knows how, let me know!). The UK depends on one less AS than before
and I can do Fiji
I still can’t do the world, though - but now the problem is that dot chokes on the graph.
Ben Laurie - Who Pwns The Internet? (Take 2)
Another interesting way to pwn the Internet is to control the routing of packets to critical nameservers. In practice, Internet routing is done by ASes (Autonomous Systems). If an AS wants to pwn a nameserver on a network it controls, it is a trivial matter: it just redirects the packets to its own nameserver. I’d draw you a picture, but I’m sure Matasano Chargen will do it prettier.
So. I thought it would be instructive to determine which ASes had control over which domains. More fun with dot.
The picture is no longer quite so rosy for the UK, but still, not bad, all things considered.
But France. I don’t know what to say about France. France is surreal. I’ve linked through to a much bigger version because, well, you’ve got to lose yourself in the spiderwebs. The SVG is here, though.
As for Fiji, I’d love to show you Fiji, but the way I’m doing it doesn’t work for Fiji right now. And hence, obviously, not for the whole world, either. Coming soon, I hope.
Ben Laurie - Who Pwns The Internet?
Update: Ben Hyde suggested I should use the (undocumented) “concentrate” option to dot, which certainly tidies up the graphs. So I did.
A remark on the IETF DNS Working Group’s mailing list got me thinking.
Suppose I were the owner of nordu.net (to pick an example at random), then I could take control of sunet.se, for about 25% of Internet users, since one of their four nameservers is server.nordu.net. Similarly, I could then take control of ripe.net for 25% of those 25% (via sunic.sunet.se). One in seven of those guys could fall victim to my ownership of nic.fr via ns-sec.ripe.net, and from there I have complete control of fr (that is, France) - ok, by now, for only a bit under 1% of the Internet, but even so, that’s kinda worrying, don’t you think? And obviously if I own sunet.se then it would be more like 3.5%…
On the other hand, uk does not suffer from this problem: it depends only on nic.uk. Which seems like a much better idea. Anyway, I got to wondering just how bad this problem actually is, which led to me having more fun with dot. So, for a taster, here’s France’s dependencies…
And here’s the UK’s
And here’s Fiji (I include this for Jasvir, who is getting married there soon, and ought to know the terrible risk he’s taking)
And all the top level domains put together
So that one is pretty but a bit hard to digest. Obviously the main news is that there are a lot of domains which could interfere with one or more TLDs!
Another way to think about this is to wonder who could pwn the most TLDs? Well, the answer (after the root, of course) is that nstld.com, gtld-servers.net, com and net come in equal first with 228 TLDs pwnable. Next up is Affilias, through a variety of domains, including org and info, able to control 187 TLDs. After that comes se (Sweden) with 158 and nordu.net, sunet.se, chalmers.se, kth.se, uninett.no, uu.se, edu, no, norid.no, lth.se and uit.no, all able to have a go at 157 TLDs.
Food for thought. Especially if you’re thinking about DNSSEC.
Ben Laurie - Ignorance Transfer Network
SSDSIG recognises that some commonly used languages (e.g. C, php etc.) allow, or even encourage, programming practices that introduce security vulnerabilities. Accepting that in time market forces may encourage the adoption of safer alternatives some members feel that the process needs to be accelerated. The reasons for the continued use of ‘unsafe’ ‘languages and the near-term feasibility of alternatives for commercial systems of modest criticality are complex and ill-understood. This also applies to the slow uptake of more formal methods Further data on this is required.
This is a gem from “Secure Software Development - a White Paper: Software Security Failures: who should correct them and how” by Bill Whyte and John Harrison, from the Cyber Security Ignorance (Knowledge, shurely? Ed) Transfer Network, presumably at the taxpayer’s expense. I hear through the grapevine that they’re planning to spend more of our money to set up a “Secure Software Development Panel” to deliberate on the deep thinking exemplified above. Awesome.
So, what’s wrong with that statement? Firstly, I think we’ve got past the idea that there’s something extra special about buffer overflows as a security issue. Yes, there are many languages that prevent them completely (e.g. PHP, amusingly), but they don’t magically produce secure programs either. Indeed, pretty much all languages used for web development are “safe” in this respect, and yet the web is a cesspit of security problems, so how did that help?
Secondly, the claim that the “reasons are … complex and poorly understood” is a great one to make if you want to spend your life wasting your time on government money, but, well, not exactly true. C is widely used because it is fast, portable, can do anything and has a vast amount of software already written in it that is otherwise difficult to get at. Which is, of course, why PHP is widely used: because it’s one way for the less capable programmer to get at all that C out there. As for “near-term feasibility of alternatives”, well, name an alternative and I’m pretty sure anyone knowledgeable in the field could give you a thorough rundown on its near-term feasibility in an hour or so.
Thirdly, talking about “unsafe” languages implies that there might be “safe” ones. Which is nonsense.
Fourthly, formal methods. Really? The reason there’s slow uptake is because they don’t work. Get with the program, guys!
Ben Laurie - Wave Trust Patterns
Ben Adida says nice things about Google Wave. But I have to differ with
… follows the same trust patterns as email …
Wave most definitely does not follow the same trust patterns as email, that is something we have explicitly tried to improve upon, In particular, the crypto we use in the federation protocol ensures that the origin of all content is known and that the relaying server did not cheat by omitting or re-ordering messages.
I should note, before anyone gets excited about privacy, that the protocol is a server-to-server protocol and so does not identify you any more than your email address does. You have to trust your server not to lie to you, though - and that is similar to email. I run my own mail server. Just saying.
I should also note that, as always, this is my personal blog, not Google’s.
Ben Laurie - Google Wave Federation
Today Google announced Google Wave. I’m not going to talk about Wave itself, just search for it and get a ton of articles. Suffice it to say that it is awesome.
What I want to mention is the Wave Federation Protocol, and in particular, General Verifiable Federation, which is the part my talented colleague Lea Kissner and I worked on. I know I’m a crypto geek, but I think this protocol is pretty interesting, with applications wider than just Google Wave, since it creates a platform for building federated messaging systems in which you do not trust intermediaries.
Lea and I welcome feedback on the protocol, which we are sure is full of mistakes right now, as we were in a bit of a rush to hit today’s deadline…
(And for those friends who are probably wondering now if this is why I went to Australia earlier this year, the answer is, unsurprisingly: yes).
Ben Laurie - ECMAScript 5
When I started working on Caja I had not really plumbed the depths of Javascript (or, as it is more correctly called, ECMAScript 3) and I was very surprised to learn how powerful it actually is. I was also pretty startled by some of the nasty gotchas lurking for the unwary (or even wary) programmer (had I known, perhaps I would never had tried to get Caja off the ground!).
For some time now, the ECMAScript committee has been working on a new version of Javascript which fixes many of these problems without breaking all the existing Javascript that is out there. This seems to me a remarkable achievement; Mark Miller, Mike Samuel (both members of the Caja team) and Waldemar Horwat gave a very interesting talk about these gotchas and how the ES5 spec manages to wriggle around them. I recommend it highly. Slides are available for those who don’t want to sit through the presentation, though I would say it is worth the effort.
Ben Laurie - So You Think Linux is Secure
If you ignore the cyberannoying cybertrend towards cyberusing “cyber” as a cyberprefix for everything, then you’ll notice that our man in DC is lumping Linux and Windows in the same attackable boat.
I guess we should also ignore the fact that he’s commenting on Kylin, which is derived from FreeBSD, which is, pretty much, UNIX - though I am told it doesn’t licence the UNIX trademark, unlike, say, MacOS.
Ben Laurie - Why Privacy Will Always Lose
In social networks, that is.
I hear a lot about how various social networks have privacy that sucks, and how, if only they got their user interaction act together, users would do so much better at choosing options that protect their privacy. This seems obviously untrue to me, and here’s why…
Imagine that I have two otherwise identical social networking sites, one with great privacy protection (GPPbook) and one that has privacy controls that suck (PCTSbook). What will my experience be on these two sites?
When I sign up on GPPbook, having jumped through whatever privacy-protecting hoops there are for account setup, what’s the next thing I want to do? Find my friends, of course. So, how do I do that? Well, I search for them, using, say, their name or their email address. But wait - GPPbook won’t let me see the names or email addresses of people who haven’t confirmed they are my friends. So, I’m screwed.
OK, so clearly that isn’t going to work, let’s relax the rules a little and use the not-quite-so-great site, NQSGPPbook, which will show names. After all, they’re rarely unique, so that seems pretty safe, right? And anyway, even if they are unique, what have I revealed? That someone signed up for the site at some point in the past - but nothing more. Cool, so now I can find my friends, great, so I look up my friend John Smith and I find ten thousand of them. No problem, just check the photos, where he lives, his birthday, his friends and so forth, and I can tell which one is my John Smith. But … oh dear, no friend lists, no photos, no date of birth - this is the privacy preserving site, remember? So, once more I’m screwed.
So how am I going to link to my friends? Pretty clearly the only privacy preserving way to do this is to contact them via some channel of communication I have already established with them, say email or instant messaging, and do the introduction over that. Similarly with any friends of friends. And so on.
Obviously the experience on PCTSbook is quite different. I look up John Smith, home in on the ones that live in the right place, are the right age, have the right friends and look right in their photos and I click “add friend” and I’m done.
So, clearly, privacy is a source of friction in social networking, slowing down the spread of GPPbook and NQSGPPbook in comparison to PCTSbook. And as we know, paralleling Dawkins on evolution, what spreads fastest is what we find around. So what we find around is social networks that are bad at protecting privacy.
This yields a testable hypothesis, like all good science, and here it is: the popularity of a social networking site will be in inverse proportion to the goodness of its privacy controls. I haven’t checked, but I’ll bet it turns out to be true.
And since I’ve mentioned evolution, here’s another thing that I’ve been thinking about in this context: evolution does not yield optimal solutions. As we know, evolution doesn’t even drive towards locally optimal solutions, it drives towards evolutionary stable strategies instead. And this is the underlying reason that we end up with systems that everyone hates - because they are determined by evolution, not optimality.
So, is there any hope? I was chatting with my friends Adriana and Alec, co-conspirators in The Mine! Project, about this theory, and they claimed their baby was immune to this issue, since it includes no mechanism for finding your friends. I disagree, this means it is as bad as it possible for it to be in terms of “introduction friction”. But thinking further - the reason there is friction in introductions is because the mechanisms are still very clunky. I have to use cut’n'paste and navigating to web pages that turn up in my email (and hope I’m not being phished) and so forth to complete the introduction. But if the electronic channels of communication were as smooth and natural as, say, talking, then it would be a different story. All of a sudden using existing communications channels would not be a source of friction - instead not using them would be.
So, if you want to save the world, then what you need to do is improve how we use the ‘net to communicate. Make it as easy and natural (and private) as talking.
Ben Laurie - Three Books
I do most of my reading when travelling (have to find some way to fill in the email gap), and the last three books I’ve read have been notably great. So, in no particular order…
Musicophilia: Tales of Music and the Brain, by the slightly insane Oliver Sacks. I generally enjoy Sacks’ books but they always feel a bit light on science. This book is different - full of fascinating anecdotes backed up by actual research. Most astonishing is the way that music can have a radical affect on people suffering from very debilitating conditions, such as Parkinson’s and Alzheimer’s. Great read.
Old Man’s War by John Scalzi. The cover compares Scalzi to Robert Heinlein. This strikes me as entirely unfair; Heinlein’s books are entirely populated by Heinlein talking to himself (if the character is male) and brainy bimbos that are hoplessly in love with him. Scalzi manages a much grittier and highly engaging version of Starship Troopers (which is admittedly a classic, even if Heinlein did write it).
Finally, Crooked Little Vein by Warren Ellis. A high speed romp through the perverts of the modern age by the world’s unluckiest private investigator in search of the lost, secret, alternative constitution of the United States of America, under the control of a monkey-crap injecting Most Powerful Man In The World. Really. Apparently it was supposed to shock me (said the back cover) but I was mostly laughing.
Ben Laurie - Trust Me, I’m Signed!
The W3C recently announced their spec for signing widgets. Signing things is a good idea, if you’d like to be assured that they come from where you think they come from, or you want to detect tampering. But I would have hoped we were way past statements like this
Widget authors and distributors can digitally sign widgets as a trust and quality assurance mechanism.
If trust and quality were assured by signatures then our lives would be so much easier - but sadly it is not so. Indeed, it is so much not so that CAs, in an amazing piece of marketing, have managed to persuade us that, since they work so poorly for trust, what we should do is pay them even more money to get more robust signatures (a.k.a. EV certificates)!
Anyway, I was sufficiently irritated by this stupidity that I felt it necessary to remark on it. Which prompted this absolutely brilliant response from my friend Peter Gutmann
From the report:
Of signed detected files, severity of the threats tended to be high or severe, with low and moderate threats comprising a much smaller number of files:
Severe 50819
High 73677
Moderate 42308
Low 1099So there you go, signing definitely does provide a “trust and quality assurance mechanism”. If it’s a CA-certified signed rootkit or worm, you know you’ve been infected by the good stuff.
“the report”, by the way, is a large scale study by Microsoft which makes for some interesting reading. In particular, they also acknowledge that even the promise that signatures would at least let you track down the evil bastard that wrote the code has proven empty
Though also intended to identify the signing parties, Microsoft has been unable to identify any authors of signed malware in cooperation with CAs because the malware authors exploit gaps in issuing practices and obtain certificates with fraudulent identities.
Ben Laurie - CodeCon Is Back!
Unfortunately, I can’t be there, but the lineup looks great. The bio-hacking track looks particularly fun.
Not long to go now, less than two weeks. Sign up!
Ben Laurie - More Banking Stupidity: Phished by Visa
Not content with destroying the world’s economies, the banking industry is also bent on ruining us individually, it seems. Take a look at Verified By Visa. Allegedly this protects cardholders - by training them to expect a process in which there’s absolutely no way to know whether you are being phished or not. Even more astonishing is that this is seen as a benefit!
Frame inline displays the VbV authentication page in
the merchant’s main window with the merchant’s
header. Therefore, VbV is seen as a natural part of the
purchase process. It is recommended that the top
frame include the merchant’s standard branding in a
short and concise manner and keep the cardholder
within the same look and feel of the checkout process.
Or, in other words
Please ensure that there is absolutely no way for your customer to know whether we are showing the form or you are. In fact, please train your customer to give their “Verified by Visa” password to anyone who asks for it.
Craziness. But it gets better - obviously not everyone is pre-enrolled in this stupid scheme, so they also allow for enrolment using the same inline flow. Now the phishers have the opportunity to also get information that will allow them to identify themselves to the bank as you. Yes, Visa have provided a very nicely tailored and packaged identity theft scheme. But, best of all, rather like Chip and PIN, they push all blame for their failures on to the customer
Verified by Visa helps protect you from fraudulent claims from cardholders – that they didn’t take part in, or authorise, a payment. Once you are up and running with Verified by Visa, you are no longer liable for chargebacks of this nature.
In other words, if the phisher uses your Verified by Visa password, then it’s going to be your fault - obviously the only way they could know it is if you told them! If you claim it was not you, then you are guilty of fraud; it says so, right there.
Ben Laurie - Mining Is Easy
I’ve written before about the risks involved in exposing the social graph. Now there’s a nice video showing just how easy it is to mine that graph, and other data we give away so freely, using Maltego2. Scary stuff.
Ben Laurie - Capabilities for Python
Guido van Rossum has never been a big fan of this idea, and he recently unloaded a pile of reasoning as to why. Much of this really boils down to the unsuitability of existing Python implementations as a platform for a capability version of the language, though clearly there are language features that must go, too. There’s more on this point from tav, but perhaps his idea of translating Capability Python into Cajita is a more fruitful course…
Anyway, what intrigued me more than the specifics was this statement from Guido
The only differences are at the library level: you cannot write to the filesystem, you cannot create sockets or pipes, you cannot create threads or processes, and certain built-in modules that would support backdoors have been disabled (in a few cases, only the insecure APIs of a module have been disabled, retaining some useful APIs that are deemed safe). All these are eminently reasonable constraints given the goal of App Engine. And yet almost every one of these restrictions has caused severe pain for some of our users.
Securing App Engine has required a significant use of internal resources, and yet the result is still quite limiting. Now consider that App Engine’s security model is much simpler than that preferred by capability enthusiasts: it’s an all-or-nothing model that pretty much only protects Google from being attacked by rogue developers (though it also helps to prevent developers from attacking each other). Extrapolating, I expect that a serious capability-based Python would require much more effort to secure, and yet would place many more constraints on developers. It would have to have a very attractive “killer feature” to make developers want to use it…
There are two important mistakes in this.
Firstly, capability enthusiasts don’t prefer a security model in the sense that Guido is suggesting; we prefer a way of enforcing a security model. App Engine does this enforcement through layers of sandboxing whereas capability languages do it by not providing the untrusted code with the undesirable capabilities. Of course, a side effect of this approach is that capabilities allow far more subtle security models (e.g. “you can only write this part of the file system” or “you can only write files a user has specifically designated” or “you can create sockets, but only for these destinations”) without much extra work and so capability enthusiasts have a tendency to talk about and think in terms of those subtler models. However, Guido’s all-or-nothing model can be implemented easily with capabilities - we don’t have to be subtle if he doesn’t want us to be!
This fallacy causes the second error - because the security model does not have to be subtler, there’s no particular reason to imagine it should take any longer to implement. Nor need it place many extra constraints on developers (I will concede that it must place some constraints because not all of Python is capability-safe). Developers are really only constrained by capability languages in the intended sense: they can’t do the things we don’t want them to do. If the security models are the same, the constraints will be the same, regardless of whether you use sandboxes or capabilities.
Incidentally, I tried to sell the idea of capabilities to the App Engine team several years ago. Given how far we’ve come with Caja in a year, working on a language that is definitely less suited to capabilities than Python is, I would be very surprised if we could not have done the same for Python by now.
Ben Laurie - The Telegraph Show How Not To Do It
I’m a bit stunned that an organisation the size of The Telegraph would store user passwords in plaintext, but, well … they do.
Ben Laurie - DNSSEC: Update
I’ve had feedback since I wrote about DNSSEC that my makefile didn’t work on many platforms. Why Linux and FreeBSD have to use different versions of make I have no idea, but at least it is possible to write makefiles that work on either, if you’re careful. So, I’ve updated the tarball with a version that should work most places. Give it a try.
For the geeky, here’s a diff:
iff -r 94acb807ca7c -r d4a50f0d790c Makefile
--- a/Makefile Sat Mar 07 16:41:39 2009 +0000
+++ b/Makefile Sat Mar 07 16:49:37 2009 +0000
@@ -1,4 +1,6 @@
all: run
+
+.PHONY: named.root anchors.xml isc-dlv.conf
push: dnssec.tgz
scp dnssec.tgz www.links.org:files
@@ -6,7 +8,7 @@
run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf isc-dlv.conf
named -c named.conf -d 10 -g
-named.root!
+named.root:
rm -f named.root
wget ftp://ftp.rs.internic.net/domain/named.root
@@ -17,7 +19,7 @@
./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
mv /tmp/itar-trusted-keys itar-trusted-keys.conf
-anchors.xml! iana-pgp-keys
+anchors.xml: iana-pgp-keys
# appears to break without -v!
rsync -v rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml
@@ -46,7 +48,7 @@
gpg --export 1BC91E6C | gpg --no-default-keyring --keyring ./isc-pgp-keys --import
rm isc-key.tmp* 363
-isc-dlv.conf! isc-pgp-keys
+isc-dlv.conf: isc-pgp-keys
rm -f dlv.isc.org.named.conf*
wget http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf.asc
gpg --no-default-keyring --keyring ./isc-pgp-keys --verify dlv.isc.org.named.conf.asc dlv.isc.org.named.confShmooCon News - Badge Contest
Folks we have a winner!This year's badge contest was finally solved by Darth Null. He's winning a ticket to SC2010 and asks to give a shout out to Durak for his awesome squinting abilities which apparently came in handy when reading those barcodes. :)
Congrats Darth Null.
In other news, most of the speaker presos have been posted. If they're not up, it's simply because we haven't received them yet. Videos will follow soon.
Ben Laurie - Native Client
I mentioned Native Client in passing a while back but I didn’t explain what it is…
Native Client is a way to sandbox code without resort to hardware assistance. In short, what it does is statically verify that the code obeys certain rules, and as a result, that the code can only use the interfaces to the rest of the system that the sandbox intends it to use. In other words, it’s a bit like Caja only for native code instead of Javascript. There’s also a version of gcc that produces code that will pass the static validation - which means that pretty much any C (or C++ or Fortran) program can be ported to Native Client with little difficulty.
The Native Client team think the point of Native Client is to allow web apps to have access to high speed code without compromising the security of the user. This is certainly a use, but I find the idea of using it to enforce security in other areas quite interesting, too. For example, with Native Client you could make Mark Seaborn’s Plash both portable and more useful - which Mark has been working on. Of course, before this can be relied on we need to know that NaCl is secure, so it is interesting that the team are offering cash for bugs. You could get paid for playing with NaCl!
Ben Laurie - Doing DNSSEC Right
Since posting about DNSSEC, I’ve had lots of great feedback. So, in no particular order…
Various people have pointed out that DLV is not as bad as I suggested
- DLV is only activated for queries that cannot be proved secure in the cache
- DLV employs aggressive negative caching - it works out whether existing cached NSEC (and NSEC3?) records would prove nonexistence of a record before bothering to query it
- DLV is not used for domains that have trusted keys
Although the second measure is, as I remember it, strictly speaking against the rules (one is not supposed to calculate negative responses from the cache), clearly it can be stipulated that a DLV server must behave when serving NSEC records. Anyway, the net result is that the overhead of DLV is actually quite reasonable. I still say it should be run by every DLVed domain for every other, though. In any case, I am going to switch it on in my own caching resolver.
One thing I wanted to achieve is that a DNSSEC-ignorant resolver downstream of my caching resolver would only get validated results. I tried to do this with the dnssec-must-be-secure configuration option - but this is wrong. That option requires everything to be signed, whereas in DNSSEC it is perfectly OK for a zone to be unsigned so long as its parent delegates to it with no keys (bear in mind that with DNSSEC the nonexistence of the keys is provable, and so this is secure). In fact, BIND 5.3 behaves as I want it to with just DNSSEC enabled. In BIND 5.4 onwards I will have to switch it on with the dnssec-validation option (gee, thanks, ISC for making a backward incompatible change!).
Jelte Jansen operates a domain with various broken entries - this is very handy for testing and I now include its key in my configuration. Note that if you want to see a record that fails validation, then you need to set the CD bit (with dig, +cd or +cd +dnssec if you want to see the DNSSEC records).
Paul Hoffman wonders why I would prefer a signature (for anchors2keys) to download over HTTPS. The reason is that HTTPS download doesn’t really prove the file hasn’t been interfered with - the server will serve anything that happens to be in the filesystem over HTTPS, of course. A signature would be done with a key that I would hope is very strictly supervised, and so is far more trustworthy.
Incidentally, for DNSSEC newbies, one of the interesting features of DNSSEC is that it can be done entirely with offline keys. Proving negatives (i.e. the nonexistence of names) with such a constraint is an interesting problem - and one that I spent three years working on, leading in the end to RFC 5155.
I’m sure everyone is tired of reading my config and makefile, so there’s a tarball here.
Finally, thanks very much to all the experts for the excellent feedback.
Ben Laurie - DNSSEC With DLV
Tony asks “what about DLV?”.
DLV is Domain Lookaside Validation. The idea is that if your resolver can’t find a trust anchor for foo.bar.example.com, then it can go and look in a lookaside zone, hosted at, say, dlv.isc.org, for trust anchors. So, it would first look for com.dlv.isc.org and then example.com.dlv.isc.org and so forth.
So, what do I think of this? It’s another way to solve the problem of having the root not signed.
How does it compare to IANA’s ITAR?
- It’s much less efficient - all those extra lookups for every query.
- It covers more than just TLDs - ITAR could, too, but it doesn’t, for whatever reason.
- There doesn’t seem to be a way to force it, like there is for ITAR. That is, I would like to configure my caching server to force DNSSEC for every domain that exists in DLV, but I don’t believe I can. This makes DLV practically useless, since now only clients that check the AD bit will be aware of the failure.
Also, I think it would be organisationally better if all the participating domains would run DLV for each other, rather than have any single party running it.
Anyway, I modified my setup to also use DLV. Here’s the new Makefile
all: run
run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf isc-dlv.conf
named -c named.conf -d 10 -g
named.root!
rm -f named.root
wget ftp://ftp.rs.internic.net/domain/named.root
rndc.key:
rndc-confgen -a -c rndc.key
itar-trusted-keys.conf: anchors2keys anchors.xml
./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
mv /tmp/itar-trusted-keys itar-trusted-keys.conf
anchors.xml! iana-pgp-keys
# appears to break without -v!
rsync -v rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml
anchors2keys:
wget --no-check-certificate https://itar.iana.org/_misc/anchors2keys
chmod +x anchors2keys
iana-pgp-keys:
html2text -nobs http://www.icann.org/en/general/pgp-keys.htm > iana-pgp-keys.tmp
# IANA's PGP keys suck. Clean them up...
awk '/^>/ { print substr($$0,2,100); next; } /^Version:/ { print; print ""; next; } { print }' < iana-pgp-keys.tmp > iana-pgp-keys.tmp2
gpg --import iana-pgp-keys.tmp2
gpg --export 81D464F4 | gpg --no-default-keyring --keyring ./iana-pgp-keys --import
rm iana-pgp-keys.tmp*
force-dnssec.conf: itar-trusted-keys.conf
awk '/^"/ { gsub(/"/, "", $$1); print "dnssec-must-be-secure \"" $$1 "\" true;"; }' < itar-trusted-keys.conf | sort -u > force-dnssec.conf
isc-pgp-keys:
rm -f 363
wget --no-check-certificate https://www.isc.org/node/363
html2text < 363 > isc-key.tmp
awk '/^Version:/ { print; print ""; next; } { print }' < isc-key.tmp > isc-key.tmp2
gpg --import isc-key.tmp2
gpg --export 1BC91E6C | gpg --no-default-keyring --keyring ./isc-pgp-keys --import
rm isc-key.tmp* 363
isc-dlv.conf: isc-pgp-keys
rm -f dlv.isc.org.named.conf
wget http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf.asc
gpg --no-default-keyring --keyring ./isc-pgp-keys --verify dlv.isc.org.named.conf.asc dlv.isc.org.named.conf
mv dlv.isc.org.named.conf isc-dlv.conf
test:
dig -p5453 +dnssec www.dnssec.se @localhost
and here’s named.conf
options {
listen-on port 5453 { 127.0.0.1; };
pid-file "named.pid";
dnssec-enable true;
dnssec-lookaside . trust-anchor dlv.isc.org.;
include "force-dnssec.conf";
};
// obtain this file from ftp://ftp.rs.internic.net/domain/named.root
zone "." { type hint; file "named.root"; };
// include the rndc key
include "rndc.key";
controls {
inet 127.0.0.1 port 1953
allow { 127.0.0.1; }
keys { "rndc-key"; };
};
// include ITAR trust anchors
include "itar-trusted-keys.conf";
// include ISC DLV trust anchor
include "isc-dlv.conf";
Enjoy.
Incidentally, I have enabled “forced ITAR” on my main resolver, so we’ll see how that goes. I haven’t added DLV because, like I say, failure would not be noticed, so what’s the point of all the overhead?
Ben Laurie - What Is DNSSEC Good For?
A lot of solutions to all our problems begin with “first find a public key for the server”, for example, signing XRD files. But where can we get a public key for a server? Currently the only even slightly sane way is by using an X.509 certificate for the server. However, there are some problems with this approach
- If you are going to trust the key, then the certificate must come from a trusted CA, and hence costs money.
- Because the certificate is a standard X.509 certificate, it can be used (with the corresponding private key, of course) to validate an HTTPS server - but you may not want to trust the server with that power.
- The more we (ab)use X.509 certificates for this purpose, the more services anyone with a certificate can masquerade as (for the certified domain, of course).
One obvious way to fix these is to add extensions to the certificates that prevent their use for inappropriate services. Of course, then we would have to get the CAs to support these extensions and figure out how to validate certificate requests that used them.
But I have to wonder why we’re involving CAs in this process at all? All the CA does is to establish that the person requesting the certificate is the owner of the corresponding domain. But why do we need that service? Why could the owner of the domain not simply include the certificate in the DNS - after all, only the owner of the domain can do that, so what further proof is required?
Obviously the answer is: DNS is not secure! This would allow anyone to easily spoof certificates for any domain. Well, yes - that’s why you need DNSSEC. Forgetting the details of DNSSEC, the interesting feature is that the owner of a domain also owns a private key that can sign entries in that domain (and no-one else does, if the owner is diligent). So, the domain owner can include any data they want in their zone and the consumer of the data can be sure, using DNSSEC, that the data is valid.
So, when the question “what is the public key for service X on server Y?” arises, the answer should be “look it up in the DNS with DNSSEC enabled”. The answer is every bit as secure as current CA-based certificates, and, what’s more, once the domain owner has set up his domain, there is no further cost to him - any new keys he needs he can just add to his zone and he’s done.
Does DNSSEC have any other uses? OK, it would be nice to know that the A record you just got back corresponds to the server you were looking for, but if you trust a connection just on the basis that you used the right address, you are dead meat - you’ll need some key checking on top of it (for example, by using TLS) to avoid attacks by evil proxies (such as rogue wifi hotspots) or routing attacks and so forth. For me, the real value in DNSSEC is cryptographic key distribution.
Ben Laurie - Using DNSSEC Today
It’s been a while since I’ve properly paid attention to developments in the DNSSEC world, so I was surprised to learn that IANA now has an “Interim Trust Anchor Repository“. No need to wait any longer for the root to be signed, you can configure yourself to do DNSSEC right now.
Here’s how. First off, grab this Makefile
all: run
run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf
named -c named.conf -d 10 -g
named.root!
rm -f named.root
wget ftp://ftp.rs.internic.net/domain/named.root
rndc.key:
rndc-confgen -a -c rndc.key
itar-trusted-keys.conf: anchors2keys anchors.xml
./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
mv /tmp/itar-trusted-keys itar-trusted-keys.conf
anchors.xml! iana-pgp-keys
# appears to break without -v!
rsync -v rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml
anchors2keys:
wget --no-check-certificate https://itar.iana.org/_misc/anchors2keys
chmod +x anchors2keys
iana-pgp-keys:
html2text -nobs http://www.icann.org/en/general/pgp-keys.htm > iana-pgp-keys.tmp
# IANA's PGP keys suck. Clean them up...
awk '/^>/ { print substr($$0,2,100); next; } /^Version:/ { print; print ""; next; } { print }' < iana-pgp-keys.tmp > iana-pgp-keys.tmp2
gpg --import iana-pgp-keys.tmp2
gpg --export 81D464F4 | gpg --no-default-keyring --keyring ./iana-pgp-keys --import
rm iana-pgp-keys.tmp*
force-dnssec.conf: itar-trusted-keys.conf
awk '/^"/ { gsub(/"/, "", $$1); print "dnssec-must-be-secure \"" $$1 "\" true;"; }' < itar-trusted-keys.conf | sort -u > force-dnssec.conf
and this named.conf
options {
listen-on port 5453 { 127.0.0.1; };
pid-file "named.pid";
dnssec-enable true;
include "force-dnssec.conf";
};
// obtain this file from ftp://ftp.rs.internic.net/domain/named.root
zone "." { type hint; file "named.root"; };
// include the rndc key
include "rndc.key";
controls {
inet 127.0.0.1 port 1953
allow { 127.0.0.1; }
keys { "rndc-key"; };
};
// include ITAR trust anchors
include "itar-trusted-keys.conf";
and run make. After a while, with luck, you’ll have named with trust anchors configured (you can see which ones by looking at itar-trusted-keys.conf) running on port 5453 (and the rndc control channel on port 1953).
You can test it with, for example
$ dig -p5453 +dnssec www.dnssec.se @localhost
; < > DiG 9.3.5-P2 < > -p5453 +dnssec www.dnssec.se @localhost
;; global options: printcmd
;; connection timed out; no servers could be reached
[ben@euphrates ~/svn-work/peim/doc]
$ dig -p5453 +dnssec www.dnssec.se @localhost
; < > DiG 9.3.5-P2 < > -p5453 +dnssec www.dnssec.se @localhost
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 41806
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.dnssec.se. IN A
;; ANSWER SECTION:
www.dnssec.se. 300 IN CNAME dnssec.iis.se.
www.dnssec.se. 300 IN RRSIG CNAME 5 3 300 20090302080001 20090220080001 62658 dnssec.se. y0JcIxVunryZRaccDX2PteGyxCQ2dlfeoeDYNcoPKCryBa9vGWuNJwNa MhqzMmLLr5N4SbQsIL8YrQ8+l/wBFebXB6I8dJ8OWDmz6OqihSzkDYB/ qFwEWLQi49RfCuE6Qai/PnPh0Om+7guyL15fLTMh3PtZso4axt23/vqG 5RI=
dnssec.iis.se. 3600 IN CNAME www.iis.se.
dnssec.iis.se. 3600 IN RRSIG CNAME 5 3 3600 20090302135501 20090220135501 6477 iis.se. ebDsJcmZRHkq5Y+SLTIC2Iey3fNBj7r3bk3TAeyJPXtgFE6YJqAtJmv4 m5Sn1jDZhidnI0NWyPz5dUwDFfzVnJN/DH+CZJuiynKQge4inIGt8Dzk ybaq7JSoFkHABAu+IBbVKwR4+TW92tzv2CgzdtBIsQnuOn+CQMpmuz+N rFk=
www.iis.se. 3600 IN A 212.247.7.210
www.iis.se. 3600 IN RRSIG A 5 3 3600 20090302135501 20090220135501 6477 iis.se. aIOT7U/CRcFi3CcgaHp6EqV8JHkODodQM0Pg7CKh1gby4/8pGnqABDiU +4bg8/zDlAzVUz6o4j5sjIg5uS2A1ODJzp+UodXyVL9/Q8eBfZGSDuOa FPwK9jUxj6P1iXIqoMyeAS1PG1rFgSim/xpZLhJK2l5ScQ/1+Pq6SG8T Lgc=
;; Query time: 1236 msec
;; SERVER: 127.0.0.1#5453(127.0.0.1)
;; WHEN: Sun Feb 22 14:07:14 2009
;; MSG SIZE rcvd: 602
Because we have forced DNSSEC on the trusted domains (this is done in the included file force-dnssec.conf), the fact we get an answer at all tells us that the signatures checked out - but also the fact that the AD bit is set (”;; flags: ... ad ...“) tells you that the signatures were validated by the caching server you just set up. Note that pretty much no application will check for the AD bit, so DNSSEC is only really going to help if you have it forced on, as in this configuration. Obviously if you want to run this for real, you should run it on standard ports and point all your resolvers at it. Then you get the benefits of DNSSEC today with no application changes.
Note that ordinary queries (i.e. ones that don’t request DNSSEC) are also validated by the server, but we don’t see the DNSSEC stuff in the response
$ dig -p5453 www.dnssec.se @localhost
; < > DiG 9.3.5-P2 < > -p5453 www.dnssec.se @localhost
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 2159
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;www.dnssec.se. IN A
;; ANSWER SECTION:
www.dnssec.se. 100 IN CNAME dnssec.iis.se.
dnssec.iis.se. 3400 IN CNAME www.iis.se.
www.iis.se. 3400 IN A 212.247.7.210
;; AUTHORITY SECTION:
iis.se. 86200 IN NS ns3.nic.se.
iis.se. 86200 IN NS ns.nic.se.
iis.se. 86200 IN NS ns2.nic.se.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#5453(127.0.0.1)
;; WHEN: Sun Feb 22 14:41:25 2009
;; MSG SIZE rcvd: 147
I notice that the AD bit isn’t set, though, which seems like a bug.
Ben Laurie - Identification Is Not Security
The New York Times have an article about the Stanford Clean Slate project. It concludes
Proving identity is likely to remain remarkably difficult in a world where it is trivial to take over someone’s computer from half a world away and operate it as your own. As long as that remains true, building a completely trustable system will remain virtually impossible.
As far as I can tell, Clean Slate itself doesn’t make this stupid claim, the NYT decided to add it for themselves. But why do they think identification is relevant? Possibly because we are surrounded by the same spurious claim. For example…
- We need ID cards because they will prevent terrorism.
- We shouldn’t run software on our Windows box that isn’t signed because that’ll prevent malware.
- We should only connect to web servers that have certificates from well-known CAs because only they can be trusted.
But…
- The guys who crashed the planes were all carrying ID. Didn’t help.
- The guys who blew up the train in Spain were all carrying ID. Didn’t help.
- People get hacked via their browser all the time. Did signing it help?
- What does it take to sign code? A certificate, issued by a CA…
- What does it take to get a certificate? Not much … proof that you own a domain, in fact. So, I can trust the server because the guy that owns it can afford to pay Joker $10? And I can trust the code he signed? Why?
Nope. Security is not about knowing who gave you the code that ate your lunch - security is about having a system that is robust against code that you don’t trust. The identity of the author of that code should be irrelevant.
ShmooCon News - The ShmooCon Crew
is wiping the sleep from their eyes and slowly getting back to reality. Thanks to everyone who made it out to DC. We hope you had a good time.Speaker presentations and videos will be online soon. Videos will take a bit longer than the slides, but we will get them up there eventually.
Please remember to leave your feedback at feedback.shmoocon.org or, if you'd rather, shoot us an email. The online review system will be available for one more week, so get your reviews in before it's too late.
Thanks again folks. Keep watching this spot for more post-con wrap up.
Ben Laurie - Crypto Craft Knowledge
From time to time I bemoan the fact that much of good practice in cryptography is craft knowledge that is not written down anywhere, so it was with interest that I read a post by Michael Roe about hidden assumptions in crypto. Of particular interest is this
When we specify abstract protocols, it’s generally understood that the concrete encoding that gets signed or MAC’d contains enough information to unambigously identify the field boundaries: it contains length fields, a closing XML tag, or whatever. A signed message {Payee, Amount} K_A should not allow a payment of $3 to Bob12 to be mutated by the attacker into a payment of $23 to Bob1. But ISO 9798 (and a bunch of others) don’t say that. There’s nothing that says a conforming implementation can’t send the length field without authentication.
No of course, an implementor probably wouldn’t do that. But they might.
Actually, in my extensive experience of reviewing security-critical code, this particular error is extremely common. Why does Michael assume that they probably wouldn’t? Because he is steeped in the craft knowledge around crypto. But most developers aren’t. Most developers don’t even have the right mindset for secure coding, let alone correct cryptographic coding. So, why on Earth do we expect them to follow our unwritten rules, many of which are far from obvious even if you understand the crypto?
ShmooCon News - Day 2
and all seems to be going well. Over 1300 people are currently present.Ben Laurie - A Good Use of the TPM?
Back when the TPM was called Palladium I made myself unpopular in some circles by pointing out that there were good uses for it, too, such as protecting my servers from attackers.
Whether that is practical is still an interesting question - it’s a very big step from a cheap device that does some cunning crypo to a software stack that can reliably attest to what is running (which is probably all that has saved us from the more evil uses of the TPM) - but at a recent get-together for privacy and anonymity researchers George Danezis and I ran, Mark Ryan presented an interesting use case.
He proposes using the TPM to hold sensitive data such that the guy holding it can read it - but if he does, then it becomes apparent to the person who gave him the data. Or, the holder can choose to “give the data back” by demonstrably destroying his own ability to read it.
Why would this be useful? Well, consider MI5’s plan to trawl through the Oyster card records. Assuming that government fails to realise that this kind of thing is heading us towards a police state, wouldn’t it be nice if we could check afterwards that they have behaved themselves and only accessed data that they actually needed to access? This kind of scheme is a step towards having that kind of assurance.
ShmooCon News - Ads make us happy
Another ShmooCon vid from PSKL... This was sent to us with the oh so funny comment that it was just in time for that critical "all the tickets have already been sold" phase of advertising.You can also check out previous year's video fun in our archives. (Please be aware - we no longer offer free admission in exchange for ads, but we might hook you up with some special swag.)
ShmooCon News - ShmooCon Labs
The application period for ShmooCon Labs is officially over. We've got about 30 attendees this year plus a few vendor reps and the labs staff. They'll all work pretty much non-stop to make sure the con network is up and running before ShmooCon begins on Friday - the idea being that they learn a thing or two (or three) along the way as well.A few other things of note:
There are still a few (very few) rooms left at the Washington Hilton should anyone still be needing a hotel. Those of you who are local and maybe just want to stay in DC for Saturday night - this is a good option for you. Call 202-483-3000 and reference the code SHC for a great rate.
There is a ShmooCon Twitter feed and to (again) answer the question everyone keeps asking - yes, it really is us.
Lastly - it's snowing today in the DC area. Be sure to check those weather forecasts before heading this way.
Ben Laurie - Caja on the Yahoo! Developer Network
Here’s a nice (and brief) article about developing for the Yahoo! Application Platform, and, in the process, covering some of the benefits and gotchas of Caja.
Caja enforces the W3C standards for JavaScript, HTML, and CSS, regardless of browser (!).
Yes, you read correctly, if your code cajoles, it will run in Firefox and IE. This is amazing and its value cannot be overestimated.