On 04/10/17 12:07, Ilario Gelmetti wrote:
Yesterday LEDE 17.01.3 was released. A few days earlier some severe security vulnerabilities in DNSmasq have been disclosed. Images of LibreMesh 17.06 based on LEDE 17.01.3 can be compiled using lime-sdk but please notice that this is untested. For doing this you can replace 17.01.2 with 17.01.3 in feeds.conf.defaults and options.conf files in lime-sdk, then run ./cooker -f --force and then compile as usually. On my PC the compilation worked well but I didn't test on any router.
-------- Forwarded Message -------- Subject: [LEDE-DEV] Severe dnsmasq vulnerabilities affecting LEDE Date: Tue, 3 Oct 2017 21:08:16 +0200 From: Jo-Philipp Wich <jo@mein.io> To: LEDE Development List <lede-dev@lists.infradead.org>, LEDE Project Administration <lede-adm@lists.infradead.org> The Google security team identified a number of critical security issues present in dnsmasq, the embedded DNS and DHCP server used by LEDE as well as many other different open and proprietary firmwares and network appliances. A total of six different flaws affecting both DNS and DHCP functionality have been identified in dnsmasq versions up to v2.77: - CVE-2017-14491 - Remote code execution, through DNS, due to heap overflow - CVE-2017-14492 - Remote code execution, through DHCP, due to heap overflow - CVE-2017-14493 - Remote code execution, through DHCP, due to stack overflow - CVE-2017-14494 - Information leak, through DHCP, potentially weakening ASLR - CVE-2017-14495 - Denial of service, through DNS, out-of-memory due missing free() - CVE-2017-14496 - Denial of service, through DNS, integer underflow causing huge memcpy() - CVE-2017-13704 - Denial of service, through DNS, integer underflow causing service crash According to Simon Kelley, the author of dnsmasq, most critical flaws are present in dnsmasq since a very long time, having even survived a number of audits. The security issues have been fixed in the most recent dnsmasq version, v2.78, which has been included into both the LEDE master and lede-17.01 release branches. MITIGATION In order to solve the security issues above you can either update the dnsmasq package through opkg: opkg update opkg upgrade dnsmasq Or update to a newer LEDE image. Master snapshots newer than revision r4969-67ac017fef and the upcoming LEDE release 17.01.3 images already contain a fixed dnsmasq version. WORKAROUND There is no secure workaround available, though the attack surface can be reduced somewhat by disabling the DNS service part of dnsmasq and only allowing trusted hosts to obtain DHCP leases in the local network. In order to disable the DNS service, issue the following commands: uci set dhcp.@dnsmasq[0].port="0" uci add_list dhcp.lan.dhcp_option="6,8.8.8.8" uci commit dhcp /etc/init.d/dnsmasq restart This will stop dnsmasq from serving DNS requests and instruct all DHCP clients to use Google's public DNS server instead of the router itself for name resolution. REFERENCES The orginal article published on the Google security blog: https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html Dnsmasq security notice: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q4/011772.html Debian security advisory: https://www.debian.org/security/2017/dsa-3989 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
_______________________________________________ lime-users mailing list lime-users@lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users