Bugtraq mailing list archives
Re: Netscape Exploit... with technical details.
From: robin.hood () IBM NET (Edwin Li-Kai Liu)
Date: Sat, 14 Jun 1997 18:04:57 +0700
Rusty Conover wrote:
In my method JavaScript would have to be used to automatically submit a HTML Form to the server. In these forms a page writer could have already coded the file name into the source document, such as "autoexec.bat". When the browser loads the page off of the server, it submits the form which transmits the file to the server via the HTTP-File upload procedure. The SERVER now has the file the author wanted. To fool the user, the CGI program sends the location of the real web page to the client, and the client doesn't know otherwise. This method would require the files to be small or else the user will notice this is taking a long time to load the page over a modem. But the potential for this exploit to be used over faster transmission lines is greater. To have a solution to this problem would be a warning dialog box, telling the user that they are transmitting a file not just a regular HTTP form. I have not written a single line of code exploiting this potential vulnerability, I might get around to it if I have time. Please note: I sent this original message 1 day (June 12) before to Netscape and now they confirm that my hypothesis was correct on the URL: http://home.netscape.com/misc/security_update.html
Yes, this is absolutely correct. You have proved my points also. Please see my message on netscape.security newsgroup, titled "Re: Security BUG". I have then post the same message to other newsgroups one day after, which is today. I want public to know the truth, instead of being panic. The following is the original message. -------------------------------------------------------------------------- This is probably caused by the support of <INPUT TYPE=FILE> tag. This tag allows you to send a file to a server side CGI program with the multi-part mime type. As it is an "Input type" tag, you can assign a default value to it. You can than write maybe a Java or a JavaScript to force submit the form data containing the content of the specified file to your CGI program. The reason why I think so is because I know GeoCities uses this method to upload the homepage files, which is another way to give out the file, but requires the knowledge of the complete path name and file name. If GeoCities' file uploader works in IExplorer, then IE is vulnerable as well. I am not sure if this is a correct information about the bug. If it is, please go ahead and shut my mouth and remove this message from the newsgroup. The purpose of this message is just to make sure if I was right. I post this message here because I trust the people around here. I have to disclaim that there is no leak of information about this security bug. All of the above came from my 50% imagination and 50% creativity. (Maybe 10% extra from my IQ ...... :-) ) I think this bug is very useless because I think no webmaster would want to get the files with the specified file name from the clients. First of all, the client may be using a different settings, having a different environments, etc. You cannot actually guess someone's file name that easy. For example, I have a file stored in the root of my third HD (the second partition of my second hard drive), named "passwords.txt" that stores all the userids and passwords of my currently using accounts. However, the file could be also named "passwd.txt," "pass.txt," or even with a different extension. Also not everyone has the third hard drive though. Who knows? (I also have to tell that in order to prevent somebody from using the information above and try to get this file and flood up all my accounts, I have encrypted it using my very own encryption method, which is only availiable for myself. Anyway.) -- Robin Hood ------------------------------------ Dreaming of a butterfly, fly into the sky. ¹Ú·QÅܦ¨½¹½º¡A¸¤W¤ÑªÅ¡C
Current thread:
- Re: Netscape Exploit... with technical details. Edwin Li-Kai Liu (Jun 14)
- <Possible follow-ups>
- Re: Netscape Exploit... with technical details. Phear (Jun 14)