14 ms·

Behind the Masq: Yet More DNS and DHCP Vulnerabilities

221 points by philips 9y ago

philips 9y ago
This affects all versions of Kubernetes between 1.5.0 and 1.7.6. Relevant posts: - https://groups.google.com/forum/#!topic/kubernetes-dev/QWIzhD3JhhE https://groups.google.com/forum/#!topic/kubernetes-dev/QWIzh... - https://coreos.com/blog/dns-vulnerability-patched-in-kubernetes-and-tectonic https://coreos.com/blog/dns-vulnerability-patched-in-kuberne...
- thesandlord 9y ago
  > Kubernetes versions 1.5.8, 1.6.11, 1.7.7, and 1.8.0 have been released with a patched DNS pod.
  - theptip 9y ago
    Per the kubernetes-dev post, all affected GKE clusters have been patched for you: > All GKE clusters have already been patched, so no action is necessary for GKE users. Users will see a "-gke.1" version for the MASTER_VERSION of their GKE clusters, which contains the patch.
- bboreham 9y ago
  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 9y ago
    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?
ryan-c 9y ago
Am I misunderstanding this, or is there not an updated version of the Debian package available?
- jlgaddis 9y ago
  Doesn't look like it: https://packages.debian.org/dnsmasq https://packages.debian.org/dnsmasq
- 0x0 9y ago
  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 9y ago
    Looks like it's being worked on: https://tracker.debian.org/news/876560 https://tracker.debian.org/news/876560
    - ryan-c 9y ago
      Fixed packages released - was just able to install. https://security-tracker.debian.org/tracker/source-package/dnsmasq https://security-tracker.debian.org/tracker/source-package/d...
kubov 9y ago
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.
- pingec 9y ago
  How can we verify that?
  - jlgaddis 9y ago
    Using the PoCs that Google provided?
  - kubov 9y ago
    I simply checked the version of dnsmasq running on my router, it's 2.71 so according to the article the build is affected. I'll try to launch one of the POC later in the day, but for now I assume worst case.
- loeg 9y ago
  Edgerouter Lite also uses dnsmasq.
- hathawsh 9y ago
  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/generic/packages/base/ https://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/ge... 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-lede-does-the-config-compatible/6252 https://forum.lede-project.org/t/upgrade-from-openwrt-to-led...
  - e12e 9y ago
    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
jlgaddis 9y ago
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.
- sitkack 9y ago
  pwn@home , write a not to setup for exit nodes
- agwa 9y ago
  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/vulnerabilities/dnsmasq/CVE-2017-14491-instructions.txt https://github.com/google/security-research-pocs/blob/master... 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.
  - oasisbob 9y ago
    re PTR reverse lookups - mail servers probably do it the most? That and administration / network management tools.
    - agwa 9y ago
      Agreed, but such software rarely runs on a home network with a cheap router. dnsmasq is used elsewhere, of course, but those deployments are far more likely to receive security updates.
  - agwa 9y ago
excalibur 9y ago
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 9y ago
  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.
  - eric_b 9y ago
    Security people like to paint this as a binary choice, then inevitably siding with "disclose immediately". But it's not really is it? Why do we put locks on our doors? It's not so that career hardened cat burglars can't get in - it's to prevent crimes of opportunity and small time crooks from getting an easy target. I feel like there's an analog with software. Quietly commit fixes for the RCEs to DNSMasq. Those who care will stay on the latest version. You can even say "Fixes security issues" in the release notes. But, wait awhile to release the PoCs and detail the exploits completely. The nation states will find a way to exploit it no matter what, of course. But you average cybercriminal will have a much harder time without PoCs clearly showing the attack vector.
  - xyzzy_plugh 9y ago
    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.
feelin_googley 9y ago
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 9y ago
  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 9y ago
    "... 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 9y ago
      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.
- peterwwillis 9y ago
  Dnsmasq is designed to automatically configure and provision dns and dhcp and provide a dns proxy in addition to other useful functions and requires virtually no configuration. Yes, it is for convenience.
macawfish 9y ago
Help me understand these vulnerabilities. What could happen if someone exploited these?
- eugeneionesco 9y ago
  They could get access to the device dnsmasq is running on, your pc, your router etc.
  - macawfish 9y ago
    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 9y ago
      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 9y ago
        Thanks for explaining. This wasn't obvious to me.
tareqak 9y ago
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 9y ago
  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...
  - raesene9 9y ago
    This is one of those times it's a shame I only have one upvote for a comment... Open source is extremely heavily used by commercial software and hardware manufacturers and the reality is that very few of them contribute back, meaningfully, to Open source security. The end result will continue to be bugs like this, with ever growing impact.
  - bannedtruth 9y ago
    HATEOAS
  - newman314 9y ago
    Also, good secure defaults. I see too many pieces of software ship with insecure defaults for ease of use. This needs to stop.
  - sitkack 9y ago
    The other one is that embedded devices need to running their components in sandboxes.
fulafel 9y ago
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 9y ago
  Write a better replacement in your magic language of choice then.
  - fulafel 9y ago
    Why so defensive, surely it's the vendors responsibility? Anyway, DNS and dhcp impls in safer languages exist in some numbers.
    - jlgaddis 9y ago
      "Be the change you wish to see in the world."
    - abugher 9y ago
      Probably because you used the metaphor of a military invasion and used the phrase "death trap". That kind of talk will get a defensive reaction. That's nothing to do with whether you have a point. It's just cause and effect.
    - feld 9y ago
      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 9y ago
        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.
lol768 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        "We" is inclusive - 'most developers' is exclusive. Mystery solved.
viraptor 9y ago
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.
- gcp 9y ago
  Taking control over dnsmasq seems potentially very useful even if it is running sandboxed. They're not a complete solution.
- irundebian 9y ago
  Still I was very negatively surprised about the code complexity of the seccomp integration.
  - viraptor 9y ago
    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 9y ago
      Thank you.
pbhjpbhj 9y ago
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-dns-and-dhcp.html?m=0 https://security.googleblog.com/2017/10/behind-masq-yet-more...) without that massive UX bug, where instead you can't scroll to see the table. smh
- mkj 9y ago
  Not just that page - the entirety of Blogspot/Blogger has that problem! Easy to accidentally do on Android Chrome too.
- djeikyb 9y ago
  same problem on ios 10's safari
- the8472 9y ago
  As a double whammy, it doesn't display any content if you block 3rd-party javascript. Sure, there's a <noscript> section, but that doesn't handle the failure mode (or intentional action) of some 3rd party stuff not loading.
- deftturtle 9y ago
  Reader mode is the only way to read these pages. Smh indeed
userbinator 9y ago
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.
mkj 9y ago
Is there any indication how these vulnerabilities were found? I'm guessing fuzzing given the ASAN reports.
deleted 9y ago
[deleted]
tomatcloudshark 9y ago
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/vulnerabilities/dnsmasq https://github.com/google/security-research-pocs/tree/master...
irundebian 9y ago
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.

221 points by philips 9y ago

This affects all versions of Kubernetes between 1.5.0 and 1.7.6. Relevant posts: - https://groups.google.com/forum/#!topic/kubernetes-dev/QWIzhD3JhhE https://groups.google.com/forum/#!topic/kubernetes-dev/QWIzh... - https://coreos.com/blog/dns-vulnerability-patched-in-kubernetes-and-tectonic https://coreos.com/blog/dns-vulnerability-patched-in-kuberne...

thesandlord 9y ago
> Kubernetes versions 1.5.8, 1.6.11, 1.7.7, and 1.8.0 have been released with a patched DNS pod.
- theptip 9y ago
  Per the kubernetes-dev post, all affected GKE clusters have been patched for you: > All GKE clusters have already been patched, so no action is necessary for GKE users. Users will see a "-gke.1" version for the MASTER_VERSION of their GKE clusters, which contains the patch.
bboreham 9y ago
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 9y ago
  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?

ryan-c 9y ago

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

jlgaddis 9y ago
Doesn't look like it: https://packages.debian.org/dnsmasq https://packages.debian.org/dnsmasq
0x0 9y ago
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 9y ago
  Looks like it's being worked on: https://tracker.debian.org/news/876560 https://tracker.debian.org/news/876560
  - ryan-c 9y ago
    Fixed packages released - was just able to install. https://security-tracker.debian.org/tracker/source-package/dnsmasq https://security-tracker.debian.org/tracker/source-package/d...

kubov 9y ago

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.

pingec 9y ago
How can we verify that?
- jlgaddis 9y ago
  Using the PoCs that Google provided?
- kubov 9y ago
  I simply checked the version of dnsmasq running on my router, it's 2.71 so according to the article the build is affected. I'll try to launch one of the POC later in the day, but for now I assume worst case.
loeg 9y ago
Edgerouter Lite also uses dnsmasq.
hathawsh 9y ago
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/generic/packages/base/ https://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/ge... 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-lede-does-the-config-compatible/6252 https://forum.lede-project.org/t/upgrade-from-openwrt-to-led...
- e12e 9y ago
  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

jlgaddis 9y ago

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.

sitkack 9y ago
pwn@home , write a not to setup for exit nodes
agwa 9y ago
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/vulnerabilities/dnsmasq/CVE-2017-14491-instructions.txt https://github.com/google/security-research-pocs/blob/master... 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.
- oasisbob 9y ago
  re PTR reverse lookups - mail servers probably do it the most? That and administration / network management tools.
  - agwa 9y ago
    Agreed, but such software rarely runs on a home network with a cheap router. dnsmasq is used elsewhere, of course, but those deployments are far more likely to receive security updates.
- agwa 9y ago

excalibur 9y ago

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 9y ago
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.
- eric_b 9y ago
  Security people like to paint this as a binary choice, then inevitably siding with "disclose immediately". But it's not really is it? Why do we put locks on our doors? It's not so that career hardened cat burglars can't get in - it's to prevent crimes of opportunity and small time crooks from getting an easy target. I feel like there's an analog with software. Quietly commit fixes for the RCEs to DNSMasq. Those who care will stay on the latest version. You can even say "Fixes security issues" in the release notes. But, wait awhile to release the PoCs and detail the exploits completely. The nation states will find a way to exploit it no matter what, of course. But you average cybercriminal will have a much harder time without PoCs clearly showing the attack vector.
- xyzzy_plugh 9y ago
  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.

feelin_googley 9y ago

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 9y ago
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 9y ago
  "... 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 9y ago
    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.
peterwwillis 9y ago
Dnsmasq is designed to automatically configure and provision dns and dhcp and provide a dns proxy in addition to other useful functions and requires virtually no configuration. Yes, it is for convenience.

macawfish 9y ago

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

eugeneionesco 9y ago
They could get access to the device dnsmasq is running on, your pc, your router etc.
- macawfish 9y ago
  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 9y ago
    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 9y ago
      Thanks for explaining. This wasn't obvious to me.

tareqak 9y ago

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 9y ago
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...
- raesene9 9y ago
  This is one of those times it's a shame I only have one upvote for a comment... Open source is extremely heavily used by commercial software and hardware manufacturers and the reality is that very few of them contribute back, meaningfully, to Open source security. The end result will continue to be bugs like this, with ever growing impact.
- bannedtruth 9y ago
  HATEOAS
- newman314 9y ago
  Also, good secure defaults. I see too many pieces of software ship with insecure defaults for ease of use. This needs to stop.
- sitkack 9y ago
  The other one is that embedded devices need to running their components in sandboxes.

fulafel 9y ago

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 9y ago
Write a better replacement in your magic language of choice then.
- fulafel 9y ago
  Why so defensive, surely it's the vendors responsibility? Anyway, DNS and dhcp impls in safer languages exist in some numbers.
  - jlgaddis 9y ago
    "Be the change you wish to see in the world."
  - abugher 9y ago
    Probably because you used the metaphor of a military invasion and used the phrase "death trap". That kind of talk will get a defensive reaction. That's nothing to do with whether you have a point. It's just cause and effect.
  - feld 9y ago
    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 9y ago
      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.

lol768 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      "We" is inclusive - 'most developers' is exclusive. Mystery solved.

viraptor 9y ago

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.

gcp 9y ago
Taking control over dnsmasq seems potentially very useful even if it is running sandboxed. They're not a complete solution.
irundebian 9y ago
Still I was very negatively surprised about the code complexity of the seccomp integration.
- viraptor 9y ago
  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 9y ago
    Thank you.

pbhjpbhj 9y ago

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-dns-and-dhcp.html?m=0 https://security.googleblog.com/2017/10/behind-masq-yet-more...) without that massive UX bug, where instead you can't scroll to see the table. smh

mkj 9y ago
Not just that page - the entirety of Blogspot/Blogger has that problem! Easy to accidentally do on Android Chrome too.
djeikyb 9y ago
same problem on ios 10's safari
the8472 9y ago
As a double whammy, it doesn't display any content if you block 3rd-party javascript. Sure, there's a <noscript> section, but that doesn't handle the failure mode (or intentional action) of some 3rd party stuff not loading.
deftturtle 9y ago
Reader mode is the only way to read these pages. Smh indeed

userbinator 9y ago

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.

mkj 9y ago

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

deleted 9y ago

[deleted]

tomatcloudshark 9y ago

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/vulnerabilities/dnsmasq https://github.com/google/security-research-pocs/tree/master...

irundebian 9y ago

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.