From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (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 2593B3BA8E for ; Mon, 9 Oct 2017 14:37:08 -0400 (EDT) Received: from smtp22.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DA33A6AF9; Mon, 9 Oct 2017 14:37:07 -0400 (EDT) Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B35A06AD3; Mon, 9 Oct 2017 14:37:07 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Mon, 09 Oct 2017 14:37:07 -0400 Received: from reed.com (localhost.localdomain [127.0.0.1]) by app15.wa-webapps.iad3a (Postfix) with ESMTP id A4A79A0081; Mon, 9 Oct 2017 14:37:07 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 9 Oct 2017 14:37:07 -0400 (EDT) X-Auth-ID: dpreed@reed.com Date: Mon, 9 Oct 2017 14:37:07 -0400 (EDT) From: dpreed@reed.com To: "Mikael Abrahamsson" Cc: valdis.kletnieks@vt.edu, "Rich Brown" , "cerowrt-devel@lists.bufferbloat.net" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20171009143707000000_70695" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <82be7dac-c30b-449d-a392-305c31b83519@reed.com> <59d8d7b6.06c3370a.2a6e1.858eSMTPIN_ADDED_BROKEN@mx.google.com> <82956.1507408920@turing-police.cc.vt.edu> Message-ID: <1507574227.67266158@apps.rackspace.com> X-Mailer: webmail/12.9.5-RC 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: Mon, 09 Oct 2017 18:37:08 -0000 ------=_20171009143707000000_70695 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ASooner or later it dawns on all security professionals that the idea of = a "provably secure system" is a pipedream. Same with systems designers work= ing on fault tolerance who are tasked with making their systems "NonStop" a= s the Tandem claim used to go.=0A =0AWhat we see here in most of the exampl= es is a failure of design, especially of modularity.=0A =0AModularity is th= ere to tame complexity, that's really its only reason to exist.=0A =0AOne t= hing that helps enforce modularity is end-to-end encryption, though there a= re other such concepts. The baseband processor shouldn't have the encryptio= n keys - it has no "need to know".=0A =0AThe bigger problem is that those w= ho design these "modules" don't understand the way to make systems containi= ng them modular. A module, for example, performs a function that can be des= cribed abstractly, without knowing what is inside it. And it should hide in= formation about "how" and "what" it does to the largest extent possible (Pa= rnas' Information Hiding Principle). There are other time-tested notions of= modular design that help.=0A =0ABut what we see often are what we used to = describe in software as "taking the listing and breaking it into files by t= earing on page boundaries". The tendency is toward throwing a grab bag of = functions on a chip that have no consistent and modular functionality. (e.g= . the so-called "chipsets" that accompany new Intel CPU releases).=0A =0AI = don't know what can be done, other than to design systems that have modular= structure where we can.=0AThe one remaining thing we can do is limit the b= ad things that can happen in a design, by compartmentalizing failure and se= curity risk using fairly strong and redundant approaches. Defense in depth.= Don't assume that your firewall will prevent errors from creeping in.=0A = =0A=0A=0AOn Monday, October 9, 2017 4:32am, "Mikael Abrahamsson" said:=0A=0A=0A=0A> On Sat, 7 Oct 2017, valdis.kletnieks@vt.edu wro= te:=0A> =0A> > Know how x86 people complain that SSM mode introduces jitter= ? That's=0A> > just the tip of the iceberg. Believe it or not, there's an e= ntire=0A> > IPv4/IPv6 stack *and a webserver* hiding in there...=0A> >=0A> = > https://schd.ws/hosted_files/ossna2017/91/Linuxcon%202017%20NERF.pdf=0A> = >=0A> > Gaak. Have some strong adult beverage handy, you'll be needing it..= ..=0A> =0A> Also see the wifi processor remote exploit that Apple devices (= and others=0A> I presume) had problems with.=0A> =0A> Mobile baseband proce= ssors behave in the same way, and also have their own=0A> stack. I have tal= ked to mobile developers who discovered all of a sudden=0A> the baseband wo= uld just silently "steal" a bunch of UDP ports from the=0A> host OS and jus= t grab these packets. At least with IPv6, the baseband can=0A> have its own= IPv6 address, separated from the host stack IPv6 addreses.=0A> =0A> Just t= o illustrate (incompletely) what might be going on when you're=0A> tetherin= g through a mobile phone.=0A> =0A> Packet comes in on the 4G interface. It = now hits the baseband processor=0A> (that runs code), which might send the = packet to either the host OS, or=0A> via an packet accelerator path (which = the host OS might or not have a=0A> control plane into), and this accelerat= or runs code, and then it hits the=0A> wifi chip, which also runs code.=0A>= =0A> So while the host OS programmer might see their host OS doing somethi= ng,=0A> in real life the packet potentially hits at least three other thing= s that=0A> run code using their own firmware. Also, these components are ma= nufactured=0A> in factories, how do we verify that these actually do what t= hey were=0A> intended to do, and not modified between design and production= ? How do we=0A> know the firmware we load is actually loaded and it's not i= ntercepted and=0A> real time patched before execution? Oh, also, the OS is = loaded from=0A> permanent storage, that is also running code. There are sev= eral talks=0A> about people modifying the storage controller (which also ru= ns code of=0A> coutse) to return different things depending on usage patter= n. So it's not=0A> safe for the OS to read data, check that it passes integ= rity checks, and=0A> then read it again, and execute. The storage might ret= urn different things=0A> the second time.=0A> =0A> I don't know that we as = humanity know how to do this securely. I've=0A> discussed this with vendors= in different sectors, and there's a lot of=0A> people who aren't even awar= e of the problem.=0A> =0A> I'd say the typical smartphone today probably ha= s 10 things or more=0A> running code/firmware, all susceptable to bugs, all= of them risked of even=0A> with exposed security problems, they're never g= oing to be patched.=0A> =0A> So the IoT problem isn't only for "smart meter= s" etc, it's for everything.=0A> We've created devices that are impossible = to verify without destroying=0A> them (sanding down ICs and looking at bill= ions of gates), and in order to=0A> verify them, you need equipment and ski= lls that are not available to most=0A> people.=0A> =0A> --=0A> Mikael Abrah= amsson email: swmike@swm.pp.se=0A> ------=_20171009143707000000_70695 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Sooner or later it= dawns on all security professionals that the idea of a "provably secure sy= stem" is a pipedream. Same with systems designers working on fault toleranc= e who are tasked with making their systems "NonStop" as the Tandem claim us= ed to go.

=0A

 

=0A

= What we see here in most of the examples is a failure of design, especially= of modularity.

=0A

 

=0A

Modularity is there to tame complexity, that's really its only reason= to exist.

=0A

 

=0A

One thing that helps enforce modularity is end-to-end encryption, though t= here are other such concepts. The baseband processor shouldn't have the enc= ryption keys - it has no "need to know".

=0A

 = ;

=0A

The bigger problem is that those who design = these "modules" don't understand the way to make systems containing them mo= dular. A module, for example, performs a function that can be described abs= tractly, without knowing what is inside it. And it should hide information = about "how" and "what" it does to the largest extent possible (Parnas' Info= rmation Hiding Principle). There are other time-tested notions of modular d= esign that help.

=0A

 

=0A

But what we see often are what we used to describe in software as "t= aking the listing and breaking it into files by tearing on page boundaries"= .  The tendency is toward throwing a grab bag of functions on a chip t= hat have no consistent and modular functionality. (e.g. the so-called "chip= sets" that accompany new Intel CPU releases).

=0A

=  

=0A

I don't know what can be done, other th= an to design systems that have modular structure where we can.

=0A

The one remaining thing we can do is limit the bad things = that can happen in a design, by compartmentalizing failure and security ris= k using fairly strong and redundant approaches. Defense in depth. Don't ass= ume that your firewall will prevent errors from creeping in.

=0A

 

=0A=0A



On Monday, October 9= , 2017 4:32am, "Mikael Abrahamsson" <swmike@swm.pp.se> said:

=0A
=0A

> O= n Sat, 7 Oct 2017, valdis.kletnieks@vt.edu wrote:
>
> >= Know how x86 people complain that SSM mode introduces jitter? That's
= > > just the tip of the iceberg. Believe it or not, there's an entire=
> > IPv4/IPv6 stack *and a webserver* hiding in there...
&= gt; >
> > https://schd.ws/hosted_files/ossna2017/91/Linuxcon%= 202017%20NERF.pdf
> >
> > Gaak. Have some strong adul= t beverage handy, you'll be needing it....
>
> Also see th= e wifi processor remote exploit that Apple devices (and others
> I = presume) had problems with.
>
> Mobile baseband processors= behave in the same way, and also have their own
> stack. I have ta= lked to mobile developers who discovered all of a sudden
> the base= band would just silently "steal" a bunch of UDP ports from the
> ho= st OS and just grab these packets. At least with IPv6, the baseband can
> have its own IPv6 address, separated from the host stack IPv6 addres= es.
>
> Just to illustrate (incompletely) what might be go= ing on when you're
> tethering through a mobile phone.
> > Packet comes in on the 4G interface. It now hits the baseband proc= essor
> (that runs code), which might send the packet to either the= host OS, or
> via an packet accelerator path (which the host OS mi= ght or not have a
> control plane into), and this accelerator runs = code, and then it hits the
> wifi chip, which also runs code.
= >
> So while the host OS programmer might see their host OS doi= ng something,
> in real life the packet potentially hits at least t= hree other things that
> run code using their own firmware. Also, t= hese components are manufactured
> in factories, how do we verify t= hat these actually do what they were
> intended to do, and not modi= fied between design and production? How do we
> know the firmware w= e load is actually loaded and it's not intercepted and
> real time = patched before execution? Oh, also, the OS is loaded from
> permane= nt storage, that is also running code. There are several talks
> ab= out people modifying the storage controller (which also runs code of
&= gt; coutse) to return different things depending on usage pattern. So it's = not
> safe for the OS to read data, check that it passes integrity = checks, and
> then read it again, and execute. The storage might re= turn different things
> the second time.
>
> I don= 't know that we as humanity know how to do this securely. I've
> di= scussed this with vendors in different sectors, and there's a lot of
&= gt; people who aren't even aware of the problem.
>
> I'd s= ay the typical smartphone today probably has 10 things or more
> ru= nning code/firmware, all susceptable to bugs, all of them risked of even> with exposed security problems, they're never going to be patched.<= br />>
> So the IoT problem isn't only for "smart meters" etc, = it's for everything.
> We've created devices that are impossible to= verify without destroying
> them (sanding down ICs and looking at = billions of gates), and in order to
> verify them, you need equipme= nt and skills that are not available to most
> people.
> > --
> Mikael Abrahamsson email: swmike@swm.pp.se
> =

=0A
 ------=_20171009143707000000_70695--