Slashdot Mirror

Because JavaScript Cryptography Considered Harmful. Which, of course, depends on whether CAs, and the authorities that govern them, are part of your threat model.

I expect a surge in client side cryptography, where servers store encrypted data and the keys never leave the client. This can't suit every application but it could be a good selling point for a while. Most of it will be done in JavaScript for convenience, even if it's not a good idea. Mega is just an entry level example of what can go wrong. Some "real" client application (mobile or desktop) will be developed, I wonder if they'll get mainstream. Anyway that only raises the bar for whoever wants to spy on us. There are many other ways to bypass encryption (rootkits, 0 day exploits, etc), nevertheless it's going to increase their costs.

Because I spent a lot of time on that software, and I'm not really interested in giving it away?

So, it's not that it can't, it's just that you don't want to. That's fine, but hardly the same.

None of the ones I saw met my needs. None of them even came close, actually. The token-based authentication that most websites use makes it way too easy to sniff a few packets and then impersonate someone, and regrettably, the exorbitant cost of multi-domain certificates makes SSL infeasible at this time. Therefore, my base requirement was a robust and fairly lightweight, pure-JavaScript means of signing each individual HTTP request with a shared secret key derived from the user's passphrase and an arbitrary nonce generated by the server. (Still on my to-do list is adding synchronized timestamping and/or regular nonce rotation to prevent replay attacks, but given the site design, the damage posed by such an action would be fairly minimal, so I'm in no hurry.)

Just curios: how does your system prevent an attacker from simply replacing/modifying your JavaScript code with a snippet that copies the user's passphrase to his/her server?

Have you read Matasano Security's critique of JavaScript cryptography? Last time it was discussed on Hacker News, the only real objection was that you could use a browser extension to implement the crypto - nobody had a solution for pure, extension-less cryptography.

Douglas Crockford tends to disagree. And he's not alone.

How do they mitigate these inherent security problems of the JavaScript platform in the API draft? With XSS, I can always overwrite the browser's crypto API object, replacing it with a rogue implementation.

My understanding has been that JavaScript in its present form is not a viable platform for cryptography.

I think before even starting to approach the subject of browser cryptography, let alone comment on it, first read this article:
Javascript Cryptography Considered Harmful
It's an excellent summary of all the pitfalls, and (in my opinion) a good argument why people trying to design cryptography libraries for use in browsers should just give up and approach the problem they're trying to solve from a different angle.

Javascript isn't half as evil as you make it.

It's main failing is that it sucks for crypto. A quick reference I could dig out:
http://www.matasano.com/articles/javascript-cryptography/

Basically, it has several problems, the main one being that where they write "random key" in the "browser" box in their little flowchart it should honestly say "weak pseudo-random key".

You're only able to use a set of formally verified "safe" instructions. I'm no expert on this, so look here for more detail on the way it works, from people trying to break it.

Take a look at this article which explains why you want to use a slow hashing algorithm (such as doing md5 1000 times): http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Chrome has recently also had the benefit of intensive security tests by both Mark Dowd (as a contractor) and Michal Zalewski (as employee). Of course, the have been tested by many others also, but if I could hire any 2 guys in the world to test my browser, those would be the two I would want. Combined with the security bug bounties (which are small, but notable for existing anyway), I'd give Google props for putting their money where their mouth is, and showing they care.

Salt is, by definition, exposed when the hash is exposed. They are stored side-by-side and the salt is not encrypted.

Salt does not prevent brute-forcing of a single hash. What it prevents is users with the same password from having the same hash. With salt, an attacker must brute-force each password individually (or create a separate rainbow table for each different salt, which defeats the purpose of a rainbow table). With a rainbow table and no salt, every hash can be reversed in seconds to minutes.

It's worth noting that the algorithm you are using to generate the hash (or rather, the resultant hash itself) has an inherent complexity limit. MD5 hashes are 128 bits which is 16 bytes. Any password longer than 16 bytes has another password that is shorter than 16 bytes that will have the same MD5 hash. Yes... an attacker doesn't need to know your password, just a password that, when hashed, collides with your password.

SHA1 hashes have a length of 160 bits so passwords longer than 20 characters will have an equivalent password shorter than 20 characters that produces the same hash if you are using SHA1.

Not that you should be using MD5 or even SHA1 for hashing passwords. Both hash functions are inappropriate for this purpose. If you are using raw hash functions for protecting passwords, even if you are using salt, then you need to read this now: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Seriously though they did kind of do it the MS-DOS way.

By default OpenBSD has very few network services enabled.

Which is why I consider that particular claim rather worthless.

FWIW, OpenBSD's process isn't that great:

http://www.matasano.com/log/720/openbsds-amusing-handling-of-remote-kernel-overflow/

Theo de Raadt's main focus appears to be making sure that he is right (or looks right). Making things better takes second place to that.

I personally prefer the Postgresql process. There's a lot less unnecessary/counterproductive flaming with the Postgresql process.

never worked with them, but seem to be an industry leader. http://www.matasano.com/services/deploysafe/web/ might be what you are looking for

The point is that Code Access Security (CAS) depends on the fact that there is no bugs in the MSIL verifier. Dowd has previously found exactly these type of bugs in the Flash bytecode verifier: http://www.matasano.com/log/1032/this-new-vulnerability-dowds-inhuman-flash-exploit/

And here's tptacek's grovelling retraction (which followed his drunken rant on DD at the weekend which firmly argued the public have the right to know and trying to stop public discussion is Wrong). I fear the Matasanto crew and Halvar are about to discover what happens when geeks allow their 'satiable curtiosity to run away with their sense of ethics. Halvar in particular posted a long self-justification (with mathematical functions!) trying to prove that public dissemination before BlackHat would be a good thing.

=== BEGIN PTACEK ===

"Earlier today, a security researcher posted their hypothesis regarding Dan Kaminskyâ(TM)s DNS finding. Shortly afterwards, when the story began getting traction, a post appeared on our blog about that hypothesis. It was posted in error. We regret that it ran. We removed it from the blog as soon as we saw it. Unfortunately, it takes only seconds for Internet publications to spread.

We dropped the ball here.

Since alerting the Internet earlier in July about the upcoming announcement of his finding, Dan has consistently urged DNS operators to patch their servers. We confirmed the severity of the problem then and, by inadvertantly verifying another researcherâ(TM)s results today, reconfirm it today. This is a serious problem, it merits immediate attention, and the extra attention itâ(TM)s receiving today may increase the threat. The Internet needs to patch this problem ASAP.

Dan told me about his finding personally, in order to help ensure widespread patching before further details were announced at the upcoming Black Hat conference. We chose to have a story locked and loaded for that presentation, or for any other confirmed public disclosure. On a personal level, I regret this as well.

Dan did phenomenal work on this research. It was impossible to talk to him today and not know that he was sincere about coordinating a graceful disclosure and fix for the problem. That I helped detract from that work is painful both personally and professionally, and I apologize to Dan for the way this played out.

Thomas Ptacek

Principal, Matasano Security

Jul 21, 2008

From reading the comments on the matasano blog, I get a sneaky suspicion that the port randomisation is a mid-term workaround that they want everyone to get into place, before they reveal the actual hole (and fix, I hope). I don't think the port randomisation is the final fix...

The fact that he says (emphasis mine):

"So, as a temporary workaround, the affected vendors are recommending that Dan Bernstein's UDP port randomization technique be universally deployed."

makes me think so even more.

Actually, it's not completely implemented due to some problems they had with some components of the OS. Check here http://www.matasano.com/log/981/a-roundup-of-leopard-security-features/
"The dynamic linker library (dyld) is not randomized. From what I can tell, ten different Leopard macs booted at ten different times will have the same offset to dyld."

I was amused today when I read this article about a local Mac exploit due to a SUID binary.

osascript -e 'tell app "ARDAgent" to do shell script "whoami"'

All my Mac using friends reported they were vulnerable and I think they're all using the latest Leopard. I'm no Apple hater, don't get me wrong, but it does seem the little things can slip past Apple too, not just Linux (people where I work are *still* affected by the Ubuntu key issue of last month :o)!

--
Free Playstation 3, XBox 360 and Nintendo Wii

Um a NULL pointer via flash.
http://www.matasano.com/log/1032/this-new-vulnerability-dowds-inhuman-flash-exploit/

The NULL pointer dereferencing uses an absolute address, well a relative one from 0 which is the same thing. E.g. it does this

http://www.matasano.com/log/1032/this-new-vulnerability-dowds-inhuman-flash-exploit/

Not this time. Flash forgets to check that allocation failed, a ludicrously common error. It then uses that pointer with an offset controlled by the attacker. NULL isn't valid. NULL plus 1024 isnâ(TM)t valid. But NULL + 0x8f71ba90 is, as is NULL + N for any N that addresses valid memory.

To this address, controlled by attackers via wild offset, Flash writes a value that is also controlled by the attacker. This is the write32 pattern: a vulnerability that gives the attacker the means to set any one value in memory to a value of their choosing. Game over.

Except not quite.

The exploit doesn't actually get to offset an arbitrary number of bytes from 0. A complicated set of conditions constrains the address it writes to and the value it gives it.

The the actual write occurs via a structure offset. Flash is hardcoded to translate your offset into another number. Working offsets, as it turns out, will be greater than 0x80000000, and will be evenly divisible by 12 after 4 is added to them. Note: I thought I was hardcore when I wrote shellcode with no lowercase letters for the IMAP vulnerability in the â(TM)90s

....
Two fun details.

First, even though IE and Firefox use different Flash builds, the addressing inside them is compatible. The exploit works in both places.

Second, Flash isn't compiled with ASLR. So the attack works on Vista.

Mass casualty. Go Flash!

ActionScript bytecode state; yeah, about that. ActionScript is Javascript that controls Flash animations. But the Javascript system used by Flash is pretty advanced; for performance, it transforms Javascript into bytecodes for a VM. For a bytecode VM, ActionScript is pretty tight; its runtime stack is integrated with the CPUâ(TM)s runtime stack. The memory it uses to execute code is the same memory that the Flash C-code runtime uses to manage its own state. ActionScript is a register-based VM, meaning that its bytecode instructions concern themselves chiefly with moving values in and out of memory slots that simulate CPU registers. Those registers live in the runtime stack and are accessed by indexing. Meaning, a malicious Flash bytecode instruction can index its way to an arbitrary address on the system stack. Game over.

According to the link below, you first have to disable the protection on the computer by writing to the CSRs, which can only be done from ring 0. So already have to have root access to be able to do this. Or are they trying to do something else in that link?

Google Cache http://www.matasano.com/log/695/windows-remote-memory-access-though-firewire/

This same vulnerability also affects OS X as reported here: http://blog.juhonkoti.net/2008/02/29/automated-os-x-macintosh-password-retrieval-via-firewire

As well, as Linux, as reported in an earlier 2005 report about this firewire feature: http://www.matasano.com/log/695/windows-remote-memory-access-though-firewire/

Maximillian Dornseif demonstrated this same Firewire vulnerability against Linux and OS X machines in 2005. Adam Boileau just gets more press because he performed the hack against Windows PCs.

There are few problems DNSSEC solves that SSL/TLS won't do a far better job solving. SSL/TLS deployment is almost universal. With the vast effort we've spent fighting over how to secure a tiny portion of the Internet protocol stack, we could instead have come up with a way to make verifiable SSL certificates free and easily acquired. I wrote about this at length earlier this year.

Furthermore, DNSSEC is a mess. It has taken over ten years to come up with a protocol that a plurality of operators will agree to deploy --- and that protocol hasn't even been deployed yet. Until NSEC3 (or, in the alternative, whitelies) is standardized, the result of that 10+ year effort is a protocol that publishes full zone contents to the world. And have you looked at how NSEC3 works? It's literally a Unix-style password file encoded into DNS zones. I wrote about this at length earlier this year as well.

Finally, DNSSEC will break the DNS. Everyone who takes the time to read comments on Slashdot has dealt with "expired SSL certificate" dialogs in their browser. Everyone has clicked past them. DNSSEC presents the same problem, across the entire DNS, but offers no "click-through" to deal with the situation: DNSSEC works below the API layer, and there is no chance gethostbyname is going anywhere in the near future.

Did you know that DNSSEC doesn't even secure the DNS communication between your browser and your DNS server? There's a whole other protocol --- TSIG --- that handles the "last mile" of DNS security.

Personally, I would be highly skeptical of "security" analysis from companies like Infoblox that claim DNSSEC adoption has anything to do with the security of the Internet.

There are few problems DNSSEC solves that SSL/TLS won't do a far better job solving. SSL/TLS deployment is almost universal. With the vast effort we've spent fighting over how to secure a tiny portion of the Internet protocol stack, we could instead have come up with a way to make verifiable SSL certificates free and easily acquired. I wrote about this at length earlier this year.

Furthermore, DNSSEC is a mess. It has taken over ten years to come up with a protocol that a plurality of operators will agree to deploy --- and that protocol hasn't even been deployed yet. Until NSEC3 (or, in the alternative, whitelies) is standardized, the result of that 10+ year effort is a protocol that publishes full zone contents to the world. And have you looked at how NSEC3 works? It's literally a Unix-style password file encoded into DNS zones. I wrote about this at length earlier this year as well.

Finally, DNSSEC will break the DNS. Everyone who takes the time to read comments on Slashdot has dealt with "expired SSL certificate" dialogs in their browser. Everyone has clicked past them. DNSSEC presents the same problem, across the entire DNS, but offers no "click-through" to deal with the situation: DNSSEC works below the API layer, and there is no chance gethostbyname is going anywhere in the near future.

Did you know that DNSSEC doesn't even secure the DNS communication between your browser and your DNS server? There's a whole other protocol --- TSIG --- that handles the "last mile" of DNS security.

Personally, I would be highly skeptical of "security" analysis from companies like Infoblox that claim DNSSEC adoption has anything to do with the security of the Internet.

I think it's gonna be vendors like StillSecure, who got called out earlier this year for their loose interpretation of the GPL. From MS perspective, this is a perfect way to claim "we have the advantages of OsS and the added benefit of our propietary layer," and get more vendor penetration. It's like Apple and FreeBSD, except with a few added layers of business entities, lots more bad management, and about as many marketing lies about their support for OsS.

The reason that Law #1's written the way that it is is because it's written with the assumption that the attacker knows more than you do.

To be more specific, the bad guy knows about the as of yet undiscovered security hole that renders all of your OS level sandboxing moot. That's why when the bad guy gets to run code on your computer, it's not your computer any more.

And there have absolutely been such flaws in Windows (the windows manifest file vulnerability for example), OSX (the .DMG file vulnerability for example) and Linux (the ELF file core dump issue for example), so this isn't just wild speculation (I found all 3 of those by simply typing in "<os> elevation of privilege" to my favorite search engine).

Because ATM's are perfect. ATM manufactures are often the SAME as the voting machine manufacturers and they still can't get it right. ATM's and slot machines are successful in use because fraud doesn't have catastrophic effects across the industry, it's just a spot "hiccup". Voting machine fraud means the wrong person is put in office for however long, or even worse, amendments and other laws are passed erroneously.

I love how FUD articles get posted on the front page, but they would never post something with actual content like this:
Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes

Physical memory acquisition over Firewire is a trendy tactic for snapshotting suspsect systems without the interference of malware. Recall that Firewire, which is basically a glorified DMA controller with a funky cable coming out of it, has presumptively unmediated access to physical memory; your CPU may initialize the Firewire peripheral, but it doesn't get between the peripheral and the memory controller.

Helu. I'm Thomas Ptacek, one of the four challenge team members --- Slashdot left out Dino Dai Zovi, who kicked this off by writing a virtualized rootkit at Matasano last year.

Joanna has responded to our challenge. We invited her to stipulate any terms she deemed reasonable. She proferred:

• Five (5) laptops instead of two (2), as a defense against lucky guessing.
• We can't crash the machines in the process of testing.
• We can't spike the CPU on the machine for more than one (1) second.
• We have to open source our detector, and she'll open source her rootkit.
• We have to arrange to have her paid between $384,000 and $416,000, and wait six months.

You can probably predict our response.

Here's where it stands: all parties agree that by Black Hat '07, Blue Pill will not be in a state where it is hard to detect. Our detection techniques are likely to detect Blue Pill at Black Hat. Blue Pill requires six months of engineering time to get to a state where Joanna is confident that we can't detect it.

Here's why you care: a few weeks ago, Microsoft decided that Vista Home would not allow virtualization, in part because of the threat of virtualized malware. To the best of our knowledge, there have been two (2) real hypervisor rootkits ever produced: Joanna's Blue Pill, and Matasano's Vitriol. Neither has ever been seen in the wild, because neither has been released to the public. Meanwhile, our team is preparing to demonstrate at Black Hat this year that hypervisor malware is actually even easier to detect than the kernel malware operating systems like Vista are already exposed to.

Joanna's Blue Pill work, along with all the rest of her work (check out this project, where she turns AMD security hardware against forensics devices), is top-notch. In a weird, secretive space like security, this is how science gets done. Joanna chooses a side: it's possible to make undetectable malware. We square off on the opposite side. Then we debate it using code, presentations, papers, and I guess Slashdot stories. Hopefully, in the end, we all learn something.

Hope this stays interesting for everyone. Thanks for paying attention!

Helu. I'm Thomas Ptacek, one of the four challenge team members --- Slashdot left out Dino Dai Zovi, who kicked this off by writing a virtualized rootkit at Matasano last year.

Joanna has responded to our challenge. We invited her to stipulate any terms she deemed reasonable. She proferred:

• Five (5) laptops instead of two (2), as a defense against lucky guessing.
• We can't crash the machines in the process of testing.
• We can't spike the CPU on the machine for more than one (1) second.
• We have to open source our detector, and she'll open source her rootkit.
• We have to arrange to have her paid between $384,000 and $416,000, and wait six months.

You can probably predict our response.

Here's where it stands: all parties agree that by Black Hat '07, Blue Pill will not be in a state where it is hard to detect. Our detection techniques are likely to detect Blue Pill at Black Hat. Blue Pill requires six months of engineering time to get to a state where Joanna is confident that we can't detect it.

Here's why you care: a few weeks ago, Microsoft decided that Vista Home would not allow virtualization, in part because of the threat of virtualized malware. To the best of our knowledge, there have been two (2) real hypervisor rootkits ever produced: Joanna's Blue Pill, and Matasano's Vitriol. Neither has ever been seen in the wild, because neither has been released to the public. Meanwhile, our team is preparing to demonstrate at Black Hat this year that hypervisor malware is actually even easier to detect than the kernel malware operating systems like Vista are already exposed to.

Joanna's Blue Pill work, along with all the rest of her work (check out this project, where she turns AMD security hardware against forensics devices), is top-notch. In a weird, secretive space like security, this is how science gets done. Joanna chooses a side: it's possible to make undetectable malware. We square off on the opposite side. Then we debate it using code, presentations, papers, and I guess Slashdot stories. Hopefully, in the end, we all learn something.

Hope this stays interesting for everyone. Thanks for paying attention!

Tom Ptacek says:

Patents are a crappy way to lock up the fix for a vulnerability. 10 years from now, it's vanishingly unlikely that your discovery will still be relevant. If it is, you've got better things to do with it than sell it to bottom-feeders.

Here's a better idea: copyright law. Copyright is immediate.

Here's what you do:

Find a vulnerability --- anything; say, memory corruption in some OS service --- and devise a third-party patch for it.

Publish the patch. Only the patch.

But before you do, wrap the patch up in a DRM scheme. An in-kernel, interrupt-hooking virtual machine with an encrypted instruction set should do nicely. It's worth the work; you'll be doing this over and over again. You want people to sweat to figure out how your patch works.

Alert the world to your discovery. You're a hero! You can root any computer on the Internet!

Don't publish the details of the vulnerability. No, wait, don't even allow the details to be published. If anyone figures out how your patch works, sue them under the DMCA. Especially if it's the vendor.

The vendor will, of course, claim they have the right to reverse-engineer your "intellectual property" for security and interoperability purposes. Let the courts decide. In the mean time: nice of them to establish some precedent.

Points to anyone who can prove to me that this doesn't qualify as "responsible disclosure".

Dave G. covered this on our blog last month. There's backstory to this.

As Mikko acknowledges, the real purpose of ".bank" is not to make it easier for end-users to recognize fake sites. A new TLD does almost nothing to ameliorate that problem; end-users don't know what TLDs are, or what the slash character in a URL means. And before you yelp that end-users should learn that stuff, ask yourself: do you understand how the NANP phone number scheme works, or what the 3-digit exchange number in the middle of your phone number means? But you can use your phone just fine, can't you?

The purpose of ".bank" is to make it easier for security software to patrol for fake bank sites. A great idea! Why didn't somebody think of it before? Because they did: most of the mainstream AV vendors will also sell you something that will spot fake bank sites. They do it by building and tracking whitelists of valid banking sites. If that sounds like a lot of work, it's because it is.

F-Secure would like the rest of the world to do that work for them. If all the banks lived under ".bank", they could issue a ".bank-detector" plugin that would flag illicit bank sites. This may not be a horrible idea; open-source projects could do the same thing easily too. But, as everyone who tracks this stuff is pointing out, the banks aren't going to comply: they already process transactions using a myriad of random-sounding unidentifiable domain names, which drastically complicates whitelisting.

Uh, gross? Did you mean to write:

And, you do know you can safely call free() on the result of a failed malloc (guaranteed to be NULL), right?

Though, if you don't have an answer to what you planned to do in the rest of your program if malloc fails, you have no business coming up with some complicated error reporting protocol instead of simply hooking malloc and gracefully exiting on any failure.

Glad to help. Please stop using goto now.

I think that there are changes in the nature of things that happen. Steps forward and step backwards, that's the natural way of things. Look at what Sun is doing, they are trying to emulate the success of opensource.

I think there are 3 things that are going on that will make this era kind of difficult for opensource and the community.

1. Opensource is traditionally a meritocracy. Code is king. If you want to take part, write some code. If you can't code, do something else to help the team, run the web site, write docs, etc.. With all of the blogs and stuff now, there are a lot of people taking credit, acting authoritative and aren't really always parts of the community. I'm not going to bash ESR out right, but he does that. He started a bunch of shit when he stopped using Fedora, no bug reports, no patches, nothing but a bug pile of shit when he was "pushed too far." If you want to be part of the community, take part in the community, speak for the community or act like part of it, then be part of it. Code. Do something tangible. Lot's of other projects have had leaders that got fed up with the constant bitching and taking of people that never sent anything back. Give back, if something is broken, go fix it, it's easier than you think. Be aware of who does too. It's a bit of a caste and it works because it is. Hop in, the water is nice. Respect the doers more than the takers and the talkers.
2. Look at this. Companies are trying to assume credit also. The company in question here has never contributed any code to any project. Think about that when you spend your money. I'm not going to say for a second that you should only ever support opensource friendly companies but it doesn't hurt. Look at Apple, they publish more source code than I'd have ever believed 10 years ago, enough for a full OS... They keep stuff private as well, as is their right, but they actually take part. Follow GCC, Apple gives back. Chomsky said free speech is kind of a binary, you're either for it or against it, there isn't a middle ground. OSS isn't that different, companies either take part or they just take.
3. Lastly, I'm not sure how to say this the right way. We've been doing opensource long enough that the newest era of coders doesn't seem as willing or able to take part. The itch is different or something. I look at like the Rails community, they are writing a lot of throw away code on throw away projects, that's how and why it works. There is no reason to make anything "perfect" because you'll just throw it all out and rebuild it if you need something different. That whole "just do it quick and drop it" kind of mentality is kind of contradictory. There is a ton of thrown out code. Initially, just getting code out was really important but it is something different to run well run and living project. The amount of thrown out stuff is upsetting at times but that's the nature of the beast at some level. It's hard and a lot of work to do it right and do it well.

A forth thing, possibly, is the whole sense of taboo in the community and "unix culture" has grown bigger than can be maintained. The BSD guys are doing a good job of preventing their community from growing, they don't like to change that much (unless it's a threading model, in which case they'll change it many times with no measurable affect and talk about how much better they've made it ;-) I've been following things like the Fedora parallel init discussion, Apple has done launchd (apache license no less, so it's compatible) Sun did SMF, there are factions that will prevent anything like that from being done in Fedora or Debian simply because they don't want to change. Apple dumped cron and init at the same time and improved upon both without that much code.. XML isn't UNIXy enough. Why use Java or C# when you can use C? The heuristics for

Check out this thread. Basically a company is selling astaro or a knockoff and claiming it's their own. Subsequently, they are claiming that they contribute to various projects but cannot seem to say which ones. This is the kind of crap that is screwing it up. Rather than doing the code, companies are trying to get credit and street cred for other people's work and that just sucks. We'll probably weed these folks out though.

Nothing about DNSSEC has improved since wrote about it last year:

• The current "standard" (RFC2535) remains "dead and buried" according to DNS pater familias Paul Vixie
• Nobody even knows what problem DNSSEC is meant to solve, and why it's worth deploying in a world with pervasive TLS
• It's a nightmare to deploy, both for administrators and for software developers who have to handle things like precomputing tens of thousands of expensive signatures
• The only reference implementation of the protocol is BIND, the second-least-trusted piece of open source code on the Internet.

DNSSEC is a huge waste of time. For a fraction of the effort, we could have pervasive opportunistic VPN-style connections. Or we could clean up the mess of insecure code that currently provides our core infrastructure. Or a unified standard secure email transport based on GPG/PGP. Or a concerted effort to solve the cross-site scripting problem. You could come up with a way to secure and authenticate the AOL OSCAR IM protocol and still do more good than DNSSEC ever will.

Of course, the IETF people will never admit this. The IETF types used to define themselves by making fun of the OSI X-standards people; "rough consensus and working code!". The Internet won, CLNP lost. Where do you think all those standards bureaucrats you made fun of in the OSI groups went? That's right; to IETF working groups.

Apple did what I would expect, and as someone that owns Apple stock I would want them to do. Their image and name was being slandered and they defended themselves. And if they are being honest, they took on the costs and did their own audit, found bugs and patched them.

To this day, no exploit has been demonstrated reliably against any hardware by these guys, this is a fact.

To this day, no proof that Secureworks or these two researchers gave any information to Apple or had any contact with them prior to the media campaign has been shown. This is a fact. No crash dumps, no emails that were sent, nothing, no response from Apple, nothing. Just words against words. I'm not saying that there aren't bugs, just that the claims made by these researchers that they were pressured aren't backed.

To this date, no evidence of any threat of a law suit has been shown by either side.

So far we simply see an email from Apple's PR people (go figure, this is a fucking PR campaign) expecting clarification.

Geez, don't leave out Matasano's response. George Ou is a tool.

Ivan from Core Security Technologies responded to this and other accusations in the comments of Thomas Ptacek's blog post on the subject:

http://www.matasano.com/log/720/openbsds-amusing-h andling-of-remote-kernel-overflow

Check the leading gurus - Jeremiah Grossman and RSnake - they put this dude to shame http://www.matasano.com/log/699/did-idg-bet-1000-t hat-acunetix-cant-steal-credit-cards-from-random-w ebsites/ http://jeremiahgrossman.blogspot.com/2007/02/acune tix-networkworld-and-1000-oh-my.html http://ha.ckers.org/blog/20070214/1000-to-steal-da ta-from-30-of-sites/

Aciicmez et al are extending an attack they published a few months ago. It's real, but:

• It targets RSA implementations, not the algorithm, which is fine

• Attackers need to be on the same host as the victim

• This specific attack is tuned to the Pentium 4 architecture

This paper doesn't break SSL.

We wrote about the attack two months ago. A quick, dumbed-down recap:

The CPU aggressively caches aspects of what programs do. It doesn't make an exception for RSA. You obviously can't just read key bits out of the cache.

But caches are finite, and way, way too small to accomodate everything every program does. So operations from one program are constantly evicting cached values from other programs. This makes the other program imperceptably but measurably slower. By writing a program that constantly and carefully measures those time differences, you can watch an RSA operation from another program leave footprints through the cache.

There are years-old attacks like this against the L1 and L2 caches, and extensions that use hyperthreading to improve the resolution. Some variants, which measure timing differences but don't track cache footprints, are remote attacks. These aren't. You run a "spy" process on the machine; it repeatedly executes a series of operations and measures timing differences. Aciicmez found an overlooked cache which makes Pentium branch prediction work (the BTB). They published back in August.

From what I can tell, this paper extends the attack; they figured out that the Pentium 4 architecture has two BTB caches, and their original attack wasn't hitting both of them. Their new attack does, and that creates much bigger timing differences, making RSA's footprints much easier to see.

This is really cool stuff, but from where I stand, they hit game-over back in August with the original BTB attack. This paper reads like a refined exploit for the same vulnerability.

Since this is localhost-only, and (unlike Bernstein's and Boneh's attacks) can't be extended remote, it's not going to impact SSL or (single-user) SSH. The classic victim of timing attacks is smart cards. For these attacks, another interesting possibility is DRM; these attacks say you can't trust crypto running on the same Pentium 4+ as an attacker.

No, I commented on it too. Here's some food for thought:

http://www.matasano.com/log/window-snyder
http://www.blogger.com/profile/13043301

Someone with a hotmail address (windowsnyder@hotmail.com) as a security expert on XP? No wonder Windows is broken. My own tests show that more than 1% of all hotmail addresses are down temporarily on any particular day.

There is more history here than meets the eye. Yes, Window used to work for MS but before that she worked for @Stake. . You remember them? The security company founded by a bunch of hackers! Window herself was involved with similar groups before then such as New Hack City and Messiah Village. She has a been a regular attendee at Defcon and other hacker cons such as Pumpcon and Summercon. Even now she has tight relations with group that was formed by old hackers from @Stake and earlier Matasano.com.

What does all this mean? It means that Mozilla is getting one smart person to work on thier security.

Well, Microsoft sure does NOT have a very good record of making a secure system and that record is over 15 years old. But regardless, one thing I was looking for was what/where this person did BEFORE Microsoft to see if there really might be some security talent there. That's when I found that she worked for @Stake before going to Microsoft( http://www.matasano.com/log/mtso/team ). This is the same @Stake which fired one of their own, their CTO no less, when he released a document which was NOT kind regarding Microsoft Windows security( http://www.computerworld.com/securitytopics/securi ty/story/0,10801,85563,00.html ).

So, I hope they actually had an expert to interview/test her because those two resume' items are NOT providing strength in any claim of being a security expert. IMO.

LoB

Window didn't just leave Microsoft to join Mozilla, she actually left awhile back to be one of the co-founders of Matasano Security, http://www.matasano.com/. Founding a company is a good reason to leave a company ;) She did a great job at Microsoft, and I'm sure she is going to do a great job at Mozilla.

I wrote about this after reading the white paper. I don't think this is a particularly useful idea.

The key "insight" of the paper is that if you associate cookies with IP addresses, and not domain names, attackers can't spoof DNS to steal cookies. So a server and client have a facsimile of a "trusted channel"; if the server can recover a proper IP-tagged cookie, it knows it's talking to a client and not a man-in-the-middle.

Apart from the fact that this whole scheme is aimed at a relatively exotic exploit, which exploit accounts for only a fraction of all phishing attacks, I don't think it will work technically. The simplest reason is Javascript. Attackers don't have to relay requests for victims; they can complete a transaction and transparently direct the victim back to the server. The server need never have contact with the attacker.