Re: Totally exploitable on college campuses
You have totally misunderstood the nature of the bug. Putting an HTML or batch file in the folder would not trigger it. The server housing the share would have to be modified to send a specially-crafted response so that when a request to a specific file or folder on the share is made that the requesting workstation looks at a local file instead. The server never gains access to the files to which it redirects, only the workstation.
So, lets say that you either compromise an existing server, or set up a honeypot. On that server you create a share called "downloadme" and put a file called "passwords.txt" in it.
Now, when the unsuspecting user tries to notepad \\honeypot\downloadme\passwords.txt your compromised server can instead point them to a file on their C: partition, such as c:\boot.ini
The interesting thing would be if the user tried to delete \\honeypot\downloadme\passwords.txt and would instead delete their own boot.ini -- but tricking a user into deleting a file wouldn't be very easy.
The idea behind the HTML exploit using XMLHttpRequest is that the javascript on the HTML file could make a request to the mount point and get a file off of the C: drive -- however, as the code runs on the workstation and not the server the exploit could just as easily access the file directly without having to rely on the bug.
The same exploit running on a non-compromised server pointing directly to the local file would accomplish the same thing, and would actually be easier to implement. As such, labeling this as a "security bug" is stretching things a bit.