java/00 file path truncation vulnerability with parsing for Windows and pair. NET comparison

author:kj021320
Team:i.s.t.o

JAVA Web File Upload is the name of the file submitted by the user, not from the random to take the machine number is worth noting
Asp+ado with the past. Stream upload vulnerability is equally
Because the Windows platform does not support file directories or file names with/00 characters
So Java although platform-independent but his low-level operations must be the platform to invoke the API so it will inevitably have some platform-related
Security vulnerabilities or vulnerabilities that the Java language developers can't take care of. OK, here's a simple code example

String filepath= "c://kj021320.jsp" + (char) 0+ ". txt";
SYSTEM.OUT.PRINTLN (filepath);
FileOutputStream fos=new FileOutputStream (filepath);
Fos.write ("Hello". GetBytes ());
Fos.close ();
byte [] b=new byte[100];
int i=0;
FileInputStream fis=new FileInputStream (filepath);
I=fis.read (b);
Out.println (New String (b,0,i));
Fis.close ();

and see what output it has.

OK, all of them have been tested under the code. Let's analyze the JVM's final call process
To implement from source to inner core
First analyze the FileOutputStream class constructor
This constructor calls another constructor
Public FileOutputStream (String name) throws FileNotFoundException {
This (name!= null? New File (name): null, FALSE);
}
Here is the concrete implementation of the call to another constructor
Public fileoutputstream (File file, Boolean append) throws FileNotFoundException
{
String name = (file!= null file.getpath (): null);
SecurityManager security = System.getsecuritymanager ();
if (security!= null) {
Security.checkwrite (name)//Do security check Java sandbox have permission to write
}
if (name = = null) {
throw new NullPointerException ();
}
FD = new FileDescriptor ();
This.append = append;
if (append) {
Openappend (name);//Call Openappend
} else {
Open (name); Call Open
}
}

After analyzing the 2 construction methods above the FileOutputStream class, we can continue to follow.
Look at the implementation of the Open Openappend

Private native void open (String name) throws FileNotFoundException;
Private native void Openappend (String name) throws FileNotFoundException;
But we regret that. Two methods are local code implementation ~ Is it over here? No ~  JDK6 previous source code Sun company is not published. But we can go to download the
OPENJDK http://openjdk.java.net/all the source code estimates are similar.
Open the OPENJDK source code OPENJDK/J2SE/SRC/WINDOWS/NATIVE/JAVA/IO/FILEOUTPUTSTREAM_MD.C directory will have
FileOutputStream The JNI implementation of this class
Java_java_io_fileoutputstream_open (jnienv *env, jobject this, jstring path) {
    FileOpen (env, this, path, FOS_FD, O_wronly | O_creat | O_TRUNC);
}
called FileOpen to continue tracking, which is implemented in IO_UTIL_MD.C this file
void FileOpen (jnienv *env, jobject This, jstring path, Jfieldid FID, int flags) {
    jlong h = winfilehandleopen (env, path, flags);
    if (H >= 0) {
        set_fd (this, h, FID);
   }
}
It appears that the Winfilehandleopen function is also called Win32API to create the file. Needless to say, continue

Jlong Winfilehandleopen (jnienv *env, jstring path, int flags) {
Const DWORD Access =
(Flags & O_RDWR)? (Generic_write | Generic_read):
(Flags & o_wronly)? Generic_write:
Generic_read;
Const DWORD sharing =
File_share_read | File_share_write;
Const DWORD Disposition =
/* Note:o_trunc Overrides O_creat * *
(Flags & O_trunc)? Create_always:
(Flags & o_creat)? Open_always:
open_existing;
Const DWORD Maybewritethrough =
(Flags & (O_sync | O_dsync))?
File_flag_write_through:
File_attribute_normal;
Const DWORD Maybedeleteonclose =
(Flags & o_temporary)?
File_flag_delete_on_close:
File_attribute_normal;
Const DWORD Flagsandattributes = Maybewritethrough | Maybedeleteonclose;
HANDLE h = NULL;

if (onnt) {
WCHAR *pathbuf = Pathtontpath (env, Path, jni_true);
if (pathbuf = = NULL) {
/* Exception already pending * *
return-1;
}
H = Createfilew (
PATHBUF,/* Wide char path name/*
Access,/* Read and/or Write permission * *
Sharing, * File sharing flags * *
NULL,/* Security attributes * *
disposition,/* Creation Disposition * *
Flagsandattributes, * flags and attributes * *
NULL);
Free (PATHBUF);
} else {
With_platform_string (env, PATH, _ps) {
h = CreateFile (_ps, access, sharing, NULL, disposition,
Flagsandattributes, NULL);
} end_platform_string (env, _PS);
}
if (h = = Invalid_handle_value) {
int error = GetLastError ();
if (Error = = Error_too_many_open_files) {
Jnu_throwbyname (env, jnu_javaiopkg "IOException",
"Too many open files");
return-1;
}
Throwfilenotfoundexception (env, PATH);
return-1;
}
Return (Jlong) H;
}
A simple look at the above code is ultimately called Createfilew to create a file
And he's using the Pathtontpath function to convert the path. There are no pairs/00 character filters that cause the vulnerability under Windows platform

OK, now let's take a look. NET's performance. First, analyze his file operations class
Open a Reflector.exe anti-compiler FileStream too many constructors I'm not going to post it. He will eventually invoke the method of the path class to validate
internal static void Checkinvalidpathchars (string path)
{
if ( -1!= path. IndexOfAny (Internalinvalidpathchars))
{
throw new ArgumentException (environment.getresourcestring ("Argument_invalidpathchars"));
}
}
The above code if it contains illegal characters. will throw an exception ~
See how internalinvalidpathchars is defined.
Internalinvalidpathchars = new char[] {' ', ' < ', ' > ', ' | ', '/0 ', '/b ', '/x0010 ', '/x0011 ', '/x0012 ', '/x0014 ', '/x0 015 ', '/x0016 ', '/x0017 ', '/x0018 ', '/x0019 '};
Well, it looks like. NET done more fully on Ms platform

Oh. YY a bit
WINDOWS: 555~~java You don't understand my heart. "
JAVA: "Khan ~ ~ ~ ..."
. NET: "My site is my decision ... Gaga