GlibC vulnerability?

[chicagonyc]

Hello,

 

I was wondering if our XPEnology is subject to this newly revealed glibc vulnerability?

 

http://arstechnica.com/security/2016/02 ... ulnerable/

 

Looks pretty bad now.

[brantje]

We have to wait till synology releases an update.

 

 

Posted via MyXpenology

[CtrlAltDel]

There appear to be some proactive options available...one is an actual fix for the core GlibC and the others are defensive mitigation approaches according to the article quoted in the op.

 

http://arstechnica.com/security/2016/02/extremely-severe-bug...

 

The fix isn't going to help if a compiled application is vulnerable!

 

GlibC bug Patch:

 

Maintainers of glibc, as the open source library is called, released an update that patches the vulnerability. Anyone responsible for Linux-based software or hardware that performs domain name lookups should install it as soon as possible. For many people running servers, patching will be a simple matter of downloading the update and installing it. But for other types of users, a fix may not be so easy. Some apps that were compiled with a vulnerable version of glibc will have to be recompiled with an updated version of the library, a process that will take time as users wait for fixes to become available from hardware manufacturers and app developers.

 

Using this in combination with the GlibC patch is probably the best short term solution until applications can be tested and recompiled etc.

 

GlibC bug Mitigation:

 

Anyone who is in a position to update should do so as soon as possible. Google's blog post continued:

 

Google has found some mitigations that may help prevent exploitation if you are not able to immediately patch your instance of glibc. The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.

 

Meanwhile, Glibc maintainers provided the following additional mitigation details:

 

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.

 

GlibC bug Proof of concept details:

 

https://github.com/fjserna/CVE-2015-7547

 

We are providing this code as-is. You are responsible for protecting yourself,

your property and data, and others from any risks caused by this code. This

code may cause unexpected and undesirable behavior to occur on your machine.

This code may not detect the vulnerability on your system.

 

Note that this POC consists of two components: server code and client code.

The server code triggers the vulnerability and therefore will crash the client

code. Note also that it is necessary to set the nameserver to point to the

server code, and doing so could cause other programs that call into the

getaddrinfo() function to crash while testing is underway. This POC code is

provided "as is" with no warranties, whether express or implied, including

without limitation any warranties or merchantability, fitness for a particular

use and noninfringement. Google assumes no responsibility for your proper

installation and use of the POC code.