<html><head></head><body><div dir="auto">I share your concern for updates, and support for same.<br><br></div>
<div dir="auto">However, there are architectural solutions we should have pursued a long time ago, which would bound the damage of such vulnerabilities. Make the system far more robust.<br><br></div>
<div dir="auto">There's no reason for dnsmasq to run with privileges. Not should packet parsing. All datagrams should be end to end authenticated.<br><br></div>
<div dir="auto">We developed these rules in 1973-78, both in Multics and in the MIT part of the Internet design. Recommended a specific embedding of cryptography in TCP.<br><br></div>
<div dir="auto">They were rejected as unnecessary by Unix and by the TCP decision-makers.<br><br></div>
<div dir="auto">Now Fedora Server uses SELinux in it's packaged version of dnsmasq, so dnsmasq can't do anything it is not permitted to do, or access resources it isn't supposed to. My personal home router is Fedora 26 Server, so I feel very calm about using dnsmasq.<br><br></div>
<div dir="auto">But the "community" rejects SELinux! Turns it off after install. I know it is a pain, but it works. And it is based on the Multics concepts that Unix ignored. The principle of least privilege.<br><br><br></div>
<div dir="auto"><!-- tmjah_g_1299s -->Sent from <!-- tmjah_g_1299e --><a href="http://www.bluemail.me/r?b=10777"><!-- tmjah_g_1299s -->Blue<!-- tmjah_g_1299e --></a><!-- tmjah_g_1299s --> <!-- tmjah_g_1299e --></div>
<div class="gmail_quote" >On Oct 3, 2017, at 8:50 PM, Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="blue">Back before I was trying to keep my blood pressure reliably low, I<br>would have responded to this set of dnsmasq vulns<br><br><a href="https://www.cso.com.au/article/628031/prehistoric-bugs-dnsmasq-strike-android-linux-google-kubernetes">https://www.cso.com.au/article/628031/prehistoric-bugs-dnsmasq-strike-android-linux-google-kubernetes</a>/<br><br>with an impassioned plea to keep a financial floor under the primary<br>authors of network facing software as an insurance policy for network<br>society. I also have long hoped that we would see useful risk<br>assessments vs costs of prevention emerge from network vulnerable<br>companies and insurance houses.<br><br>Billions of devices run dnsmasq, and it had been through multiple<br>security audits before now. Simon had done the best job possible, I<br>think. He got beat. No human and no amount of budget would have found<br>these problems before now, and now we face the worldwide costs, yet<br>again, of something ubiquitous now, vulnerable.<br><br>I'd long hoped, also, we'd see rapid updates enter the entire IoT<br>supply chain, which remains a bitter joke. "Prehistoric" versions of<br>dnsmasq litter that landscape, and there is no way they will ever be<br>patched, and it would be a good bet that many "new" devices for the<br>next several years will ship with a vulnerable version.<br><br>I've grown quite blase' I guess, since heartbleed, and the latest list<br>of stuff[1,2,3,4] that scared me only just last week, is now topped by<br>this one, affecting a humongous list of companies and products.<br><br><a href="http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=973527&SearchOrder=4">http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=973527&SearchOrder=4</a><br><br>I am glad to see lede and google reacting so fast to distribute<br>updates... and I'm sure the container folk and linux distros will also<br>react quickly...<br><br>... but, it will take decades for the last vulnerable router to be<br>taken out of the field. And that hardly counts all the android boxes,<br>all the linux distros that use dnsmasq, all the containers you'll find<br>dnsmasq in, and elsewhere. Those upgrades, might only take years.<br><br>[1]<br><a href="http://bits-please.blogspot.com/2016/06/trustzone-kernel-privilege-escalation.html">http://bits-please.blogspot.com/2016/06/trustzone-kernel-privilege-escalation.html</a><br>(many others, just google for "trustzone vulnerability")<br>[2]<br><a href="http://www.zdnet.com/article/researchers-say-intels-management-engine-feature-can-be-switched-off">http://www.zdnet.com/article/researchers-say-intels-management-engine-feature-can-be-switched-off</a>/<br>[3] <a href="https://www.kb.cert.org/vuls/id/240311">https://www.kb.cert.org/vuls/id/240311</a><br>[4]<br><a href="https://arstechnica.com/information-technology/2013/09/researchers-can-slip-an-undetectable-trojan-into-intels-ivy-bridge-cpus">https://arstechnica.com/information-technology/2013/09/researchers-can-slip-an-undetectable-trojan-into-intels-ivy-bridge-cpus</a>/<br><hr><br>Cerowrt-devel mailing list<br>Cerowrt-devel@lists.bufferbloat.net<br><a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br></pre></blockquote></div></body></html>