Mailslot bug (MS06-035) vs non-Mailslot bug (CVE-2006-3942)
Mailslot bug (MS06-035)
vs.
non-Mailslot bug(MS0?-???/CVE-2006-3942)
This is the story of a yet unpatched bug which is not a 0-day.
Time line:
2006-07-12 - MS06-035 Published by Microsoft [1]
2006-07-12 - Windows Mailslot (MS06-035) DoS module
released to IMPACT customers
2006-07-13 - We realized (too late) that it was a different bug [2]
2006-07-14 - We got in touch with Microsoft
2006-07-19 - Public exploit released by cocoruder [3]
(frankruder_at_hotmail.com)
2006-07-28 - ISS released their advisory [4]
2006-07-28 - Microsoft acknowledged the bug [5]
2006-08-14 - Today - We publish and advisory [10] and this email
---[ Intro ]
Last month's patch Tuesday started with a nice challenge: A remotely
exploitable code execution kernel bug for most Microsoft's OSes (most
supported Windows). As my job is to write exploits, I jumped to that as
soon as I could (which was latter than what I liked because we were
closing a new version of our product). I got something working in a
short time, sent it to QA to test and released before the end of the
day... I was truly amazed... to only find out, a little bit later, that
I had accidentally found a different (yet unpatched today) bug.
In this pseudo-advisory I will describe the Details of this new bug, the
process of how I [also] discovered it, and why I think it's not
exploitable (only to be proved later by someone else that I'm a moron)
---[ MS06-035... I think ]
For a long time I've been waiting for a remotely exploitable kernel bug
to try to exploit. It was a tough challenge, at least for me, as I've
never before worked on such a beast. I jumped immediatly to
Microsoft's advisory's [1] Vulnerability details section to find what
I expected: NOTHING. Just a general description, as in most advisories
lately, which can't, in any way, be used to prove or disprove the
existence of the bug, nor to decide how high in the priority list this
patch should be put:
There is a remote code execution vulnerability in the Server driver
that could allow an attacker who successfully exploited this
vulnerability to take complete control of the affected system. [1]
Uhm... if the information is not under Vulnerability details, where
may it be? I think I need to take even more English lessons, because I
thought details meant detalles, oh well... let's read all the
advisory just in case...
After reading Microsoft's advisory I continued with TippingPoint's [5]
and Pedram Amini's blog [7] to happily find a few more details. Let me
summarize what I knew then:
. Mailslot == SMB
. Kernel Heap overflow
. Code execution is possible (why would Microsoft over-rate it?)
. SRV.SYS (Server driver)
. Port 445 (from advisory's Workarounds section)
. First class mailslot (whatever it means)
What do I know about Mailslots? the basics, probably a little bit more,
but surely not enough. Let's see if Impacket [11] has something for
Mailslots:
$ cd Impacket-0.9.6.0
$ grep -i mailslot *
$ grep -i mailslot */*
$ grep -i mailslot */*/*
$ grep -i mailslot */*/*/*
grep: */*/*/*: No such file or directory
... ... nothing... now what? After quickly sending Pedram an
email to congratulate him and HD for their finding (and, of course, cry
for some help), I sat down to read CIFS' specification [12] once again.
I searched for the word mailslot to only find it in one section
describing the format for Mailslot Write transactions. Nice! Lets try
the fuzzing approach, lets create a Mailslot request with a lot of data!
So I opened my Ethereal and my Python interpreter, booted up a VMware
with Windows, went through the automatic Win-R, cmd, ipconfig. Got
VMware's IP address and continued typing:
from impacket import smb
s = smb.SMB('*SMBSERVER','10.0.1.44')
s.login('','')
tid = s.tree_connect_andx(r'\\*SMBSERVER\IPC$')
s.send_trans(tid,
'\x01\x00\x00\x00\x00\x00', r'\MAILSLOT\LANMAN', '', 'A'*1000)
BOOM! The vmware crashed!
What? Wait a second...
At this point I thought How stupid I am! I should have
tested this before! just sending a big packet crashed it! And I'm one
of those who 5 years ago thought first generation fuzzers are not going
to find too many bugs any more... stupid me!
Ok. Got a crash, it's a kernel bug... no, no, it's a remotely
exploitable kernel heap overflow bug... it's quite unlikely I will be
able to do anything better than a simple Denial of Service for quite
some days. So I better focus on writing down the documentation. I will
send right away a working version to QA so we can try to ship it today.
Thought and done. Documentation written, typos fixed, some extra packets
added just in case, QA approved it for Early release mode...
Nice! we tested it against most Windows VMWares we have, it crashed
them all in the first try. And we shipped it all in a single day! I was
not really expecting this, I'm more used to spending a few days per bug
until I have a QA-approved shippable version
New SMB and DCERPC features on Impacket released with doc
Hi! As we promised in the too short 5 minutes talk at CanSecWest last month, here we are publishing a new version of Impacket including all the new features we added for SMB and DCERPC. At the same time we are releasing a document describing what this new and weird features are, full of examples of how to use them, including a crash for MS05-039 (UMPNP remotely exploitable buffer overflow), writen in python using this library, which can be used as base for other DCERPC exploits and configured in lots of different ways to send non-standard and correct trafic. Some of the new features are: * NMB and SMB (high-level implementations). * DCE/RPC versions 4 and 5, over different transports: UDP (version 4 exclusively), TCP, SMB/TCP, SMB/NetBIOS and HTTP. * Multiple ways of doing SMB tree_connect, file open, read, write. * SMB fragmentation, SMB AndX command chaining. * Plain, NT and LM v1 authentications, using password and hashes only. * Portions of the following DCE/RPC interfaces: Conv, DCOM, EPM, SAMR, SvcCtl, WinReg. * DCERPC Alternate contexts, Multi-bind requests, Endianness selection * DCERPC NT and LM v1 authentication, integrity checking and encryption. * DCERPC v4 and v5 fragmentation, DCERPC v4 idempotent requests. take a look here: http://www.corest.com/common/showdoc.php?idx=539idxseccion=11 and send feedback, to us gera and beto
more MD5 colliding examples
hello everybody, last month we presented in a lightning talk at PacSec a few interesting and somehow new things related to MD5 collisions: 2 different Win32 .EXE files with the same MD5 hash, and 4 different files (inputs) with the same MD5 hash. These are direct results of reimplementing the already known attacks on MD5, specifically abusing the fact that collisions can be generated for arbitrary IVs. Today we are releasing some new stuff: - The 4 colliding files have been increased to 8 files (there is no real limit in the number of colliding files which can be generated, this is just an example of what can be done). - Two new Win32 .EXE files, this time with the same MD5 hash and also the same CRC32, the same checksum 32 and the same checksum 16. Of course all this is no big theoretical breakthrough, but it's somehow interesting to have examples to show to the incredulous. All the information (the files and presentation explaining how to regenerate the files) from PacSec is now available at http://www.corest.com/corelabs/projects/research_topics.php. have fun! gera
RSAREF2 buffer overflow patch
While exchanging emails with CERT about the problem in RSAREF2 they told me that somebody anonymous observed that there may be problem on the patch we released for RSAREF2. Together we produced a new version of this patch, which you can find in ftp://www.core-sdi.com/pub/patches/rsaref2.patch or at the end of this email. While we [Core SDI S.A.] and the CERT are not aware of any exploit that bypasses the checks performed by the previous version, this new version is more strict than the other, so we recommend you to use it. We still think that RSAREF's problem need to be solved a little better that with a patch, but still this is more than what we can legally do... while it's obligatory to use RSAREF [only] in the USA, nobody can legally alter its sources, so be careful when changing them. richie PS: You must apply this new patch to the original version of rsa.c. --- rsaref2.patch *** rsa.original.c Fri Mar 26 14:01:48 1994 --- rsa.c Fri Dec 10 12:56:34 1999 *** *** 33,38 --- 33,41 unsigned char byte, pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen; + if (publicKey-bits MAX_RSA_MODULUS_BITS) + return (RE_LEN); + modulusLen = (publicKey-bits + 7) / 8; if (inputLen + 11 modulusLen) return (RE_LEN); *** *** 78,83 --- 81,89 unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; + if (publicKey-bits MAX_RSA_MODULUS_BITS) + return (RE_LEN); + modulusLen = (publicKey-bits + 7) / 8; if (inputLen modulusLen) return (RE_LEN); *** *** 128,133 --- 134,142 int status; unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen; + + if (privateKey-bits MAX_RSA_MODULUS_BITS) + return (RE_LEN); modulusLen = (privateKey-bits + 7) / 8; if (inputLen + 11 modulusLen) *** *** 168,173 --- 177,185 unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; + if (privateKey-bits MAX_RSA_MODULUS_BITS) + return (RE_LEN); + modulusLen = (privateKey-bits + 7) / 8; if (inputLen modulusLen) return (RE_LEN); -- A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0 Investigacion y Desarrollo - CoreLabs - Core SDI http://www.core-sdi.com --- For a personal reply use [EMAIL PROTECTED]
Re: WordPad/riched20.dll buffer overflow
Solar Eclipse wrote: Just find me a single RET instruction and I will rule the world! 'ldkw' == 0x776B646C, in my NT4SP3 is a RET 8 [C2 08] in WS2_32.dll, the address we wish to return (the one in the heap you [Solar] said) would be reachable with this RET 8, and I managed to use this RET 8, several times ['ldkwldkwldkwldkwldkwldkwldkw...'], but suddenly it wants to return to 0x0102 that I couldn't change, I don't know why. Don't forget that there are other group of addresses that you can jump to (as Thomas Dullien said in vuln-dev) The original return address is something like 0x6C00 (who knows it?) so, using a by-one, by-two or by-three bytes buffer overflow you can jump to a different family of addresses, always with a 0x00 in the middle. By the way, I noticed that a single RET (with no argument) is still useful BUT you must take care of the 0x00 at the end of the ASCIIZ, so you need a return address some bytes after the beginning of the string in the HEAP (which I saw somewhere in the stack). First I said that if it's exploitable it would be really hard, now I say it again, being closer to a: 'it's not exploitable' (just matter of luck). Having in mind the differences between different incarnations of Wordpad in memory (DLLs, SPs, OSs,etc) richie -- A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0 Investigacion y Desarrollo - CoreLabs - Core SDI http://www.core-sdi.com --- For a personal reply use [EMAIL PROTECTED]
Re: WordPad/riched20.dll buffer overflow
Solar Eclipse wrote: When I tried this, I found out that code CAN be executed on the heap, although the heap descriptor has no execute permissions. I don't know why. If somebody can confirm this it would be great. I remember reading something about this i a book named Windows NT Device Driver Development, let me check it out... Ok, here it is, on page 58, it's talking about Access Control of virtual pages, and it says, literally if a page can be read, it can be executed. I remember that this took my attention for some days, then I forgot about it, until you mentioned it. richie -- A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0 Investigacion y Desarrollo - CoreLabs - Core SDI http://www.core-sdi.com --- For a personal reply use [EMAIL PROTECTED]
Re: ImmuniX OS Security Alert: StackGuard 1.21 Released
Crispin Cowan wrote:
Consider this vulnerable code:
foo(char * arg) {
char *p = arg;// a vulnerable pointer
char a[25];// the buffer that makes the pointer vulnerable
gets(a);// using gets() makes you vulnerable
gets(p);// this is the good part
}
In attacking this code, the attacker first overflows the buffer a[]
with
a goal of changing the value of the char * p pointer. Specifically,
the attacker can cause the p pointer to point anywhere in memory,
but especially at a return address record in an activation record.
When the program then takes input and stores it where p points, the
input data is stored where the attacker said to store it.
I think that having this kind of overflow available, StackWard is
still vulnerable to a little smarter attack.
You may think that this code example is too tricky, but there was a
buffer overflow in bind's inverse query
(http://www.securityfocus.com/vdb/bottom.html?vid=134) like this. This
makes me remember of some code I wrote to exploit this for Sparcs, as
it was just one call deep, it was imposible to overwrite the return
address, so, by using a memcpy() to a pointer I could overwrite (like
that one in
the example code) I overwrited part of the libc in memory, lets say
printf, so when the program called printf() after the second memcpy(),
instead of calling the original printf() it called my code: Here you
have an exploit that can be used still if you have StackWard.
Am I wrong?
Gerardo Richarte
--
Investigacion y Desarrollo - CoreLabs - Core SDI
http://www.core-sdi.com
--- For a personal reply use [EMAIL PROTECTED]
Re: WordPad/riched20.dll buffer overflow
Pauli Ojanpera wrote:
Just if someone needs to know...
Win98/NT4 Riched20.dll (which WordPad uses) has a classic buffer
overflow problem with ".rtf"-files.
Crashme.rtf :
{\rtf\}
A malicious document may probably abuse this to execute arbitary
code. WordPad crashes with EIP=41414141.
Someone else do deeper investigation since I don't care to.
I've been trying to determine if it's exploitable, and couldn't
reproduce what you described. I want to know if there is some other
information I need to know... here is what I tried:
an rtf file with
{\rtf\A...} a lot of As (tryed 32,49,1000,2000,...
5000...
2)
nothing happened until 5000, where I got a crash but not with
EIP==
0x41414141 but with ESI==0x41414141 on a 'push [esi]'. ESI was copyed
previously from the stack, but on the stack there where only 4 As here,
8 As there, a so...
then on 1 As I got a different crash, with EDI==0x41414141,
but
never got EIP==0x41414141.
Anyway, it MAY be exploitable, but doesn't look simple...
Then I tryed a differen aproach I got
http://www.securityfocus.com, I used a real rtf file and appended
the same amount (32,49,...) of As after the first '\', but got exactly
the same results...
could anybody reproduce this bug?
richie
--
A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0
Research and Developemen - CoreLabs - Core SDI (Information Security)
http://www.core-sdi.com
--- For a personal reply use [EMAIL PROTECTED]
