How I discovered CCS Injection Vulnerability (CVE-2014-0224)

http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html

by rdtsc • 12 years ago

114 28 12 years ago

ccsinjection.lepidum.co.jp

bayonetz3• 12 years ago

It's funny, I just assume open source security oriented development would follow far more rigorous testing and verification than it apparently does. I guess it's no different from every other kind of development - testing and verification are not the fun part. Human incentives being what they are, this keeps playing out. Bounties are probably the only practical way to reverse those incentives because making that cash makes testing and verification fun again.

Alupis4• 12 years ago

Even at big shops... testing is not fun and not done as much as you'd [want to] think.

jacquesm• 12 years ago

Proposal: When something is completed according to the devs a bonus is posted. For every vulnerability discovered by all the other devs in the company a portion of the bonus gets paid out. If an 'x' period has passed and no vulnerabilities have been discovered the remainder is paid out to the original devs.

Touche• 12 years ago

Maybe I'm weird but writing a test, seeing it fail, fixing the bug, and then seeing it pass is quite delightful. Having a set of 100+ test, doing a large refactoring and seeing them all pass, is a completely joy. Then again, I also like writing documentation.

sp3322• 12 years ago

OpenSSL was such a painful codebase to work on that people quickly gave up trying to test it. https://twitter.com/OpenSSLFact Also their memory-management wrappers made it impossible for valgrind etc. to even see which memory was "used" and "freed" inside the program. http://www.openbsd.org/papers/bsdcan14-libressl/mgp00007.htm...

Alupis4• 12 years ago

Well, this is sort of fudd being spread by the libressl project.

Most old and large codebases will have a mix of coding styles, etc... even at big companies (take a gander at the recently posted Windows 2000 source code for example, or the leaked Half Life 2 codebase, etc).

Does it make testing more difficult with preferred tool X? Maybe... but perhaps tool X isn't the best fit for the codebase? Or perhaps minor changes could be made to make it work well.

In any event... part of being a developer is being able to read and understand a variety of coding styles... since, coding styles have zero effect on the code's purpose/execution.

Not trying to detract... but we should remember the people who complained about the coding styles and difficultly in reading/understanding the codebase were new to the codebase, and the codebase was not in their expected format... which is normal when you sit down to any new codebase. Also... this is a crypto codebase... so there will be an element that is always difficult for an outsider to read and understand.

userbinator• 12 years ago

It seems odd that I haven't seen a full state diagram (including send/receive packet details) for SSL, unlike e.g. TCP, since I think that having one, either as part of the spec (which only contains a brief one for the handshake sequence) or created from it before writing any code, would've made it much more difficult to cause bugs like this. At least I've found state diagrams very useful when working with protocols like this.

contingencies3• 12 years ago

Agreed. The sheer brilliance of clarity in the classic TCP/IP Illustrated: Volume 1 - The Protocols only becomes visible in hindsight. Anyone know if the the LaTeX source for its diagrams are available? I have been able to emulate them for the most part in graphviz using shape=record when required, but wonder if that was the technique used.

(PS. Reading the above tome ~1999, I actually discovered numerous specification flaws in the RFCs ... eg. for ARP and ICMP, that could be used for remote OS detection.)

rdtsc• 12 years ago

What is interesting is that the (core?) of OpenSSL was re-written in Coq according to the author. Then the natural question can that representation be used to generate C code from it and would that make a safer product.

nine_k• 12 years ago

I very much hope that some next big crypto / security library will be designed and tested in some rigorous language like Haskell, its key parts proven correct with something like Coq, and then an efficient and portable implementation code generated automatically.

A C implementation seems inevitable, but an easy-to-link Rust implementation would be very nice to have.

CatMtKing• 12 years ago

There's hs-tls (http://hackage.haskell.org/package/tls-0.9.11), but being a newb to both crypto and Haskell, I can't tell you much about it.

hrjet• 12 years ago

It seems like the author was able to discover the vulnerability while in the process of specifying it in Coq (understanding the handshakes better during specification).

From what I read the Coq specification itself wasn't complete or used to discover the vulnerability.

Would be great if the author shed some light here.

ian-lewis• 12 years ago

That seems correct. He discovered it while creating the coq specification but coq wasn't itself used to discover the bug. He confirmed that much in this podcast (It's in Japanese though): http://mozaic.fm/post/88061749963/4-security-protocol.

o_____________o• 12 years ago

Okay, how many of you thought this said "CSS"?

jimmytidey• 12 years ago

acdanger• 12 years ago

Mildly disappointed this was not about injecting arbitrary styles into sites.

skeletonjelly• 12 years ago

How I hacked HN using a CSS vulnerability to make it look like reddit. 4214 comments 1 hour ago

err4nt• 12 years ago

got me too :S

How I discovered CCS Injection Vulnerability (CVE-2014-0224)

Related Stories