[sf-lug] System Events (sf-lug.{org, com}.DNS)

[GoOSSBears]

"Michael Paoli" <Michael.Paoli at cal.berkeley.edu wrote:
> The annoyance factor of notifies from 198.144.194.235 (non-master)
> for sf-lug.{com,org} zones should now be gone.  The data and summary
> bits from the logs, further below, should show the last such notifies
> you would have received - there should be no more of those.
> 
> I'm quite certain rationale of BIND9's default of sending notifies to
> all NS except SOA MNAME, even from slave zones, is master/slave
> is relative, and slave has no way to know that it's not (also)
> master to an NS - hence the notifies (which can also be safely ignored
> if not relevant to the target sent to from that source).



Not that the following is necessarily related to the above 
sf-lug.{com,org} zone annoyance factor, but apparently Google and Red Hat 
are warning us Linux users over a supposedly critical glibc bug[1]. 

As summarized in one of the detailed descriptions of the bug[2]:
~~~~~~~~~~~~~~~~ quoting ~~~~~~~~~~~~~~~~

During upstream review of the public open bug 18665 for glibc, it was
discovered that the bug could lead to a stack-based buffer overflow.

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

The buffer overflow occurs in the function send_dg (UDP) and send_vc
(TCP) for the NSS module libnss_dns.so.2 when calling getaddrinfo with
AF_UNSPEC family and in some cases also with AF_INET6 before the fix in
commit 8479f23a (only use gethostbyname4_r if PF_UNSPEC).

The use of AF_UNSPEC triggers the low-level resolver code to send out
two parallel queries for A and AAAA. A mismanagement of the buffers used
for those queries could result in the response writing beyond the alloca
allocated buffer created by __res_nquery.

Main conclusions:

- Via getaddrinfo with family AF_UNSPEC or AF_INET6 the overflowed
  buffer is located on the stack via alloca (a 2048 byte fixed size
  buffer for DNS responses).

- At most 65535 bytes (MAX_PACKET) may be written to the alloca buffer
  of 2048 bytes. Overflowing bytes are entirely under the control of the
  attacker and are the result of a crafted DNS response.

- Local testing shows that we have been able to control at least the
  execution of one free() call with the buffer overflow and gained
  control of EIP. Further exploitation was not attempted, only this
  single attempt to show that it is very likely that execution control
  can be gained without much more effort. We know of no known attacks
  that use this specific vulnerability.

- Mitigating factors for UDP include:
  - A firewall that drops UDP DNS packets > 512 bytes.
  - A local resolver (that drops non-compliant responses).
  - Avoid dual A and AAAA queries (avoids buffer management error) e.g.
    Do not use AF_UNSPEC.
  - No use of `options edns0` in /etc/resolv.conf since EDNS0 allows
    responses larger than 512 bytes and can lead to valid DNS responses
    that overflow.
  - No use of `RES_USE_EDNS0` or `RES_USE_DNSSEC` since they can both
    lead to valid large EDNS0-based DNS responses that can overflow.

- Mitigating factors for TCP include:
  - Limit all replies to 1024 bytes.

- Mitigations that don't work:
  - Setting `options single-request` does not change buffer management
    and does not prevent the exploit.
  - Setting `options single-request-reopen` does not change buffer
    management and does not prevent the exploit.
  - Disabling IPv6 does not disable AAAA queries. The use of AF_UNSPEC
    unconditionally enables the dual query.
    - The use of `sysctl -w net.ipv6.conf.all.disable_ipv6=1` will not
      protect your system from the exploit.
  - Blocking IPv6 at a local or intermediate resolver does not work to
    prevent the exploit. The exploit payload can be delivered in A or
    AAAA results, it is the parallel query that triggers the buffer
    management flaw.

... it goes on further ...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
So that those of you reading this are aware of the glibc vulnerability, 
if you're not already, Cisco has recently put out a comprehensive list of 
their products[3] that could be affected by the GNU glibc vulnerability.

--

I'll reiterate that this supposedly critical glibc bug is *not* 
necessarily related to the top sf-lug.{com,org} zone annoyance factor.

-A


Refs
=====
[1]http://www.zdnet.com/article/patch-linux-now-google-red-hat-warn-over-critical-glibc-bug/
[2]https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
[3]https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160218-glibc

------------------------------



_____________________________________________________________
Get your FREE, LinuxWaves.com Email Now! --> http://www.LinuxWaves.com 
Join Linux Discussions! --> http://Community.LinuxWaves.com