Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: valdis.kletnieks@vt.edu
Cc: dpreed <dpreed@reed.com>, Rich Brown <richb.hanover@gmail.com>,
	 "cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] dnsmasq CVEs
Date: Mon, 9 Oct 2017 10:32:26 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1710091016390.31961@uplift.swm.pp.se> (raw)
In-Reply-To: <82956.1507408920@turing-police.cc.vt.edu>

On 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...
>
> https://schd.ws/hosted_files/ossna2017/91/Linuxcon%202017%20NERF.pdf
>
> Gaak.  Have some strong adult beverage handy, you'll be needing it....

Also see the 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 talked to mobile developers who discovered all of a sudden 
the baseband would just silently "steal" a bunch of UDP ports from the 
host OS and just grab these packets. At least with IPv6, the baseband can 
have its own IPv6 address, separated from the host stack IPv6 addreses.

Just to illustrate (incompletely) what might be going on when you're 
tethering through a mobile phone.

Packet comes in on the 4G interface. It now hits the baseband processor 
(that runs code), which might send the packet to either the host OS, or 
via an packet accelerator path (which the host OS might 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 doing something, 
in real life the packet potentially hits at least three other things that 
run code using their own firmware. Also, these components are manufactured 
in factories, how do we verify that these actually do what they were 
intended to do, and not modified between design and production? How do we 
know the firmware we load is actually loaded and it's not intercepted and 
real time patched before execution? Oh, also, the OS is loaded from 
permanent storage, that is also running code. There are several talks 
about people modifying the storage controller (which also runs code of 
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 return different things 
the second time.

I don't know that we as humanity know how to do this securely. I've 
discussed this with vendors in different sectors, and there's a lot of 
people who aren't even aware of the problem.

I'd say the typical smartphone today probably has 10 things or more 
running code/firmware, all susceptable to bugs, all of them risked of even 
with exposed security problems, they're never going to be patched.

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 equipment and skills that are not available to most 
people.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

  reply	other threads:[~2017-10-09  8:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04  0:43 Rich Brown
2017-10-04  3:49 ` Dave Taht
2017-10-04 13:12   ` David P Reed
2017-10-04 16:38     ` Dave Taht
2017-10-07 13:33       ` dpreed
2017-10-07 20:54         ` dpreed
     [not found]     ` <59d8d7ae.5b37c80a.9c70e.c057SMTPIN_ADDED_BROKEN@mx.google.com>
2017-10-07 18:32       ` Dave Taht
2017-10-07 20:28         ` Dave Taht
     [not found]     ` <59d8d7b6.06c3370a.2a6e1.858eSMTPIN_ADDED_BROKEN@mx.google.com>
2017-10-07 20:42       ` valdis.kletnieks
2017-10-09  8:32         ` Mikael Abrahamsson [this message]
2017-10-09 17:33           ` Dave Taht
2017-10-09 18:37           ` dpreed
  -- strict thread matches above, loose matches on Subject: below --
2017-10-02 18:18 [Cerowrt-devel] dnsmasq cves Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1710091016390.31961@uplift.swm.pp.se \
    --to=swmike@swm.pp.se \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dpreed@reed.com \
    --cc=richb.hanover@gmail.com \
    --cc=valdis.kletnieks@vt.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox