Cisco ASN.1 vulnerability (cisco-sa-20160721-asn1c)

Just in case you missed it, Cisco has recently announced a critical flaw with their code that affects a range of products [1]. However, whilst there will undoubtedly be a lot of discussion around the detail of the vulnerability specifics in the coming weeks (especially if someone turns it into a working exploit), I think that it actually raises a few broader questions that are worth exploring too.

Firstly, is the use of language in the advisory itself. The headline says it all really: Cisco is clearly placing the blame at the feet of Objective Systems, the supplier of the third-party code (who has also released their own advisory too [2]). This is a bit like a car manufacturer blaming the gearbox subcontractor if there’s a recall. Now, it is true that it might be due to a flaw in the third-party code, but as with the car analogy, the ultimate responsibility for ensuring that a product is fit for purpose, lays with the car manufacturer. Even a half-arsed root cause analysis for how the flaw made it through to a finished product (then remained undetected through four major product releases), should quickly show that it is ultimately nothing to do with the third-party code at all, but instead lays with failures in quality assurance.

Secondly, although the word compiler is used liberally in the Cisco advisory, the original advisory released by Lucas Molas [3] (the researcher who found the flaw), is very clear that the root cause is in a runtime library. So it is just another TP code issue, rather than an esoteric compiler bug that is being hinted at.

Thirdly, this is a common library that is used in a number of products, so don’t expect the fallout to be limited to Cisco. The CERT advisory [4] already lists a number of vendors who are likely to be affected, so it would be wise to expect this one to have the potential of snowballing in the coming weeks. You can almost feel the hushed silence, as the ambulance-chasers dust off their reverse-engineering toolkits and get ready to go to work.

Fourthly, speaking from the perspective of someone who has written an ASN.1 interpreter from scratch, it is complex and fiddly; which means easy to get wrong. So it comes as no surprise that this isn’t the first time that there has been a critical issue that has been found in third-party ASN.1 code which is common across a range of platforms. Does anyone remember the huge batch of ASN.1 issues about 15-years back that were discovered by the University of Oulu Secure Programming Group [5]? Déjà vu baby!

Finally, and most importantly, the description of the vulnerability provided by the researcher shows that the root cause lays in parameters that are used without being first sanity checked. In fact, it’s a straightforward boundary condition that overflows a 32bit integer, which really is pretty much the lowest of-the-low-hanging-fruit when it comes to unit testing. So I would have to wag my chubby finger at both Cisco and Objective Systems and question their approach to QA in their development cycle. This isn’t rocket science people!

References

1. http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160721-asn1c
2. http://www.obj-sys.com/blog/?p=949
3. https://github.com/programa-stic/security-advisories/tree/master/ObjSys/CVE-2016-5080
4. http://www.kb.cert.org/vuls/id/790839 
5. https://www.sans.org/reading-room/whitepapers/protocols/snmp-potential-asn1-vulnerabilities-912