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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

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

L2 Linker

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?

1 accepted solution

Accepted Solutions

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

2 REPLIES 2

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.)

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.

  • 1 accepted solution
  • 5149 Views
  • 2 replies
  • 0 Likes
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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!