Saturday, February 18, 2017

Reader Comment – Moxa NPort Advisory

Today Reid Wightman posted a comment to a December blogpost that mentioned a control system security advisory published by ICS-CERT for Moxa NPort products. Reid was identified as one of the researchers that identified one or more of the vulnerabilities covered in that advisory. Reid’s comments that the reported fix for CVE-2016-9361 does not work. Please read his comment for more details.

Alert readers might remember that Digital Bond (with whom Reid was associated at the time) publicly disclosed the vulnerability in April of last year, resulting in an ICS-CERT control system security alert. Given the total elapsed time between the initial notification by Digital Bond and the published “fix”, it is especially disconcerting that Reid has to report that the fix does not work.

Assuming that there was no deliberate malfeasance involved on the part of Moxa, I can only conclude that Moxa did not really understand the cause of the vulnerability discovered by Reid. This is one of the reasons that it is important to have someone not employed by the vendor verify the efficacy of the fix. I think it would be best if the discovering researcher were the one to do the verification testing. That way there can be no doubt about how well the fix mitigates the discovered vulnerability.


Reid does not mention in his comment whether or not he had coordinated the report of the failure of the vendor’s fix with ICS-CERT. In some ways, I am hoping that he did not. If he had, it would seem to indicate that ICS-CERT (or perhaps Moxa) did not accept Reid’s judgement about the efficacy of the fix. Given the seriousness of the vulnerability (CVSS v3 base score of 9.8) I would have hoped that ICS-CERT would have tried to corroborate Reid’s report.

1 comment:

Jake Brodsky said...

Even with large, reputable companies, fixes can take frustratingly long periods of time.

I documented a case as a paying customer with an actual functionality problem in the field that could easily be exploited as a denial of service attack. It took more than seven months from when we first identified the problem to a resolution.

The problem is that often embedded systems companies outsource their software writers to places in the world where exchange rates promise cheap talent.

This forces all updates and all performance issues to go through a lengthy contractual process. If you miss the update and testing cycle, you could be in for a very long wait. And unfortunately, that's pretty much what happened to us. Thankfully, the product we were using was still very much in development. Other products may be in long term maintenance mode. Pity the people who find problems in those products...

 
/* Use this with templates/template-twocol.html */