TL;DR - patches for this widely deployed vulnerability not generally available. Recommend disabling EDNS by modifying your /etc/resolv.conf to ensure that the "options edns0" directive is not present. Don't have that option present? Then EDNS probably isn't enabled on your machine and you probably* aren't exploitable.
*I still need more time with this to fully understand whether other exploitation paths might exist. Use this at your own risk.
What's going on?
Google has discovered issues with the getaddrinfo function in glib. They state that these issues may be remotely exploitable, but you will have to bypass exploit restrictions like ASLR. There is a patch available, but it's a source level patch, requiring users to recompile code. Something that most people simply can't do.
Google claims to have a weaponized proof of concept, but they are not releasing it. They have however released a proof of concept to demonstrate the vulnerability.
Is this a problem you need to worry about?
Probably. It's too early to understand all applications in which this vulnerability may be remotely exploited. But suffice it to say that this is something we should patch sooner than later.
Why is this vulnerability more serious than others I hear about?
Because this vulnerability is present in a commonly used network function in glibc, the exposure is greater than if the vulnerability were in a single service. Glibc is linked into many applications and many (if not most) network applications use the getaddrinfo function.
When was the vulnerability introduced?
It appears that the vulnerability was introduced in Glibc 2.9. Interestingly, the bug was noticed and added to the glibc bug tracker in July, 2015. If your system (or code) is using a much older version of glibc, you are not vulnerable to this bug (but you have a whole set of other problems). Glibc was released February 26, 2009, but the offending code commit occurred in 2008.
How easy will this be to patch?
Unfortunately, patching is non-trivial. You'll have to compile software from source or wait for new binary distributions to come out. At this point, you are in stand by mode. Consider this the warning order.
Are there any mitigations?
This writeup has some mitigations. One detection strategy could be to look for are very large DNS responses. Only a large DNS response would be able to overflow the stack based buffer. But large DNS responses (those larger than 512 bytes) are not entirely abnormal. In fact, many DNS SRV and TXT records exceed this size. However, DNS host records (A and AAAA records) typically do not reach such large sizes).
The easiest mitigation to use appears to involve disabling EDNS by removing the "options edns0" directive in /etc/resolv.conf. Of course you shouldn't use this if EDNS is in use on your production machines, but honestly it probably isn't. Your mileage will vary as to whether you can use this as an effective strategy. This fix will need to be applied on all hosts that are running impacted software, including ssh, curl, and other network aware software. I checked several servers in client environments and found that EDNS wasn't enabled on any of them. But if you use DNSSEC, you have to enable EDNS. So if you are using DNSSEC, bear in mind that this mitigation breaks it. Given the choice between DNSSEC and remote code execution, I'll disable DNSSEC every. single. time. Hands down.
Have fun and stay safe. Also, get some rest tonight. We're likely to be in a flurry of required patching later this week
*I still need more time with this to fully understand whether other exploitation paths might exist. Use this at your own risk.
What's going on?
Google has discovered issues with the getaddrinfo function in glib. They state that these issues may be remotely exploitable, but you will have to bypass exploit restrictions like ASLR. There is a patch available, but it's a source level patch, requiring users to recompile code. Something that most people simply can't do.
Google claims to have a weaponized proof of concept, but they are not releasing it. They have however released a proof of concept to demonstrate the vulnerability.
Is this a problem you need to worry about?
Probably. It's too early to understand all applications in which this vulnerability may be remotely exploited. But suffice it to say that this is something we should patch sooner than later.
Why is this vulnerability more serious than others I hear about?
Because this vulnerability is present in a commonly used network function in glibc, the exposure is greater than if the vulnerability were in a single service. Glibc is linked into many applications and many (if not most) network applications use the getaddrinfo function.
When was the vulnerability introduced?
It appears that the vulnerability was introduced in Glibc 2.9. Interestingly, the bug was noticed and added to the glibc bug tracker in July, 2015. If your system (or code) is using a much older version of glibc, you are not vulnerable to this bug (but you have a whole set of other problems). Glibc was released February 26, 2009, but the offending code commit occurred in 2008.
How easy will this be to patch?
Unfortunately, patching is non-trivial. You'll have to compile software from source or wait for new binary distributions to come out. At this point, you are in stand by mode. Consider this the warning order.
Are there any mitigations?
This writeup has some mitigations. One detection strategy could be to look for are very large DNS responses. Only a large DNS response would be able to overflow the stack based buffer. But large DNS responses (those larger than 512 bytes) are not entirely abnormal. In fact, many DNS SRV and TXT records exceed this size. However, DNS host records (A and AAAA records) typically do not reach such large sizes).
The easiest mitigation to use appears to involve disabling EDNS by removing the "options edns0" directive in /etc/resolv.conf. Of course you shouldn't use this if EDNS is in use on your production machines, but honestly it probably isn't. Your mileage will vary as to whether you can use this as an effective strategy. This fix will need to be applied on all hosts that are running impacted software, including ssh, curl, and other network aware software. I checked several servers in client environments and found that EDNS wasn't enabled on any of them. But if you use DNSSEC, you have to enable EDNS. So if you are using DNSSEC, bear in mind that this mitigation breaks it. Given the choice between DNSSEC and remote code execution, I'll disable DNSSEC every. single. time. Hands down.
Have fun and stay safe. Also, get some rest tonight. We're likely to be in a flurry of required patching later this week
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.