Back before I was trying to keep my blood pressure reliably low, I would have responded to this set of dnsmasq vulns
https://www.cso.com.au/article/628031/prehistoric-bugs-dnsmasq-strike-android-linux-google-kubernetes/ with an impassioned plea to keep a financial floor under the primary authors of network facing software as an insurance policy for network society. I also have long hoped that we would see useful risk assessments vs costs of prevention emerge from network vulnerable companies and insurance houses. Billions of devices run dnsmasq, and it had been through multiple security audits before now. Simon had done the best job possible, I think. He got beat. No human and no amount of budget would have found these problems before now, and now we face the worldwide costs, yet again, of something ubiquitous now, vulnerable. I'd long hoped, also, we'd see rapid updates enter the entire IoT supply chain, which remains a bitter joke. "Prehistoric" versions of dnsmasq litter that landscape, and there is no way they will ever be patched, and it would be a good bet that many "new" devices for the next several years will ship with a vulnerable version. I've grown quite blase' I guess, since heartbleed, and the latest list of stuff[1,2,3,4] that scared me only just last week, is now topped by this one, affecting a humongous list of companies and products. http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=973527&SearchOrder=4 I am glad to see lede and google reacting so fast to distribute updates... and I'm sure the container folk and linux distros will also react quickly... ... but, it will take decades for the last vulnerable router to be taken out of the field. And that hardly counts all the android boxes, all the linux distros that use dnsmasq, all the containers you'll find dnsmasq in, and elsewhere. Those upgrades, might only take years. [1] http://bits-please.blogspot.com/2016/06/trustzone-kernel-privilege-escalation.html (many others, just google for "trustzone vulnerability") [2] http://www.zdnet.com/article/researchers-say-intels-management-engine-feature-can-be-switched-off/ [3] https://www.kb.cert.org/vuls/id/240311 [4] https://arstechnica.com/information-technology/2013/09/researchers-can-slip-an-undetectable-trojan-into-intels-ivy-bridge-cpus/ _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
