Readers of this blog are well aware of a number of vulnerability reports from ICS-CERT about problems with various implementations of the DNP3 protocol that result in improper input validation vulnerabilities that were originally reported by the team of Crain-Sistrunk. The DNP Users Group has published a new application note (AN2013-004) that addresses the Validation of Incoming DNP3 Data. While it is not yet (as of 11:00 pm CST, 12-11-13) available on the DNP Users Group web site, the decision has been made to make this application note available to the public.
The copy that I have seen provides some interesting “General Coding” recommendations (along with the expected DNP3 protocol details that will be of little interest to the general reader of this blog). Some of those include:
• Parse and validate all incoming data using a “trust nothing” approach before processing it or performing any actions based on the data.
• Validation of object data should be robust and object-dependent; the handling of unexpected/invalid data will need to be device-dependent and well-thought-out (e.g. master requests that do not apply to an outstation’s specific functionality, timestamps that contain invalid values that cannot be converted to a realistic internal time, counter values that decrease, etc.).
• Consider the removal of debugging artifacts and associated constructs from the production code.
None of the above is really new. I’m sure that I’ve heard similar messages in the programming classes that I took 20+ years ago, but they do bear repeating.
Since the Crain-Sistrunk vulnerabilities were all detected through the use of a custom made fuzzer I am really glad to see the following comment closing out the general coding consideration discussion:
“Adopt a holistic Security Development Life-cycle (SDL) that includes, but is not limited to, code reviews, static & dynamic analysis, and fuzz testing [emphasis added] (e.g. www.microsoft.com/security/sdl/, grouper.ieee.org/groups/plv/, www.cert.org/secure-coding/).”
It might have been nice if it had mentioned the fuzz tester that will made publicly available by the AEGIS Consortium at the SANS Summit in March.