From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 622A53B2A4 for ; Wed, 4 Oct 2017 09:12:38 -0400 (EDT) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3E9375878; Wed, 4 Oct 2017 09:12:38 -0400 (EDT) X-Auth-ID: dpreed@reed.com Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender: dpreed-AT-reed.com) with ESMTPSA id 8BBC05837; Wed, 4 Oct 2017 09:12:37 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from [192.0.0.4] ([UNAVAILABLE]. [172.56.39.111]) (using TLSv1.2 with cipher AES256-SHA) by 0.0.0.0:465 (trex/5.7.12); Wed, 04 Oct 2017 09:12:38 -0400 In-Reply-To: References: X-Referenced-Uid: 35981 Thread-Topic: Re: [Cerowrt-devel] dnsmasq CVEs User-Agent: Android MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----F0VBAQ8AC1J9MB662CIN09LEJC2A4P" Content-Transfer-Encoding: 7bit From: David P Reed Date: Wed, 04 Oct 2017 06:12:33 -0700 To: Dave Taht CC: Rich Brown ,cerowrt-devel@lists.bufferbloat.net Message-ID: <82be7dac-c30b-449d-a392-305c31b83519@reed.com> Subject: Re: [Cerowrt-devel] dnsmasq CVEs X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 13:12:38 -0000 ------F0VBAQ8AC1J9MB662CIN09LEJC2A4P Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 I share your concern for updates, and support for same=2E However, there a= re architectural solutions we should have pursued a long time ago, which wo= uld bound the damage of such vulnerabilities=2E Make the system far more ro= bust=2E There's no reason for dnsmasq to run with privileges=2E Not should= packet parsing=2E All datagrams should be end to end authenticated=2E We = developed these rules in 1973-78, both in Multics and in the MIT part of th= e Internet design=2E Recommended a specific embedding of cryptography in TC= P=2E They were rejected as unnecessary by Unix and by the TCP decision-mak= ers=2E 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 resource= s it isn't supposed to=2E My personal home router is Fedora 26 Server, so I= feel very calm about using dnsmasq=2E But the "community" rejects SELinux= ! Turns it off after install=2E I know it is a pain, but it works=2E And it= is based on the Multics concepts that Unix ignored=2E The principle of lea= st privilege=2E =E2=81=A3Sent from Blue =E2=80=8B On Oct 3, 2017, 8:50 P= M, at 8:50 PM, Dave Taht wrote: >Back before I wa= s trying to keep my blood pressure reliably low, I >would have responded to= this set of dnsmasq vulns > >https://www=2Ecso=2Ecom=2Eau/article/628031/p= rehistoric-bugs-dnsmasq-strike-android-linux-google-kubernetes/ > >with an = impassioned plea to keep a financial floor under the primary >authors of ne= twork facing software as an insurance policy for network >society=2E I also= have long hoped that we would see useful risk >assessments vs costs of pre= vention emerge from network vulnerable >companies and insurance houses=2E >= >Billions of devices run dnsmasq, and it had been through multiple >securi= ty audits before now=2E Simon had done the best job possible, I >think=2E H= e got beat=2E No human and no amount of budget would have found >these prob= lems before now, and now we face the worldwide costs, yet >again, of someth= ing ubiquitous now, vulnerable=2E > >I'd long hoped, also, we'd see rapid u= pdates enter the entire IoT >supply chain, which remains a bitter joke=2E "= Prehistoric" versions of >dnsmasq litter that landscape, and there is no wa= y they will ever be >patched, and it would be a good bet that many "new" de= vices for the >next several years will ship with a vulnerable version=2E > = >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=2E > >http://www= =2Ekb=2Ecert=2Eorg/vuls/byvendor?searchview&Query=3DFIELD+Reference=3D97352= 7&SearchOrder=3D4 > >I am glad to see lede and google reacting so fast to d= istribute >updates=2E=2E=2E and I'm sure the container folk and linux distr= os will also >react quickly=2E=2E=2E > >=2E=2E=2E but, it will take decade= s for the last vulnerable router to be >taken out of the field=2E And that = hardly counts all the android boxes, >all the linux distros that use dnsmas= q, all the containers you'll find >dnsmasq in, and elsewhere=2E Those upgra= des, might only take years=2E > >[1] >http://bits-please=2Eblogspot=2Ecom/2= 016/06/trustzone-kernel-privilege-escalation=2Ehtml >(many others, just goo= gle for "trustzone vulnerability") >[2] >http://www=2Ezdnet=2Ecom/article/r= esearchers-say-intels-management-engine-feature-can-be-switched-off/ >[3] h= ttps://www=2Ekb=2Ecert=2Eorg/vuls/id/240311 >[4] >https://arstechnica=2Ecom= /information-technology/2013/09/researchers-can-slip-an-undetectable-trojan= -into-intels-ivy-bridge-cpus/ >____________________________________________= ___ >Cerowrt-devel mailing list >Cerowrt-devel@lists=2Ebufferbloat=2Enet >h= ttps://lists=2Ebufferbloat=2Enet/listinfo/cerowrt-devel ------F0VBAQ8AC1J9MB662CIN09LEJC2A4P Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I share your concern for updates= , and support for same=2E

However, there ar= e architectural solutions we should have pursued a long time ago, which wou= ld bound the damage of such vulnerabilities=2E Make the system far more rob= ust=2E

There's no reason for dnsmasq to run= with privileges=2E Not should packet parsing=2E All datagrams should be en= d to end authenticated=2E

We developed thes= e rules in 1973-78, both in Multics and in the MIT part of the Internet des= ign=2E Recommended a specific embedding of cryptography in TCP=2E

They were rejected as unnecessary by Unix and by the= TCP decision-makers=2E

Now Fedora Server u= ses SELinux in it's packaged version of dnsmasq, so dnsmasq can't do anythi= ng it is not permitted to do, or access resources it isn't supposed to=2E M= y personal home router is Fedora 26 Server, so I feel very calm about using= dnsmasq=2E

But the "community" rejects SEL= inux! Turns it off after install=2E I know it is a pain, but it works=2E An= d it is based on the Multics concepts that Unix ignored=2E The principle of= least privilege=2E


Sent from Blue
On Oct = 3, 2017, at 8:50 PM, Dave Taht <dave=2Etaht@gmail=2Ecom> wrote:
Back befor=
e I was trying to keep my blood pressure reliably low, I
would have resp=
onded to this set of dnsmasq vulns

https://www=2Ecso=2Ecom=2Eau/article/628031/prehistoric-bugs-dn=
smasq-strike-android-linux-google-kubernetes/

with an impassione=
d plea to keep a financial floor under the primary
authors of network fa=
cing software as an insurance policy for network
society=2E I also have =
long hoped that we would see useful risk
assessments vs costs of prevent=
ion emerge from network vulnerable
companies and insurance houses=2E
=

Billions of devices run dnsmasq, and it had been through multiple
se=
curity audits before now=2E Simon had done the best job possible, I
thin=
k=2E He got beat=2E No human and no amount of budget would have found
th=
ese problems before now, and now we face the worldwide costs, yet
again,=
 of something ubiquitous now, vulnerable=2E

I'd long hoped, also, we=
'd see rapid updates enter the entire IoT
supply chain, which remains a =
bitter joke=2E "Prehistoric" versions of
dnsmasq litter that landscape, =
and there is no way they will ever be
patched, and it would be a good be=
t that many "new" devices for the
next several years will ship with a vu=
lnerable version=2E

I've grown quite blase' I guess, since heartblee=
d, and the latest list
of stuff[1,2,3,4] that scared me only just last w=
eek, is now topped by
this one, affecting a humongous list of companies =
and products=2E

http=
://www=2Ekb=2Ecert=2Eorg/vuls/byvendor?searchview&Query=3DFIELD+Referen=
ce=3D973527&SearchOrder=3D4

I am glad to see lede and google=
 reacting so fast to distribute
updates=2E=2E=2E and I'm sure the contai=
ner folk and linux distros will also
react quickly=2E=2E=2E

=2E=
=2E=2E but,  it will take decades for the last vulnerable router to be
t=
aken out of the field=2E And that hardly counts all the android boxes,
a=
ll the linux distros that use dnsmasq, all the containers you'll find
dn=
smasq in, and elsewhere=2E Those upgrades, might only take years=2E

=
[1]
http://bits-please=2Eblogspot=2Ecom/2016/0=
6/trustzone-kernel-privilege-escalation=2Ehtml
(many others, just go=
ogle for "trustzone vulnerability")
[2]
http://www=2Ezdnet=2Ecom/article/researchers-say-intels-managemen=
t-engine-feature-can-be-switched-off/
[3] https://www=2Ekb=2Ecert=2Eorg/vuls/id/240311=

[4]
https://arstechnica=2Ecom/information-technology/2013/09/researchers-=
can-slip-an-undetectable-trojan-into-intels-ivy-bridge-cpus/
Cerowrt-devel mailing list
Cerowrt-devel@lists=2Ebufferbloat=2Enet
<=
a href=3D"https://lists=2Ebufferbloat=2Enet/listinfo/cerowrt-devel">https:/=
/lists=2Ebufferbloat=2Enet/listinfo/cerowrt-devel
------F0VBAQ8AC1J9MB662CIN09LEJC2A4P--