[Cerowrt-devel] dnsmasq cves

[Cerowrt-devel] dnsmasq cves

[Dave Taht]

If you are still running cerowrt, stop and switch to lede.

https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cerowrt-devel] dnsmasq CVEs

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 4979 bytes --]


Sooner or later it dawns on all security professionals that the idea of a "provably secure system" is a pipedream. Same with systems designers working on fault tolerance who are tasked with making their systems "NonStop" as the Tandem claim used to go.
 
What we see here in most of the examples is a failure of design, especially of modularity.
 
Modularity is there to tame complexity, that's really its only reason to exist.
 
One thing that helps enforce modularity is end-to-end encryption, though there are other such concepts. The baseband processor shouldn't have the encryption keys - it has no "need to know".
 
The bigger problem is that those who design these "modules" don't understand the way to make systems containing them modular. A module, for example, performs a function that can be described abstractly, without knowing what is inside it. And it should hide information about "how" and "what" it does to the largest extent possible (Parnas' Information Hiding Principle). There are other time-tested notions of modular design that help.
 
But what we see often are what we used to describe in software as "taking 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 that have no consistent and modular functionality. (e.g. the so-called "chipsets" that accompany new Intel CPU releases).
 
I don't know what can be done, other than to design systems that have modular structure where we can.
The one remaining thing we can do is limit the bad things that can happen in a design, by compartmentalizing failure and security risk using fairly strong and redundant approaches. Defense in depth. Don't assume that your firewall will prevent errors from creeping in.
 


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



> 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
> 

[-- Attachment #2: Type: text/html, Size: 7311 bytes --]

Re: [Cerowrt-devel] dnsmasq CVEs

[Dave Taht]

Mikael Abrahamsson <swmike@swm.pp.se> writes:

> On Sat, 7 Oct 2017, valdis.kletnieks@vt.edu wrote:
>
>> Know how x86 people complain that SSM mode introduces jitter?

I'm a really jitter-sensitive person. my life is warped by trying to
achieve hard realtime (meaning - *0* missed deadlines in a variety of
OSes and products - everything from rockets to brakes, to medical and
safety systems to DAW's like "ardour.org"). Achieving hard deadlines
below 5ms in modern processors and OSes is incredibly difficult.

Everyone (else) seems willing to sacrifice a little latency here or
there for their special feature - power management, SSM, sidechannel
uploads to various government agencies, whathaveyou.

In walking down the street, dodging the smart cars...

I try really hard to not think about all the stuff out there that works
correctly only 99.9999% of the time, but I still perpetually flash on
Monty Python's character of "Mr Bledsoe", who explodes after adding on
one additional wafer thin mint, everytime I learn of some new "feature"
in some chip, that costs latency and/or jitter, that you cannot control.

Anyway, my larger point is, a reason why we are seeing this explosion of
dedicated processors for various things is that the main cpus - even
with a ton of cores on die - can no longer reliably meet hard RT
deadlines, and either you try to make a really complicated OS (linux) do
RT within that flakyness - or you graft on the needed features - like,
ugh - a web server - on a harder RT os running on a dedicated chip.

I'd like good harder-rt performance to become a priority again on
mainstream cpus.

For example, I'd have a dedicated i and d-cache for interrupt handling.

(I mentioned the mill on this thread. Interrupt context switch is 3-5
clocks, vs 1000s for intel. I also get a kick out of the propeller
architecture - one cpu per I/O)

>> 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.

This was a really good summary, thank you. A couple comments:

Bugs tend to accumulate at the edges between interfaces, also.

I don't actually make much difference between bugs and security bugs. At
the moment, I'm catching up on Brin's "Transparent society".

And for an example of one way forward, read larry niven's "safe at any speed".

Re: [Cerowrt-devel] dnsmasq CVEs

[Mikael Abrahamsson]

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

Re: [Cerowrt-devel] dnsmasq CVEs

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 5072 bytes --]

  
  
Interesting. If stack pops zeroed memory, a stack machine would fix the subroutine call privilege drop issue. Also register zeroing on syscall return avoids privilege leaks. Linux on Intel 64 doesn't do this :-(
  

  
The mill is very interesting.   
  

  
One concern, I have recently realized that it is not fully open like RISC-V. I don't blame its    developers for wanting a ROI. But adoption may require rethinking that choice. These days, shared standardized infrastructure tends to require open adoptability.
  
  

  
  
  
  
  
>   
> On Oct 7, 2017 at 4:28 PM,  <Dave Taht>  wrote:
>   
>   
>  I misstated something, fix below. On Sat, Oct 7, 2017 at 11:32 AM, Dave Taht wrote:  >  On Sat, Oct 7, 2017 at 6:33 AM, dpreed wrote:  >>  No disagreement here. I saw a wonderful discussion recently by a researcher  >>  at Mentor Graphics about 2 things: VLSI design hacking and low level  >>  interconnect hacking. Things we call "hardware" and just assume are designed  >>  securely. Was this filmed, btw?  >>  They are not. The hardware designers at the chip and board level know little  >>  or nothing about security techniques. They don't work with systems people  >>  who build with their hardware to limit undefined or covert behaviors.  >>   >>  Systems people in turn make unreasonable and often wrong assumptions about  >>  what is hard about hardware. Assumptions about what it won't do, in  >>  particular.  >>   >>  We need to treat hardware like we treat software. Full of bugs, easily  >>  compromised. There are approaches to reliability and security that we know,  >>  that are tractable. But to apply them we need to drop the fictional idea  >>  that hardware is hard... It's soft.  >   >  hardware design tools and software seem stuck in the 80s.  >   >>  The principle of least privilege is one of those.  >   >  Everybody here probably knows by now how much I am a mill cpu fan.  >   >  The principle of least privs, on a mill, can apply to individual subroutines.  >   >  The talk (it's up at [0], but because it has to cover so much prior  >  material doesn't really get rolling till slide 30) highlighted how  >  they do secure IPC, and transfer memory access privs around, cheaply.  >   >  One thing I hadn't realized was that the belt concept[1] resulted in  >  having no register "rubble" left over from making a normal... or! IPC  >  call that changed privs. Say you have a belt with values like:  >   >  3|4|2|1|5|6|7|8  >   >  a subroutine call, with arguments  >   >  jsr somewhere,b1,b4,b3  >   >  creates a new belt (so the called routine sees no other registers from  >  the caller)  >   >  4,5,1,X,X,X,X,X # (the mill has a concept of "not a value, or NAR")  >   >  On a return, the same idea applies, where the return values are dropped  >  at the head of the callee's belt. head of the callers belt, I meant.  >  callee does some work:  >   >  8|1|2|3|6|2|7|1  >  ...  >  retn b1,b5  >   >  Which drops those two values only on the callers belt, and discards  >  everything else. SSA, everywhere.  >   >  callee belt becomes: caller belt becomes  >   >  1|2|3|4|2|1|5|6  >   >  This makes peer to peer based secure IPC (Where normally you'd have a  >  priv escalation call like syscall, or attempt sandboxing) a snap,  >  instead of making a jsr, you make a "portal" call, which also ets up  >  memory perms, etc.  >   >  Me trying to explain here how they handle priv (de)escalation  >  (switching between "turfs" and so on) is way beyond the scope of what  >  I could write here, let me just say their work is computer  >  architecture Pr0n of the highest order, and I've lost many, many  >  weekends to grokking it all. [2].  >   >>  The end to end argument  >>  should be applied to bus protocols like CAN, for the same reason.  >   >  Too late!  >   >  [0] https://millcomputing.com/docs/inter-process-communication/  >  [1] https://en.wikipedia.org/wiki/Belt_machine  >  [2] https://millcomputing.com/docs/  >   >>   >>  On Oct 4, 2017 at 12:38 PM, wrote:  >>   >>  well, I still think the system is rotten to its (cpu) cores and much  >>  better hardware support for security is needed to start from in order  >>  to have better software. Multics pioneered a few things in that  >>  department as I recall, but research mostly died in the 90s...  >>   >>  Blatant Plug: The mill cpu folk are giving a talk about how they do  >>  secure interprocess communication tonight in san jose, ca. I'm going.  >>  While I expect to be cheered up by the design (the underlying  >>  architecture supports memory protections down to the byte, not page,  >>  level, and may be largely immune to ROP) - I expect to be depressed by  >>  how far away they still remain from building the darn thing.  >>   >>  https://millcomputing.com/event/inter-process-communication-talk-on-october-4-2017/  >>   >>   >   >   >   >  --  >   >  Dave Täht  >  CEO, TekLibre, LLC  >  http://www.teklibre.com  >  Tel: 1-669-226-2619 -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619  
>   
     

[-- Attachment #2: Type: text/html, Size: 5740 bytes --]

Re: [Cerowrt-devel] dnsmasq CVEs

[valdis.kletnieks]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On Sat, 07 Oct 2017 09:33:34 -0400, dpreed said:

> They are not. The hardware designers at the chip and board level know little
> or nothing about security techniques. They don't work with systems people who
> build with their hardware to limit undefined or covert behaviors.

It's worse than that.  The hardware people are now intentionally building the
chipsets with covert behavior baked right into the chip.

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....

[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]

Re: [Cerowrt-devel] dnsmasq CVEs

[Dave Taht]

I misstated something, fix below.

On Sat, Oct 7, 2017 at 11:32 AM, Dave Taht <dave.taht@gmail.com> wrote:
> On Sat, Oct 7, 2017 at 6:33 AM, dpreed <dpreed@reed.com> wrote:
>> No disagreement here. I saw a wonderful discussion recently by a researcher
>> at Mentor Graphics about 2 things: VLSI design hacking and low level
>> interconnect hacking. Things we call "hardware" and just assume are designed
>> securely.

Was this filmed, btw?

>> They are not. The hardware designers at the chip and board level know little
>> or nothing about security techniques. They don't work with systems people
>> who build with their hardware to limit undefined or covert behaviors.
>>
>> Systems people in turn make unreasonable and often wrong assumptions about
>> what is hard about hardware. Assumptions about what it won't do, in
>> particular.
>>
>> We need to treat hardware like we treat software. Full of bugs, easily
>> compromised. There are approaches to reliability and security that we know,
>> that are tractable. But to apply them we need to drop the fictional idea
>> that hardware is hard... It's soft.
>
> hardware design tools and software seem stuck in the 80s.
>
>> The principle of least privilege is one of those.
>
> Everybody here probably knows by now how much I am a mill cpu fan.
>
> The principle of least privs, on a mill, can apply to individual subroutines.
>
> The talk (it's up at [0], but because it has to cover so much prior
> material doesn't really get rolling till slide 30) highlighted how
> they do secure IPC, and transfer memory access privs around, cheaply.
>
> One thing I hadn't realized was that the belt concept[1] resulted in
> having no register "rubble" left over from making a normal... or! IPC
> call that changed privs. Say you have a belt with values like:
>
> 3|4|2|1|5|6|7|8
>
> a subroutine call, with arguments
>
> jsr somewhere,b1,b4,b3
>
> creates a new belt (so the called routine sees no other registers from
> the caller)
>
> 4,5,1,X,X,X,X,X # (the mill has a concept of "not a value, or NAR")
>
> On a return, the same idea applies, where the return values are dropped
> at the head of the callee's belt.

head of the callers belt, I meant.

> callee does some work:
>
> 8|1|2|3|6|2|7|1
> ...
> retn b1,b5
>
> Which drops those two values only on the callers belt, and discards
> everything else. SSA, everywhere.
>
> callee belt becomes:

caller belt becomes
>
> 1|2|3|4|2|1|5|6
>
> This makes peer to peer based secure IPC (Where normally you'd have a
> priv escalation call like syscall, or attempt sandboxing) a snap,
> instead of making a jsr, you make a "portal" call, which also ets up
> memory perms, etc.
>
> Me trying to explain here how they handle priv (de)escalation
> (switching between "turfs" and so on) is way beyond the scope of what
> I could write here, let me just say their work is computer
> architecture Pr0n of the highest order, and I've lost many, many
> weekends to grokking it all. [2].
>
>> The end to end argument
>> should be applied to bus protocols like CAN, for the same reason.
>
> Too late!
>
> [0] https://millcomputing.com/docs/inter-process-communication/
> [1] https://en.wikipedia.org/wiki/Belt_machine
> [2] https://millcomputing.com/docs/
>
>>
>> On Oct 4, 2017 at 12:38 PM, <Dave Taht> wrote:
>>
>> well, I still think the system is rotten to its (cpu) cores and much
>> better hardware support for security is needed to start from in order
>> to have better software. Multics pioneered a few things in that
>> department as I recall, but research mostly died in the 90s...
>>
>> Blatant Plug: The mill cpu folk are giving a talk about how they do
>> secure interprocess communication tonight in san jose, ca. I'm going.
>> While I expect to be cheered up by the design (the underlying
>> architecture supports memory protections down to the byte, not page,
>> level, and may be largely immune to ROP) - I expect to be depressed by
>> how far away they still remain from building the darn thing.
>>
>> https://millcomputing.com/event/inter-process-communication-talk-on-october-4-2017/
>>
>>
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cerowrt-devel] dnsmasq CVEs

[Dave Taht]

On Sat, Oct 7, 2017 at 6:33 AM, dpreed <dpreed@reed.com> wrote:
> No disagreement here. I saw a wonderful discussion recently by a researcher
> at Mentor Graphics about 2 things: VLSI design hacking and low level
> interconnect hacking. Things we call "hardware" and just assume are designed
> securely.
>
> They are not. The hardware designers at the chip and board level know little
> or nothing about security techniques. They don't work with systems people
> who build with their hardware to limit undefined or covert behaviors.
>
> Systems people in turn make unreasonable and often wrong assumptions about
> what is hard about hardware. Assumptions about what it won't do, in
> particular.
>
> We need to treat hardware like we treat software. Full of bugs, easily
> compromised. There are approaches to reliability and security that we know,
> that are tractable. But to apply them we need to drop the fictional idea
> that hardware is hard... It's soft.

hardware design tools and software seem stuck in the 80s.

> The principle of least privilege is one of those.

Everybody here probably knows by now how much I am a mill cpu fan.

The principle of least privs, on a mill, can apply to individual subroutines.

The talk (it's up at [0], but because it has to cover so much prior
material doesn't really get rolling till slide 30) highlighted how
they do secure IPC, and transfer memory access privs around, cheaply.

One thing I hadn't realized was that the belt concept[1] resulted in
having no register "rubble" left over from making a normal... or! IPC
call that changed privs. Say you have a belt with values like:

3|4|2|1|5|6|7|8

a subroutine call, with arguments

jsr somewhere,b1,b4,b3

creates a new belt (so the called routine sees no other registers from
the caller)

4,5,1,X,X,X,X,X # (the mill has a concept of "not a value, or NAR")

On a return, the same idea applies, where the return values are dropped
at the head of the callee's belt.

callee does some work:

8|1|2|3|6|2|7|1
...
retn b1,b5

Which drops those two values only on the callers belt, and discards
everything else. SSA, everywhere.

callee belt becomes:

1|2|3|4|2|1|5|6

This makes peer to peer based secure IPC (Where normally you'd have a
priv escalation call like syscall, or attempt sandboxing) a snap,
instead of making a jsr, you make a "portal" call, which also ets up
memory perms, etc.

Me trying to explain here how they handle priv (de)escalation
(switching between "turfs" and so on) is way beyond the scope of what
I could write here, let me just say their work is computer
architecture Pr0n of the highest order, and I've lost many, many
weekends to grokking it all. [2].

> The end to end argument
> should be applied to bus protocols like CAN, for the same reason.

Too late!

[0] https://millcomputing.com/docs/inter-process-communication/
[1] https://en.wikipedia.org/wiki/Belt_machine
[2] https://millcomputing.com/docs/

>
> On Oct 4, 2017 at 12:38 PM, <Dave Taht> wrote:
>
> well, I still think the system is rotten to its (cpu) cores and much
> better hardware support for security is needed to start from in order
> to have better software. Multics pioneered a few things in that
> department as I recall, but research mostly died in the 90s...
>
> Blatant Plug: The mill cpu folk are giving a talk about how they do
> secure interprocess communication tonight in san jose, ca. I'm going.
> While I expect to be cheered up by the design (the underlying
> architecture supports memory protections down to the byte, not page,
> level, and may be largely immune to ROP) - I expect to be depressed by
> how far away they still remain from building the darn thing.
>
> https://millcomputing.com/event/inter-process-communication-talk-on-october-4-2017/
>
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cerowrt-devel] dnsmasq CVEs

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

 
 
No disagreement here. I saw a wonderful discussion recently by a researcher at Mentor Graphics about 2 things: VLSI design hacking and low level interconnect hacking. Things we call "hardware" and just assume are designed securely.
 

 
They are not. The hardware designers at the chip and board level know little or nothing about security techniques. They don't work with systems people who build with their hardware to limit undefined or covert behaviors.
 

 
Systems people in turn make unreasonable and often wrong assumptions about what is hard about hardware. Assumptions about what it won't do, in particular.
 

 
We need to treat hardware like we treat software. Full of bugs, easily compromised. There are approaches to reliability and security that we know, that are tractable. But to apply them we need to drop the fictional idea that hardware is hard... It's soft.
 

 
The principle of least privilege is one of those. The end to end argument should be applied to bus protocols like CAN, for the same reason.
 
 
 

 
 
 
 
 
>  
> On Oct 4, 2017 at 12:38 PM,  <Dave Taht>  wrote:
>  
>  
>  well, I still think the system is rotten to its (cpu) cores and much better hardware support for security is needed to start from in order to have better software. Multics pioneered a few things in that department as I recall, but research mostly died in the 90s... Blatant Plug: The mill cpu folk are giving a talk about how they do secure interprocess communication tonight in san jose, ca. I'm going. While I expect to be cheered up by the design (the underlying architecture supports memory protections down to the byte, not page, level, and may be largely immune to ROP) - I expect to be depressed by how far away they still remain from building the darn thing. https://millcomputing.com/event/inter-process-communication-talk-on-october-4-2017/ 
>  
     

[-- Attachment #2: Type: text/html, Size: 2175 bytes --]

Re: [Cerowrt-devel] dnsmasq CVEs

[Dave Taht]

well, I still think the system is rotten to its (cpu) cores and much
better hardware support for security is needed to start from in order
to have better software. Multics pioneered a few things in that
department as I recall, but research mostly died in the 90s...

Blatant Plug: The mill cpu folk are giving a talk about how they do
secure interprocess communication tonight in san jose, ca. I'm going.
While I expect to be cheered up by the design (the underlying
architecture supports memory protections down to the byte, not page,
level, and may be largely immune to ROP) - I expect to be depressed by
how far away they still remain from building the darn thing.

https://millcomputing.com/event/inter-process-communication-talk-on-october-4-2017/

Re: [Cerowrt-devel] dnsmasq CVEs

[David P Reed]

[-- Attachment #1: Type: text/plain, Size: 3741 bytes --]

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, 8:50 PM, 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

[-- Attachment #2: Type: text/html, Size: 5137 bytes --]

Re: [Cerowrt-devel] dnsmasq CVEs

[Dave Taht]

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/

Re: [Cerowrt-devel] dnsmasq CVEs

[Rich Brown]

> On Oct 3, 2017, at 12:00 PM, Dave wrote:
> 
> If you are still running cerowrt, stop and switch to lede.
> 
> https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html

LEDE 17.01.3 (third stable release) is currently being built with dnsmasq 2.78 that fixes those CVEs. It should be available for all platforms in less than 48 hours.