Heads up for CVE-2015-7547

[tapper]

https://dev.openwrt.org/ticket/21870
CVE-2015-7547
The Google Security Team and Red Hat discovered that the eglibc
host name resolver function, getaddrinfo, when processing
AF_UNSPEC queries (for dual A/AAAA lookups), could mismanage its
internal buffers, leading to a stack-based buffer overflow and
arbitrary code execution. This vulnerability affects most
applications which perform host name resolution using getaddrinfo,
including system services.
https://googleonlinesecurity.blogspot.c ... stack.html
https://sourceware.org/ml/libc-alpha/20 ... 00416.html

http://arstechnica.co.uk/security/2016/ ... ulnerable/
The vulnerability, which is indexed as CVE-2015-7547, was disclosed Tuesday by researchers from Google. In a blog post, the researchers said they stumbled on the vulnerability when one of their SSH applications experienced an extremely serious error known as a segmentation fault each time it tried to contact a specific Internet address. Google engineers eventually figured out that the error was caused by a buffer overflow inside glibc that made malicious code-execution attacks possible and then notified glibc maintainers.
To the surprise of the Google researchers, they soon learned that glibc maintainers had been alerted to the vulnerability last July. They also learned that people who work for the Red Hat Linux distribution had also independently discovered the bug and were working on a fix.
"This was an amazing coincidence, and thanks to their hard work and cooperation, we were able to translate both teams’ knowledge into a comprehensive patch and regression test to protect glibc users," the Google researchers wrote.
They went on to say that weaponized exploits that successfully execute malicious code are "possible, but not straightforward" since they require the bypassing of address space layout randomization and other protections designed to make software more resistant to attacks. To prevent the vulnerability from being exploited maliciously, Google researchers aren't releasing the more advanced exploit they developed. The previously mentioned proof-of-concept attack merely crashes an application so users can figure out if it's vulnerable.
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.

[nworbnhoj]

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.

So do we wait for the openwrt chaps to resolve this and bump openwrt, or attempt to apply this mitigation in the interim?

[Lantis]

I'd wait.

In the meantime you could provide instructions for all users on how to protect themselves if they want.

[nworbnhoj]

@Lantis - agreed.

If you are concerned about this vulnerability in the short term (ie before openwrt resolves the issue, and Gargoyle is release with the fix included) then you might like to login to your Gargoyle router with ssh and run the following commands:

Code: Select all

uci set dhcp.@dnsmasq[0].ednspacket_max=1280
uci commit

Also in the Gargoyle GUI, review your DNS server and consider using:
Gargoyle - Connection - Basic - Local Network / LAN - DNS Servers - Google DNS Servers

[tapper]

Thanks for the fix.

[Lantis]

On further reading I'm not sure this affects gargoyle.
I think all firmwares use uClibc.

[jki]

Yes, Gargoyle itself is safe. See also https://forum.openwrt.org/viewtopic.php?id=62794.