The glibc vulnerability announced yesterday is very interesting. It requires a large response to a DNS request to trigger the vulnerability. These are typically seen with EDNS and DNSSEC. I published yesterday that disabling EDNS would partially mitigate the vulnerability on impacted hosts. Several people have pointed out that this is only partially true (and I think they are right).
While disabling EDNS will prevent you from making large requests, an attacker with man in the middle (MITM) position could potentially send you a large reply anyway. I haven't yet confirmed whether the resolver will process this large response if not configured for EDNS, but it might. Honestly this might not require MITM position anyway. The attacker, by connecting to a vulnerable service, would force the DNS request for their source IP. Presumably this would be fulfilled by a DNS server they control. So disabling EDNS *might* mitigate the vulnerability.
But is it exploitable? Google says they have a weaponized exploit for at least one service. Reportedly, this has been shared with RedHat to demonstrate the vulnerability as well. We know that the vulnerability is the result of a mismatch between the size of a buffer on the heap and a buffer on the stack. The heap contents are copied onto the stack without checking or updating the size of the stack buffer. So basically you have a run of the mill stack based overflow.
But stack based buffer overflows have been mitigated for years using exploit mitigations such as stack canaries, ASLR, and non-executable stacks. So any stack based buffer overflow you want to exploit today requires some gymnastics to get working. So will this work? Probably not on your nice shiny Linux distro.
But what about IOT? Stack canaries and ASLR take processing power and many embedded devices have precious little processor power to spare. This means that they often don't enable exploit mitigations that will keep our core Linux distributions safe. Unfortunately, these embedded devices that are not protected are also the most likely to suffer from patch rot. Unfortunately, these systems are also the hardest to monitor in most cases. It's not a good situation to say the least.
Are IOT devices impacted? Yeah. For sure. This vulnerability has been around since 2009 and would have been compiled into tons of embedded software. If you are running an impacted IOT device, work with your manufacturer to demonstrate the vulnerability and get a patch.
While disabling EDNS will prevent you from making large requests, an attacker with man in the middle (MITM) position could potentially send you a large reply anyway. I haven't yet confirmed whether the resolver will process this large response if not configured for EDNS, but it might. Honestly this might not require MITM position anyway. The attacker, by connecting to a vulnerable service, would force the DNS request for their source IP. Presumably this would be fulfilled by a DNS server they control. So disabling EDNS *might* mitigate the vulnerability.
But is it exploitable? Google says they have a weaponized exploit for at least one service. Reportedly, this has been shared with RedHat to demonstrate the vulnerability as well. We know that the vulnerability is the result of a mismatch between the size of a buffer on the heap and a buffer on the stack. The heap contents are copied onto the stack without checking or updating the size of the stack buffer. So basically you have a run of the mill stack based overflow.
But stack based buffer overflows have been mitigated for years using exploit mitigations such as stack canaries, ASLR, and non-executable stacks. So any stack based buffer overflow you want to exploit today requires some gymnastics to get working. So will this work? Probably not on your nice shiny Linux distro.
But what about IOT? Stack canaries and ASLR take processing power and many embedded devices have precious little processor power to spare. This means that they often don't enable exploit mitigations that will keep our core Linux distributions safe. Unfortunately, these embedded devices that are not protected are also the most likely to suffer from patch rot. Unfortunately, these systems are also the hardest to monitor in most cases. It's not a good situation to say the least.
Are IOT devices impacted? Yeah. For sure. This vulnerability has been around since 2009 and would have been compiled into tons of embedded software. If you are running an impacted IOT device, work with your manufacturer to demonstrate the vulnerability and get a patch.
From Jake
ReplyDelete