I share your concern for updates, and support for same.

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.

There's no reason for dnsmasq to run with privileges. Not should packet parsing. All datagrams should be end to end authenticated.

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.

They were rejected as unnecessary by Unix and by the TCP decision-makers.

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.

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.


Sent from Blue
On Oct 3, 2017, at 8:50 PM, Dave Taht <dave.taht@gmail.com> wrote:
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