Detecting overly long DNS Responses for CVE-2015-7547 glibc getaddrinfo() stack-based buffer over..

Reply
Highlighted
L2 Linker

Detecting overly long DNS Responses for CVE-2015-7547 glibc getaddrinfo() stack-based buffer over..

Objective: I'm trying to write a custom vuln for detecting DNS responses with payloads greater than 512 bytes.  This is one of the recommended mitigations for CVE-2015-7547.

 

Editorial:  I know that there are better places to apply mitigations, such as the clients themselves, caching nameservers, etc, but please for the sake of defense-in-depth and the academic discussion, please let's assume I want to do this mitigation on the PAN firewalls.

 

Problem:  I can't seem to find enough bytes in a standard DNS response that are static and will meet the 7-byte minimum matching requirement.  I'm finding the dns-rsp-* contexts to be extremely limiting in this exercise because the response packets (at least the ones I'm looking at) arevery compact and have a lot of information crammed into a small number of bytes.  Would it be better to try something using the unknown-rsp-udp context and try to start matching there?  Has anyone else tried matching on payload lengths?


Accepted Solutions
Highlighted
L4 Transporter

Good morning, mgentile!

 

You are correct in your analysis of the DNS response contexts being difficult to identify static patterns on; this is a challenge I've faced myself writing custom signatures where what I am looking for is shorter than our static byte length restriction. This is a current limit of the pattern matching capabilities in the custom signature engine, and as such, signatures requiring this type of evaluation require a decoder based signature (which is something our engineers would write.)

 

The good news is that we released a signature in an emergency content (560) in the early hours this morning that protects from exploitation of this vulnerability under threat ID 38898.

 

Additionally, as a result of your inquiry, I will investigate whether or not a context is possible for DNS request/response lengths, outside of a pattern-match (Meaning, contexts available for mathematical evaluations, like equal to, greater than, less than.)

View solution in original post


All Replies
Highlighted
L4 Transporter

Good morning, mgentile!

 

You are correct in your analysis of the DNS response contexts being difficult to identify static patterns on; this is a challenge I've faced myself writing custom signatures where what I am looking for is shorter than our static byte length restriction. This is a current limit of the pattern matching capabilities in the custom signature engine, and as such, signatures requiring this type of evaluation require a decoder based signature (which is something our engineers would write.)

 

The good news is that we released a signature in an emergency content (560) in the early hours this morning that protects from exploitation of this vulnerability under threat ID 38898.

 

Additionally, as a result of your inquiry, I will investigate whether or not a context is possible for DNS request/response lengths, outside of a pattern-match (Meaning, contexts available for mathematical evaluations, like equal to, greater than, less than.)

View solution in original post

Highlighted
L2 Linker

Thank you for the quick response!  That is great news that there is a signature ready for install. Our vuln. mgmt team will breathe a sigh of relief :-)

 

I also checked the greater than/less than operators, but there were only two, very specific contexts for DNS available with those operators selected.  They did not lend themselves to evaluating Answers for A records.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!