Dan Kaminsky's Blog

Ladies and Gentlemen of the Quantum Physics Community:

  I want you to make a Pseudorandom Number Generator!

  And why not!  I’m just a crypto nerd working on computers, I only get a few discrete bits and a handful of mathematical operations.  You have such an enormous bag of tricks to work with!  You’ve got a continuous domain, trigonometry, complex numbers, eigenvectors…you could make a PRNG for the universe!  Can you imagine it?  Your code could be locally hidden in every electron, proton, fermion, boson in creation.

  Don’t screw it up, though.  I can’t possibly guess what chaos would (or would fail to) erupt, if multiple instances of a PRNG shared a particular seed, and emitted identical randomness in different places far, far away.  Who knows what paradoxes might form, what trouble you might find yourself entangled with, what weak interactions might expose your weak non-linearity.  Might be worth simulating all this, just to be sure.

  After all, we wouldn’t want anyone saying, “Not even God can get crypto right”.

—–

0day is cool.  Killing 0day, sight unseen, at scale — that’s cooler.

If you agree with me, you might be my kind of defender, and the upcoming O’Reilly Security Conference(s) might be your kind of cons.

Don’t get me wrong.  Offense is critical.  Defense without Offense is after all just Compliance.  But Defense could use a home.  The Blue Team does not always have to be the away team.

So for quite some time, I’ve been asking Tim O’Reilly to throw a highly technical defensive security event.  Well, be careful what you wish for.  I actually keynoted his Velocity event with Zane Lackey a while back, and was struck by the openness of the environment, and the technical competence of the attendees.  This is a thing that would be good for Defense, and so I’ve taken the rare step of actually joining the Program Committee for this one,  CFP’s for NYC & Amsterdam are still open (but not for much longer!).  How would you know if this is your sort of party?

NIST’s SAMATE project has been assembling this enormous collection of minimized vulnerability cases.  They’re just trying to feed static analyzers, but if you’re filled with ideas of what else is possible with these terabytes of goodies – this is your con.

Researchers at Stanford instrumented the IDE’s of students, and watched how early failures predicted later ones.  Can we predict the future authorship of security vulnerabilities?  In what ways do languages themselves predict failures, independent of authors?  If this interests you, this is your con.

It’s not actually surprising that somebody would claim to be the creator of Bitcoin.  Whoever “Satoshi Nakamoto” is, is worth several hundred million dollars.  What is surprising is that credible people were backing Craig Wright’s increasingly bizarre claims.  I could speculate why, or I could just ask.  So I mailed Gavin Andresen, Chief Scientist of the Bitcoin Foundation, “What the heck?”:

What is going on here?

There’s clear unambiguous cryptographic evidence of fraud and you’re lending credibility to the idea that a public key operation could should or must remain private?

He replied as follows, quoted with permission:

Yeah, what the heck?

I was as surprised by the ‘proof’ as anyone, and don’t yet know exactly what is going on.

It was a mistake to agree to publish my post before I saw his– I assumed his post would simply be a signed message anybody could easily verify.

And it was probably a mistake to even start to play the Find Satoshi game, but I DO feel grateful to Satoshi.

If I’m lending credibility to the idea that a public key operation should remain private, that is entirely accidental. OF COURSE he should just publish a signed message or (equivalently) move some btc through the key associated with an early block.

Feel free to quote or republish this email.

Good on Gavin for his entirely reasonable reaction to this genuinely strange situation.

Craig Wright seems to be doubling down on his fraud, again, and I don’t care.  The guy took an old Satoshi signature from 2009 and pretended it was fresh and new and applied to Sartre.  It’s like Wright took the final page of a signed contract and stapled it to something else, then proclaimed to the world “See?  I signed it!”.

That’s not how it works.

Say what you will about Bitcoin, it’s given us the world’s first cryptographically provable con artist.  Scammers always have more to say, but all that matters now is math.  He can actually sign “Craig Wright is Satoshi Nakamoto” with Satoshi’s keys, openly and publicly.  Or he can’t, because he doesn’t have those keys, because he’s not actually Satoshi.

SUMMARY:

1. Yes, this is a scam.  Not maybe.  Not possibly.
2. Wright is pretending he has Satoshi’s signature on Sartre’s writing.  That would mean he has the private key, and is likely to be Satoshi.  What he actually has is Satoshi’s signature on parts of the public Blockchain, which of course means he doesn’t need the private key and he doesn’t  need to be Satoshi.  He just needs to make you think Satoshi signed something else besides the Blockchain — like Sartre.  He doesn’t publish Sartre.  He publishes 14% of one document.  He then shows you a hash that’s supposed to summarize the entire document.  This is a lie.  It’s a hash extracted from the Blockchain itself.  Ryan Castellucci (my engineer at White Ops and master of Bitcoin Fu) put an extractor here.  Of course the Blockchain is totally public and of course has signatures from Satoshi, so Wright being able to lift a signature from here isn’t surprising at all.
3. He probably would have gotten away with it if the signature itself wasn’t googlable by Redditors.
4. I think Gavin et al are victims of another scam, and Wright’s done classic misdirection by generating different scams for different audiences.

===

UPDATE:  This signature does actually validate, you just have to use a different version of OpenSSL than I did originally.

Of course, if this is the signature that already went out with that block, it doesn’t matter.  So I’m looking into that right now.

Update 2:

I’ve made some comments regarding Apple vs. the FBI at Wired.

CVE-2015-7547 is not actually the first bug found in glibc’s DNS implementation.  A few people have privately asked me how this particular flaw compares to last year’s issue, dubbed “Ghost” by its finders at Qualys.  Well, here’s a list of what that flaw could not exploit:

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql, nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd, xinetd.

And here are the results from a few minutes of research on the new bug.

More is possible, but I think the point is made.  The reason why the new flaw is significantly more virulent is that:

• This is a flaw in getaddrinfo(), which modern software actually uses nowadays for IPv6 compatibility, and
• Ghost was actually a really “fiddly” bug, in a way CVE-2015-7547 just isn’t.

As it happens, Qualys did a pretty great writeup of Ghost’s mitigating factors, so I’ll just let the experts speak for themselves:

• The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead.
• Many programs, especially SUID binaries reachable locally, use gethostbyname() if, and only if, a preliminary call to inet_aton() fails. However, a subsequent call must also succeed (the “inet-aton” requirement) in order to reach the overflow: this is impossible, and such programs are therefore safe.
• Most of the other programs, especially servers reachable remotely, use gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also known as full-circle reverse DNS) checks. These programs are generally safe, because the hostname passed to gethostbyname() has normally been pre-validated by DNS software:
  • . “a string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets.” This makes it impossible to satisfy the “1-KB” requirement.
  • Actually, glibc’s DNS resolver can produce hostnames of up to (almost) 1025 characters (in case of bit-string labels, and special or non-printable characters). But this introduces backslashes (‘\\’) and makes it impossible to satisfy the “digits-and-dots” requirement.

And:

TL;DR:  The glibc DNS bug (CVE-2015-7547) is unusually bad.  Even Shellshock and Heartbleed tended to affect things we knew were on the network and knew we had to defend.  This affects a universally used library (glibc) at a universally used protocol (DNS).  Generic tools that we didn’t even know had network surface (sudo) are thus exposed, as is software written in programming languages designed explicitly to be safe. Who can exploit this vulnerability? We know unambiguously that an attacker directly on our networks can take over many systems running Linux.  What we are unsure of is whether an attacker anywhere on the Internet is similarly empowered, given only the trivial capacity to cause our systems to look up addresses inside their malicious domains.

We’ve investigated the DNS lookup path, which requires the glibc exploit to survive traversing one of the millions of DNS caches dotted across the Internet.  We’ve found that it is neither trivial to squeeze the glibc flaw through common name servers, nor is it trivial to prove such a feat is impossible.  The vast majority of potentially affected systems require this attack path to function, and we just don’t know yet if it can.  Our belief is that we’re likely to end up with attacks that work sometimes, and we’re probably going to end up hardening DNS caches against them with intent rather than accident.  We’re likely not going to apply network level DNS length limits because that breaks things in catastrophic and hard to predict ways.

This is a very important bug to patch, and it is good we have some opportunity to do so.

It’s problematic that, a decade after the last DNS flaw that took a decade to fix, we have another one.  It’s time we discover and deploy architectural mitigations for these sorts of flaws with more assurance than technologies like ASLR can provide.  The hard truth is that if this code was written in JavaScript, it wouldn’t have been vulnerable.  We can do better than that.  We need to develop and fund the infrastructure, both technical and organizational, that defends and maintains the foundations of the global economy.

Click here if you’re a DNS expert and don’t need to be told how DNS works. Click here if your interests are around security policy implications and not the specific technical flaw in question.

Update:  Click here to learn how this issue compares to last year’s glibc DNS flaw, Ghost.

So, my Defcon talk, ultimately about ending clickjacking by design.

TL:DR: The web is actually fantastic, and one of the cool things about it is the ability for mutually distrusting entities to share the same browser, or even the same web page. What’s not so cool is that embedded content has no idea what’s actually being presented to the user — Paypal could have a box that says “Want to spend $1000” and somebody could shove an icon on top of that saying “$1.00” and nobody could tell, least of all Paypal.

I want to fix that, and all other Clickjacking attacks. Generally the suggested solution involves pixel scraping, i.e. comparing what was supposed to be drawn to what actually was. But it’s way too slow to do that generically. Browsers don’t actually know what pixels are ultimately drawn normally; they just send a bunch of stuff to the GPU and say “you figure it out”.

But they do know what they send to the GPU. Web pages are like transparencies, one stacked over the next. So, I’ve made a little thing called IronFrame, that works sort of like Jenga: We take the layer from the bottom, and put it on top. Instead of auditing, we make it so the only thing that could be rendered, is what should be rendered. It works remarkably well, even just now. There’s a lot more work to do before web browsers can really use this, but let’s fix the web!

Oh, also, here’s a CPU monitor written in JavaScript that works cross domain.

So some of the more fun bugs involve one team saying, “Heh, we don’t need to validate input, we just pass data through to the next layer.”  And the the next team is like, “Heh, we don’t need to validate input, it’s already clean by the time it reaches us.”  The fun comes when you put these teams in the same room.  (Bring the popcorn, but be discreet!)

Policy and Technology have some shared issues, that sometimes they want each other to solve.  Meanwhile, things stay on fire.

I talked about some of our challenges in Infosec with Die Zeit recently.  Germany got hit pretty bad recently and there’s some soul searching.  I’ll let the interview mostly speak for itself, but I would like to clarify two things:

1) Microsoft’s SDL (Security Development Lifecycle) deserves more credit.  It clearly yields more secure code.  But getting past code, into systems, networks, relationships, environments — there’s a scale of security that society needs, which technology hasn’t achieved yet.

2) I’m not at all advocating military response to cyber attacks.  That would be awful.  But there’s not some magic Get Out Of War free card just because something came over the Internet.  For all the talk of regulating non-state actors, it’s actually the states that can potentially completely overwhelm any potential technological defense.   Their only constraints are a) fear of getting caught, b) fear of damaging economic interests, and c) fear of causing a war.  I have doubts as to how strong those fears are, or remain.  See, they’re called externalities for a reason…

(Note:  This interview was translated into German, and then back into English.  So, if I sound a little weird, that’s why.)

So I went ahead and did a podcast with Stewart Baker, former general counsel for the NSA and actually somebody I have a decent amount of respect for (Google set me up with him during the SOPA debate, he understood everything I had to say, and he really applied some critical pressure publicly and behind the scenes to shut that mess down).  Doesn’t mean I agree with the guy on everything.  I told him in no uncertain terms we had some disagreements regarding backdoors. and if he asked me about them I’d say as such.  He was completely OK with this, and in today’s echo-chamber loving society that’s a real outlier.  The debate is a ways in, and starts around here.

You can get the audio (and a summary) here but as usual I’ve had the event transcribed.  Enjoy!

Steptoe Cyberlaw Podcast-070

Stewart: Welcome to episode 70 of the Steptoe Cyberlaw Podcast brought to you by Steptoe & Johnson; thank you for joining us. We’re lawyers talking about technology, security, privacy in government and I’m joined today by our guest commentator, Dan Kaminsky, who is the Chief Scientist at WhiteOps, the man who found and fixed a major and very troubling flaw in the DNS system and my unlikely ally in the fight against SOPA because of its impact on DNS security. Welcome, Dan.

Dan: It’s good to be here.