Su Debian Jessie per armi ho aggiornato stamattina e c'è ancora la 2.72 dal
repo Security...
Il 04 ott 2017 11:28 AM, "Claudio Pisa" ha scritto:
FYI
Forwarded Message
Subject: [LEDE-DEV] Severe dnsmasq vulnerabilities affecting LEDE
Date: Tue, 3 Oct 2017 21:08:16 +0200
From: Jo-Philipp Wich
To: LEDE Development List , LEDE Project
Administration
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-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
