Java getSoundBank function Stack Overflow Vulnerability

Inking's home : Vulnerability Principle Specifically, the error function is Java's Native method Java.com. sun. media. sound. HeadspaceSoundbank. nOpenResource. This function directly copies the file path without checking the string size, resulting in stack overflow: // $ Kk: 04.11.99: we are never calling XFileClose !! JNIEXPORT jlong JNICALL Java_com_sun_media_sound_HeadspaceSoundbank_nOpenResource (JNIEnv * e, jobject thisObj, jstring path) { XFILE file = NULL; XFILENAME xfilename; Const char * str = (* e)-> GetStringUTFChars (e, path, 0 ); TRACE0 ("Java_com_sun_media_sound_HeadspaceSoundbank_nOpenResource ."); XConvertNativeFileToXFILENAME (void *) str, & xfilename ); File = XFileOpenResource (& xfilename, TRUE ); (* E)-> ReleaseStringUTFChars (e, path, str ); TRACE1 ("Java_com_sun_media_sound_HeadspaceSoundbank_nOpenResource completed, returning % lu.", file ); Return (jlong) (INT_PTR) file; } // Given a native file spec (FSSpec for MacOS, and C string for WinOS, fill in a XFILENAME Void XConvertNativeFileToXFILENAME (void * file, XFILENAME * xfile) { If (xfile) { XSetMemory (xfile, (INT32) sizeof (XFILENAME), 0 ); } If (file) { # If USE_HAE_EXTERNAL_API = TRUE { Void * dest; Dest = & xfile-> theFile; HAE_CopyFileNameNative (file, dest ); } # Else # If X_PLATFORM = X_MACINTOSH Xfile-> theFile = * (FSSpec *) file ); # Endif # If (X_PLATFORM = X_WINDOWS) | (X_PLATFORM = X_WIN_HARDWARE) | (X_PLATFORM = X_BE) | (X_PLATFORM = X_SOLARIS) | (X_PLATFORM = X_LINUX) | (X_PLATFORM = X_NAVIO )) XStrCpy (char *) xfile-> theFile, (char *) file ); # Endif # Endif } } Struct XFILENAME { // Public platform specific # If X_PLATFORM = X_MACINTOSH XFILE_HANDLE fileReference; FSSpec theFile; # Endif # If (X_PLATFORM = X_WINDOWS) | (X_PLATFORM = X_WIN_HARDWARE) | (X_PLATFORM = X_WEBTV) | (X_PLATFORM = X_BE) | (X_PLATFORM = X_SOLARIS) | (X_PLATFORM = X_LINUX) | (X_PLATFORM = X_NAVIO )) /* $ Fb 2002-02-14: itanium port */ XFILE_HANDLE fileReference; Char theFile [FILE_NAME_LENGTH]; // "C" string name for path # Endif // Private variables. Zero out before calling functions INT32 fileValidID; XBOOL resourceFile; XPTR pResourceData; // if file is memory based INT32 resMemLength; // length of memory resource file INT32 resMemOffset; // current offset of memory resource file XBOOL readOnly; // TRUE then file is read only XBOOL allowMemCopy; // if TRUE, when a memory based resource is // Read, a copy will be created otherwise // Its just a pointer into the larger memory resource // File XFILE_CACHED_ITEM memoryCacheEntry; XFILERESOURCECACHE * pCache; // if file has been cached this will point to it }; Typedef struct XFILENAME; Typedef void * XFILE; // Standard strcpy // Copies C string src into dest Char * XStrCpy (char * dest, char * src) { Char * sav; Sav = dest; If (src = NULL) { Src = ""; } If (dest) { While (* src) { * Dest ++ = * src ++; } * Dest = 0; } Return sav; } The above FILE_NAME_LENGTH is _ MAX_PATH in windows, that is, 256, so as long as the url-> filename is greater than 256, it will overflow. There is another key point: HeadspaceSoundbank (URL url) throws IOException { If (Printer. trace) Printer. trace ("HeadspaceSoundbank: constructor: url:" + url ); String protocol = url. getProtocol (); If (! (Protocol. equals ("file "))){ InputStream stream = url. openStream (); Try { Initialize (stream, false ); } Catch (IllegalArgumentException e ){ Stream. close (); Throw e; } } Else { String path = url. getFile (); Initialize (path); // come here } If (Printer. trace) Printer. trace ("HeadspaceSoundbank: constructor: url:" + url + "completed "); } : Vulnerability Exploitation The vulnerability principle is simple, but it is not so easy to use. In the first place, although the loopholes are exposed by Internet Explorer, java.exe is the final process of execution. Therefore, it cannot be exploited through simple JavaScript heap injection. If java heap injection is directly implemented in java.exe, it will be better, but in fact there are many problems. The most troublesome problem is that the java heap size is only 64 MB by default, and if the gc frequency is too high, jvm directly throws an exception. So after several attempts, I temporarily gave up this path. There is also a way to exploit stack overflow. However, this method also has several problems. Fortunately, we have enough space to write Shellcode. We can use jmp esp to locate Shellcode directly. The most tricky issue is character encoding. During the exploitation process, the size of the jump address and Shellcode must be less than 0x80 (java is learning, and may have blind spots ), otherwise, it will be messy due to Character Set Issues. Shellcode is better solved within 0x80, because esp just points to Shellcode. Using alpha2 encoding, Shellcode can eventually be all visible characters. Jmp esp (call esp) is troublesome because many stable opcode addresses are on kernel32 and ntdll, the base address for loading the two is depressing (for example, the value of kernel32.dll is 0x7c800000), and you cannot find a dynamic link library similar to shell32.dll, so I finally locked several dynamic link libraries of java itself, hoping to get the version number through java code, and then calculate different opcode addresses based on different version numbers. : PoC The opcode in PoC can be found at will. The test environment is xp sp2 and jre 6.0.160.1. //////////////////////////////////////// //////////////////////////////////////// //////////////// Import java. applet. Applet; Import java. awt. Graphics; Import java. io. CharArrayWriter; Import java. io. PrintStream; Import java. lang. reflect. Array; Import java.net. URL; Import javax. sound. midi. MidiSystem; Import javax. sound. midi. Soundbank; Import javax. sound. midi. Synthesizer; Public class test extends Applet { Pub