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
