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.
Posts
1 comment:
Thank you for your review and comments on DNP3 Application Note AN2013-004. It is the product of several months of review and discussion by the members of the DNP Technical Committee. I take the opportunity here to thank them for their contribution.
You express mild disappointment that the Users Group did not mention the AEGIS Consortium tool in the App Note.
The DNP Users Group policy is not to promote any specific vendor's services over those of any other vendor or endorse any specific product. The exception to this is the specific "Conformance Tested" marking of devices on the Users Group website that have passed the Users Group's own DNP3 Conformance Tests.
As Adam Crain himself has told me when discussing this, there are a number of fuzzing platforms that could be applied to testing DNP3. The AEGIS Consortium tool is just one of these.
The Users Group recommends that testing be performed. By the very nature of "directed randomness" employed in fuzz testing, one tool may identify particular faults that might not be exposed by another. It may be beneficial to use multiple different tools in order to increase test coverage.
Andrew West
Chair, DNP3 Technical Committee
Post a Comment