TLS record handling vulnerability in GnuTLS [MU-201202-01] [CVE-2012-1573]
ASN.1 length decoding vulnerability in Libtasn1 [MU-201202-02] [CVE-2012-1569]
Download The PGP Signed Text Version Of This Advisory
Note: Thanks to Red Hat Security Team for requesting the CVE IDs above.
While the bad news is that experts are declaring that we have entered the age of cyber war, the worse news as we enter 2012 is that security systems and professionals are just not able to keep up. Security attacks are increasing in their complexity and intensity every day. These range from inter-state attacks (like the one on Raytheon this year and the ones from China that are being investigated by the U.S. government) to cyber-crime (that includes countless malware and DDOS attacks against businesses and consumers).
If you are running CouchDB on an EC2 node with an EBS volume (or otherwise), it’s kinda hard to predict how the view performance will be affected by disk seeks and other criteria. Add complex reduce functions to this mix and you are flying blind. Just in my last blog, we talked about adding parameterization to blitz.io so you can easily test location-aware iPhone and Android apps. What if we could use CouchDB itself to generate fully parameterized tests so you can blitz it?
MuSL stands for Mu Scenario Language, a canonical canonical Domain Specific Language that we use in Mu Studio to represent complex transactions between multiple hosts using multiple transports and layers. The language itself borrows constructs from numerous languages and was designed to be protocol friendly. We just published an interactive application protocol playground that shows off MuSL and how to use it for various types of testing including LTE, NoSQL, Databases, Layer2 and DPI.
So we’ve had this thing called MuSL (Mu Scenario Language) for more than a year now in the Mu Studio product. It’s the format of choice at Mu for modeling everything from layer 2 through 7 across a wide range of applications, everything from LTE (Long Term Evolution), Databases, SCADA, Web applications, NoSQL to FCoE (Fiber Channel over Ethernet). Our customers use this for Functional Testing, Fuzzing and most recently Scale Testing. This is the first of a series of blogs describing what MuSL is and how you can use a single description of a multi-host, multi-protocol, multi-transport transaction for Application Fuzzing to Scale Testing.
There are two kinds of test tool vendors in the world. Those that count in binary and those that don’t. Okay, stale joke aside there are those that test applications (like Mercury, now part of HP, IBM, etc) and those that test the infrastructure (like IXIA, Spirent, etc). Mu was founded on the premise that this boundary is blurring rapidly and there needs to be a new kind of testing solution that spans the layers between applications and infrastructures and looks at the service as a whole. As we look into the imminent future of HTML5 and the innovation in mobile and cloud apps, you can see this in play right now. And yet all these test tool vendors are lagging behind this brave new world.
Fuzzing has in the past mostly been relegated to protocols and file formats. With the huge surge in mobile apps, cloud applications, virtualization and social gaming, not to mention a RESTful API for everything these days, the challenge becomes generating fuzz tests rapidly for these applications. This is not just for the actual services, but also for the application-aware systems that are getting smarter by the day. We now have Deep Packet Inspection, Application Identification and a host of new technologies that allow firewalls and UTM’s to inspect application flows for compliance, QoS and access control.
Using Mu Studio, we recently enabled one of our customers to do both functional and fuzz testing of their proxy/load-balancer (P/LB). This P/LB supports SSL termination, IPv6, Caching, Compression, WAN Acceleration & Optimization and a plethora of really cool features that enable high-volume cloud apps and web sites. What I want to talk about is our approach to testing complex products/deployments like these from both a functional and fuzz/security/resiliency testing perspective.
Just saw someone tweet about Python dissectors in Wireshark. Personally, I would’ve preferred a Ruby DSL that maps back to the internal libwireshark API in a way that makes writing dissectors incredibly easy. A couple of years ago, I presented “I see dead protocols” at CanSecWest and talked quite a bit about laziness, impatience and virtue. In the context of dissectors, I dug out some code that I wrote a while back that essentially converts a parser into a fuzzer. Let me explain.
It’s cool that Charlie Miller fuzzed the iPhone and broke it, but the catch phrase for me was (paraphrased) “When I start the fuzzer, I want to get some sleep and when I wake up find tons of 0-days“. I remember watching the movie with my kids and it wasn’t that the factory made awesome chocolates, but the whole thing was automated with elves and such.
