
Behind the Masq: Yet More DNS and DHCP Vulnerabilities - philips
https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html
======
pbhjpbhj
Meta: that page is impossible to read for me on Firefox mobile - if I pinch
zoom, or scroll, and move left or right slightly Google "helpfully" send me to
a different page.

How many millions did Google spend optimising the code that makes that page
useless for anyone who wants to zoom in on mobile? Man, that, wow, I can't
express how terrible that is, Google, really!?

Edit: they have a "web version"
([https://security.googleblog.com/2017/10/behind-masq-yet-
more...](https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-
dhcp.html?m=0)) without that massive UX bug, where instead you can't scroll to
see the table. smh

~~~
mkj
Not just that page - the entirety of Blogspot/Blogger has that problem! Easy
to accidentally do on Android Chrome too.

------
lol768
So were these vulnerabilities present, and missed by Cure53's audit
([https://wiki.mozilla.org/images/f/f7/Dnsmasq-
report.pdf](https://wiki.mozilla.org/images/f/f7/Dnsmasq-report.pdf))?

~~~
fulafel
Probably.

It's well known that it's generally (and practically) intractable to find all
vulnerabilities in a typical networked C program using reasonable auditing
effort. If auditing worked, we would know how to secure C programs and the
world would be a much different place.

~~~
throwme211345
But we do know how to write secure C. It's just time consuming and requires
discipline. Two things that most developers don't have or want.

~~~
Xylakant
That seems to indicate “we” as a profession don’t actually know. Because the
developer is always part of writing the code and thus, any process that
results in C-Code has at least one insecure element.

~~~
throwme211345
"We" is inclusive - 'most developers' is exclusive. Mystery solved.

------
userbinator
My experience with implementations of these protocols is mostly from embedded
systems, but I was under the impression that they could and should be written
with almost no dynamic allocation at all, since everything has very small and
fixed sizes. To see so many overflows and other dynamic-allocation related
bugs is thus a little surprising.

Also interesting to note that 3 of the 7 in the list definitely appear to be
in handling of IPv6-related parts of the protocol.

------
viraptor
The part that makes me happy is:

> In addition to these patches we have also submitted another patch which will
> run Dnsmasq under seccomp-bpf to allow for additional sandboxing.

It takes a while, but the more known projects start getting seccomp patches
and this will lower the impact of exploits like this in the future.

~~~
irundebian
Still I was very negatively surprised about the code complexity of the seccomp
integration.

~~~
viraptor
It's a very detailed implementation by dedicated people. It includes the
namespace setup and mounts. It's not a great thing to show off IMO.

You can get good results with much smaller implementations too. See my patch
to memcached for example:
[https://github.com/memcached/memcached/pull/275/files](https://github.com/memcached/memcached/pull/275/files)

~~~
irundebian
Thank you.

------
jlgaddis
Damn, there's gonna be a _LOT_ of home/SOHO-type routers out there that are
affected by this. I expect we'll see some exploits for these devices in the
near future.

~~~
agwa
Of the three RCEs, two of them are in the DHCP server subsystem, which means
they can only be exploited by a device that successfully authenticates to your
local network.

The other RCE is in the DNS subsystem, and can apparently be exploited by
making a PTR record lookup to an attacker-controlled DNS server:

[https://github.com/google/security-research-
pocs/blob/master...](https://github.com/google/security-research-
pocs/blob/master/vulnerabilities/dnsmasq/CVE-2017-14491-instructions.txt)

My first question is: can you induce people to make PTR lookups? I don't think
there's a way to make a browser do a PTR lookup, which may limit the remote
exploitability of this vulnerability.

My second question is: can the vulnerability be exploited with an A/AAAA
record lookup instead? If so, that would open a very devastating remote attack
vector, as a website would need only include a hidden image tag pointing to an
attacker-controlled domain in order to get RCE on someone's router.

~~~
agwa
The author of dnsmasq says it has to be a PTR lookup:
[https://twitter.com/SimonRKelley/status/914918747978305537](https://twitter.com/SimonRKelley/status/914918747978305537)

That's very good news.

Edit: never mind, he says a CNAME answer to a A/AAAA query can trigger
vulnerability. That's very bad news.

~~~
AndyMcConachie
If that's true this is really really bad news. I mean I can't even begin to
describe how bad this is.

~~~
Ajedi32
According to the blog post, that CVE (CVE-2017-14491) only allows a 2-byte
overflow on Dnsmasq >=2.76, so hopefully that's enough to prevent it from
being exploited effectively.

2.76 was only released 16 months ago though. There are probably tons of router
firmwares out there that are way older than that.

~~~
fulafel
It's unlikely that even the latest firmwares follow dnsmasq releases that
closely, safe to assume that ~ all CPE devices are wormable.

(And most of the devices out there will never get updated even after this,
just replaced one day)

------
philips
This affects all versions of Kubernetes between 1.5.0 and 1.7.6.

Relevant posts:

\- [https://groups.google.com/forum/#!topic/kubernetes-
dev/QWIzh...](https://groups.google.com/forum/#!topic/kubernetes-
dev/QWIzhD3JhhE)

\- [https://coreos.com/blog/dns-vulnerability-patched-in-
kuberne...](https://coreos.com/blog/dns-vulnerability-patched-in-kubernetes-
and-tectonic)

~~~
bboreham
I'm wondering how exploitable this is. Kube-dns doesn't listen outside of the
cluster, so to you need to be able to run arbitrary code inside the cluster to
make use of it.

Then it lets you escape to the dnsmasq container. Which does have a shell, but
I'm struggling to think how this gets you more capability than "able to run
arbitrary code inside the cluster".

Most likely I missed something. Help me spot it.

~~~
dward
It is far harder to exploit on Kubernetes then on a laptop running a dnsmasq
cache attached to a starbucks wifi.

You would need to middle man traffic between dnsmasq and upstream DNS or have
some control over DNS records and be able to force dnsmasq to do lookups. As
you point out the escalation is also far more limited. Ok, so you have a shell
in the dnsmasq container. Now what?

------
kubov
Think of all OpenWrt/dd-wrt devices - and possibly countless router-boxes
around the world that use some proprietary firmware along with dnsmasq.

Just verified that my home OpenWrt WDR4300 is affected.

~~~
hathawsh
OpenWrt 15.05.1 "Chaos Calmer" was released more than a year ago. I haven't
seen many updates. I wonder if there's an update channel that I'm missing.

Specifically, here is where all updates are coming from:
[https://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/ge...](https://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/packages/base/)

No updates since March 2016.

EDIT: Has development has moved to the LEDE project? I don't understand what's
happening in the OpenWRT/LEDE split. There appears to be a fairly clean
upgrade path, though: [https://forum.lede-project.org/t/upgrade-from-openwrt-
to-led...](https://forum.lede-project.org/t/upgrade-from-openwrt-to-lede-does-
the-config-compatible/6252)

~~~
e12e
Yes, you probably want Lede, not OpenWRT or dd-wrt. I used lede to flash some
old routers last year, and on the whole the experience was similar to my last
interaction with OpenWRT only better (more evolved).

[https://lede-project.org/start](https://lede-project.org/start)

~~~
gurrone
I would like to add that you can usually in place upgrade from OpenWRT to
LEDE. Though making a config backup and a backup of the list of additional
packages you installed is highly recommended. Beside of that just flash and
reinstall all additional packages.

~~~
hathawsh
Upgrading to LEDE worked flawlessly. Thanks guys!

------
tomatcloudshark
Here are some PCAPs of the PoCs from the GitHub repo:

CVE-2017-14491.pcap:
[https://www.cloudshark.org/captures/016080cbeab5](https://www.cloudshark.org/captures/016080cbeab5)

CVE-2017-14492.pcap:
[https://www.cloudshark.org/captures/fd4bfa9403fc](https://www.cloudshark.org/captures/fd4bfa9403fc)

CVE-2017-14493.pcap:
[https://www.cloudshark.org/captures/1c30b56dc1d3](https://www.cloudshark.org/captures/1c30b56dc1d3)

CVE-2017-14494.pcap:
[https://www.cloudshark.org/captures/657de976c0d1](https://www.cloudshark.org/captures/657de976c0d1)

Used this repo to generate these: [https://github.com/google/security-
research-pocs/tree/master...](https://github.com/google/security-research-
pocs/tree/master/vulnerabilities/dnsmasq)

------
tareqak
How should/would we design routers and any Internet-connected device that we
expect the users to not patch themselves? e.g. SOHO users.

Let's not get into the discussion of whether or not everything that can be
connected to the Internet should be. (I'm in the "should not be connected
camp", but I think my question can stand on its own without this discussion).

~~~
hannob
The first answer is obviously auto-updates.

The second answer is also obvious: Try to avoid as many bugs as possible
_before_ shipping the product. If you include a highly exposed software like
dnsmasq make sure you look for bugs in it before shipping it.

I don't remember having seen any professional security audit for dnsmasq
before. Such an audit is probably an almost irrelevant expense for all the
router manufacturers out there, yet none of them chose to fund one...

~~~
sitkack
The other one is that embedded devices need to running their components in
sandboxes.

~~~
gcp
To be honest, a compromised dnsmasq can do quite a lot of harm even if it is
running in a sandbox. The rest of the system expects to trust the output.

------
mkj
Is there any indication how these vulnerabilities were found? I'm guessing
fuzzing given the ASAN reports.

------
ryan-c
Am I misunderstanding this, or is there not an updated version of the Debian
package available?

~~~
0x0
Currently listed as vulnerable, I'm sure they'll get on it as soon as
possible.

[https://security-tracker.debian.org/tracker/CVE-2017-14491](https://security-
tracker.debian.org/tracker/CVE-2017-14491) [https://security-
tracker.debian.org/tracker/CVE-2017-14492](https://security-
tracker.debian.org/tracker/CVE-2017-14492) [https://security-
tracker.debian.org/tracker/CVE-2017-14493](https://security-
tracker.debian.org/tracker/CVE-2017-14493) [https://security-
tracker.debian.org/tracker/CVE-2017-14494](https://security-
tracker.debian.org/tracker/CVE-2017-14494) [https://security-
tracker.debian.org/tracker/CVE-2017-14495](https://security-
tracker.debian.org/tracker/CVE-2017-14495) [https://security-
tracker.debian.org/tracker/CVE-2017-14496](https://security-
tracker.debian.org/tracker/CVE-2017-14496)

~~~
ryan-c
Looks like it's being worked on:
[https://tracker.debian.org/news/876560](https://tracker.debian.org/news/876560)

~~~
ryan-c
Fixed packages released - was just able to install. [https://security-
tracker.debian.org/tracker/source-package/d...](https://security-
tracker.debian.org/tracker/source-package/dnsmasq)

------
irundebian
Yet another high impact vulnerabilities report related to C implementation.
History repeats. Software engineering still didn't come to the point to make
engineering of safe and secure software easy.

------
excalibur
I love it when vulnerabilities are publicly disclosed the moment they have
patches. Now we all get to choose between patching them ourselves and manually
managing patches for the affected software from now on, or leaving them
unpatched until the fixes eventually find their way downstream to us.

~~~
tptacek
The alternative is to deprive people willing to manually manage patches of the
ability to protect their networks, so that everyone can wait for people who
don't take that level of responsibility over their networks to get a one-line
installer. That's no alternative at all.

~~~
xyzzy_plugh
I agree. I used to be the sole maintainer of a small Linux distribution for my
employer (only a side-project, responsibility wise). This was a Fortune 50
company. I'd often have patches applied and new versions released within
hours. It's very easy to do. Usually by the time someone else in the office
found out, it had been patched long ago. And I'd like to be clear that I am
not actively subscribed to any lists, I just casually find these issues by
reading where other professionals write, often. And lo, we were more up to
date than most other companies.

Sure, we were vulnerable for a brief window, and without a doubt there were
other vulnerabilities, but we were pretty much as safe as possible, let alone
for a half-person team.

You just don't leave windows broken. You don't leave the holes unfilled. If
you find a crack in the foundation, you fix it. To do otherwise is not only
irresponsible to your peers and employer, but to your customers.

My only criticism is that often the roles responsible for such things are
unpleasant, come with little respect, visibility and/or pay. Companies should
just suck it up and overpay a handful of engineers and security specialists,
charged with the responsibility of ensuring the company avoids being
vulnerable. Think of it as insurance -- it's worth far more than a bad press
cycle or having your customers exploited and rightful loss of trust. The bang
for your buck is off the charts.

~~~
3pt14159
Executives don't realize that it can end a company until it does. Apple gets
it. Google gets it. Facebook gets it. But very few other companies do. Cyber
vulnerabilities _killed_ Nortel back in the day. Huawei got not just designs,
but details about bids, key people, everything.

~~~
thephyber
Maybe 5-10 years ago companies didn't realize it. I think every major
corporation has started to consider that kind of scenario now. Smaller
companies may still delude themselves into thinking they aren't targets, but
they probably are much less capable than big companies of investing in the
required preparations to prevent those attacks.

The "black swan" events aren't costless to mitigate. In fact, they are
extremely expensive. And just like there can be a black swan for cyberattacks,
there can be a black swan like a terrorist attack (like companies in World
Trade Center Towers 1 and 2), a massive natural disaster (think businesses in
Puerto Rico right now), massive electrical outages (say an EMP or simply just
Enron malfeasance), etc.

Spending to protect against and mitigate all possible black swans approaches
infinity and doesn't every pay off until the extremely rare but extremely
impactful event ever happens. And in cyber security, you never know because
your defenses prevented it before it ever started.

~~~
3pt14159
If they were doing as you describe they would at the very least keep their
versions of Windows updated and they would enable things like two-factor
authentication and TLS for their email. They don't. We're not talking
expensive to prevent black swan, we're talking routine defences against white
swans.

------
fulafel
Why do we tolerate these C death traps in unmaintained devices? There needs to
be legislated liability for device peddlers or security regulation.

This, the Broadcom wifi RCE and the Bluetooth RCE are like a concurrent land,
sea and air pwning of people's personal and home devices.

~~~
feld
Write a better replacement in your magic language of choice then.

~~~
fulafel
Why so defensive, surely it's the vendors responsibility? Anyway, DNS and dhcp
impls in safer languages exist in some numbers.

~~~
feld
Vendor? This is open source software. It's not proprietary. There is no
"vendor".

The reason these devices are cheap/affordable is because of the open source
community. The reason the internet has made it to this current state is
because of the open source community. If you want the internet to be better
and safer you have to roll up your shirt sleeves and contribute in any way you
can.

~~~
fulafel
I find it really hard to understand the view that a company shipping a
defective product that may cause great harm to users should be excused from
responsibility because the bad software choices they made happened to be open
source.

I suspect the consumer protection laws take similar views in many countries.

Like I said before, there are a number of available DHCP and DNS
implementations in memory-safe languages. Many of them are open source. So the
vendors don't even have that excuse.

~~~
feld
What are they? I've certainly never heard of them or used them. Are they used
in production or are they toys?

DHCP: isc-dhcp or dnsmasq

DNS recursor: dnsmasq, unbound, bind, djb's dnscache, maradns

None of these are written in memory safe languages, but they're the only ones
I would trust because they have YEARS of testing and getting the RFCs right.

------
macawfish
Help me understand these vulnerabilities. What could happen if someone
exploited these?

~~~
eugeneionesco
They could get access to the device dnsmasq is running on, your pc, your
router etc.

~~~
macawfish
Wow... So you're saying a computer on the internet, just by knowing my IP
adress, could just get access to the LAN at my house?

I'm glad Arch Linux has such strict firewalls by default!

~~~
lftl
Three of the issues would allow an attacker to take over your router from
inside your LAN (not externally). Only one of the issues is an RCE that would
usually be exploitable from outside your LAN, and there's some debate as to
how hard that one would be to exploit. It might be as simple as getting you to
visit a web page, but the published proof of concept would require something
like tricking you into manually running a query via the command line or some
other administrative tool.

~~~
macawfish
Thanks for explaining. This wasn't obvious to me.

------
feelin_googley
I have never understood why so many people, including commercial projects, use
dnsmasq. _Convenience_?

With djbdns I have never felt the need for it. Nor do I use DHCP. Or even ARP.
At least, on computers that allow control over such things.

I guess I am missing out on the _convenience_ , or perhaps there is an
alternative selling point I have overlooked?

~~~
0x0
So if you have a wifi network that other people are to use, do you ask them to
punch in a manual IP address on their phone's wifi config every time?

~~~
feelin_googley
"... you have a wifi network that other people are to use..."

I prefer wired networks and to attach particular RFC1918 IP's to particular
devices. Works for me.

~~~
0x0
Yeah ok. In case you're still wondering why people use dnsmasq and dhcp, your
regime wouldn't work well in most places where visitors expect to just connect
and go online.

