|
|
Codenomicon Newsletter 2009-08Topics: |
|
|
The Fuzzer That Does Not Fuzz"The fuzzer that does not fuzz", was how Codenomicon test tools were described at Black Hat USA 2009. Without necessarily knowing it, the speaker made the biggest compliment to our tools anyone has given for years, if ever. Before 1998, all fuzzers that at least I know about were entirely stateless, and purely random. You should not really even consider this approach any more. After 1998, in the PROTOS project, we described an approach where no randomness was involved at all. We called it Robustness Testing, based on definitions we heard e.g. ETSI use for such a testing approach. Other names for similar approach are grammar testing (used e.g. by Wurldtech) and syntax testing (used by testing specialists everywhere). In PROTOS we noticed that if a protocol was modelled using dynamic and thorough state machines and message descriptions, there was no need for randomness anymore. Actually, the incremental benefits of adding random tests to the systematically built tests was so insignificant that eventually we just left them out entirely. Everything was carefully optimized. Test execution times were extremely fast (from minutes to few hours), and test coverage was much better than with other techniques, even those in use today. After almost ten years, block-based fuzzers were invented. They are a kind of cross-breed between the purely random, non-protocol-aware fuzzers of the early 90s, and robustness testing tools that are entirely based on protocol models and systematic test generation. A block-based fuzzer adds enough protocol awareness to its minimalistic model and state diagrams, to be able to somewhat limit the amount of random or semi-random changes it does. Why did the inventors include any randomness at all? Because a fuzzer is supposed to do random testing - or perhaps that is just what people thought. So when someone calls us a "fuzzer that does not fuzz", they are finally understanding the difference between a fuzzer, and a Robustness Testing tool. Even though finally in 2008 we decided to call our tools fuzzers also, they really isn't anything fuzzy about our tools. And we are proud of that!
Ari Takanen More information: |
|
|
|
XML VulnerabilitiesCodenomicon Ltd, a leading vendor of software security testing solutions, announced that it has helped fix multiple critical flaws in popular XML libraries, including implementations from Sun Microsystems, Apache Software Foundation, and Python. XML has come a long way from the days when it provided support for just a few applications. It is now used to a significant extent by all the main specifiers of protocols, and in some (but not all) cases is the dominant specification language. Usually the notation is associated with use of the XML-defined encoding, with a few exceptions. This is similar to our earlier work with ASN.1 vulnerabilities (PROTOS SNMP case in 2001-2002), the major improvement being to add the XML capability to our proprietary fuzzing framework. Early this year (2009) we released some of our first XML-based tools to the market and used XML fuzzing technology against a set of open source XML implementations. The result was that once again, everything broke. Like ASN.1, XML is not a protocol by itself, but a method for describing structures. It is used in a wide range of modern protocols and file formats. These flaws are caused by a set of problematic inputs that can be given to any applications using XML. Each vendor (library, programming language, parser, application using XML) will have different flaws. This is exactly like the times when flaws were found in ASN.1. There also, it was not a single flaw in ASN.1, but each vendor that had their own set of flaws and those flaws could be triggered by ASN.1-aware fuzzers. Codenomicon will release its new testing solution, DEFENSICS for XML commercially along with explaining more details about some of the XML vulnerabilities that were found at the Hacker Halted 2009 security conference in Miami, Florida, in September 2009. The CROSS open source testing team at Codenomicon has previously found flaws in such open source projects as Apache, OpenSSL, GnuTLS, Squid, and NetBSD. More information: |
|
|
|
Codenomicon Defensics for 3G/4G/LTE4G/LTE is one of the strong R&D focus areas for Codenomicon during the second half of 2009 and and early 2010. Past experience has shown that any new and complex technology is vulnerable before it has been subjected to rigorous and systematical robustness testing. Most recent example of course being XML discussed above. There is no reason to believe new 4G/LTE technologies would be inherently secure either. DEFENSICS for 4G provides unique value by offering support for core LTE/EPC (Evolved Packet Core) protocols, such as GTPv1 and GTPv2. Assuring the security and robustness of underlying layers like IP, including Mobile IP, UDP and SCTP are equally important. Diameter is offered for AAA robustness assurance. The most important use scenarios to be tested involve User Access (UA) to LTE/EPC core and an interface between LTE/EPC and wild Internet (PDN-GW testing to be more precise). In the User Access case, Serving Gateway (SG) and Mobility Management Entity (MME) are critical components to be tested. These components also play major role in roaming scenarios between operators, creating a trust boundary requiring a high level of robustness. An aspect over which operator has least control in an all-IP network is IP traffic originating from user equipment, and as such, robustness of IP packet handling should be thoroughly tested in an end-to-end configuration. Packet Data Network Gateway (PD-GW), together with the AAA servers create outer boundary of LTE/EPC facing Internet. PDN-GW is also part of the trust boundary in roaming scenarios. This requires high degree of robustness and reliability from these components. Currently Codenomicon is actively developing a GTPv2 protocol tester for the critical interfaces mentioned earlier. The rest of the protocols are already supported off-the-shelf. |
|
|
|
Hot CROSS Bugs!The Newsletter editor had a chance to interview one of the CROSS team's security researchers, Ossi Herrala about who, why and what Codenomicon Robust Open Source Software (CROSS) team is. Who are you?We are hackers. We dress in black but wear white hats. We are young and enthusiastic and we love the Open Source community. We don't do evil. We want to help the community. We are also part of the community ourselves. Why do you do it?We test Open Source software because it's easily and freely available. Open Source implementations of various protocols give us good base to test our own tools against. And once in a while we find problems in the implementations. Open Source community gives us the tools we do our daily work with and I think our CROSS team then contributes back to the community by sharing the findings and by giving our tools for free to use. What do you do with the findings?When we find something, we document our findings to our Collab environment and start our own research about the issue. This is a co-operation between teams inside Codenomicon and everyone is free to contribute. After the research is finished, we review the results and report our findings. The Finnish National Computer Emergency Response Team (CERT-FI) takes the ball and begins to contact the vendors and starts to coordinate the fixes and public advisories. The guys at CERT-FI do the hard work and we acknowledge that. Thank you! Where are the exploits?We don't write exploits. It's laborious job to do and it doesn't help the community. However, I think the exploits for some of our disclosed findings might be out there somewhere. But the impact of the exploits is minor because of our responsible disclosure. |
|
|
|
Follow Codenomicon In Social Media |
|
|
|
Upcoming EventsMeet us at upcoming events! Wireless China Industry Summit 2009
Hacker Halted USA 2009
ISSE 2009
The IT Security Expo IT-SA 2009
RSA Conference Europe 2009
For details, see: |
|
|
|
Latest News
For latest news from Codenomicon, see: |
