[Snort-sigs] CVE-2015-7547 (GlibC bug) rules
gserrao at ...435...
Wed Feb 17 17:06:54 EST 2016
Thank you for your submission. We've been furiously testing different
techniques for detecting this vulnerability since it was disclosed with the
help of our sensors deployed in the wild. What we've found is that reliably
convicting large DNS query responses over TCP port 53 can be very
unreliable with just a plaintext snort rule. In essence, even with flowbit
checking we generate too much noise for the rule to be useful.
What we settled on was finding large DNS query responses over UDP 53 with
the truncated flag set whose dsize is greater than 2000 (2048 bytes will
overflow the alloca buffer). We know that the memory management error
happens when getaddrinfo is called with AF_UNSPEC, which causes the
low-level resolver code to send out parallel queries for A and AAAA
With this bit of information we can use the following content matches:
#For AAAA record responses
content:"|00 1C 00 01|"; fast_pattern:only;
#For A record responses
content:"|00 01 00 01|"; fast_pattern:only; \
These content matches are common for DNS traffic, but if we write the rule
with at least one content match that is elligible we can be guaranteed that
the match will be utilized in the fast pattern matcher. So instead of our
rule entering on *every *packet, we just enter on *almost* every packet.
We're also just the slightest bit more sure that what we're looking at is
what we're interested in.
If we drop the initial malicious UDP DNS query response with the truncated
flag set, the client will be forced to either timeout or continue asking
We're still exploring how to detect the TCP portion reliably and if we come
up with something useful then we will release it officially. As it stands
now from our testing all that's needed to block this exploit is dropping
the initial UDP response.
I also want to add that the rules going out today will be in the community
ruleset so anyone can download them.
On Wed, Feb 17, 2016 at 3:13 AM, Dheeraj Gupta <dheeraj.gupta4 at ...2420...>
> I was looking at the newly revealed CVE-2015-7547 (GlibC name resolution
> bug) and based on PoC avaliable at
> https://github.com/fjserna/CVE-2015-7547 have crafted a rudimentary
> The signature looks for two large DNS responses and raises an alert for
> the second one.
> It is tied to TCP because-
> a, The length field is only available with TCP packets
> b. Most DNS implementations will truncate large UDP DNS responses (and I
> don't know how tp count the length of UDP packet using a snort signature)
> alert tcp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"LOCAL Large DNS TCP
> response"; flow:to_client,established; byte_test: 1,&,128,4;
> byte_test:2,>,2000,0; flowbits: set,large_dns_resp; flowbits: noalert;
> sid:10000001; rev:1)
> alert tcp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"LOCAL Large second DNS
> response - possible CVE-2015-7547 attempt"; flow:to_client,established;
> byte_test: 1,&,128,4; byte_test:2,>,200,0; flowbits: isset,large_dns_resp;
> sid:10000002; rev:1)
> I have tested these agaisnt PoC and benign traffic and they seem to work.
> A possible false positive is zone transfer.
> Thoughts on how to refine them further or any alternative approaches to
> writing signatures for the said bug?
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> Please visit http://blog.snort.org for the latest news about Snort!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-sigs