Thanks for the input on this. While both my post here and on the MS newsgroups failed to elicit detailed specifics as to what exploits were being prevented by blocking these particular characters, these responses were useful and definitely preferable to what I received yesterday from MS PSS. Their answer was 'We know, but for security reasons we cannot tell you.' ( A snide aside: Thanks, MS. That took five phone calls, five emails, and you still have not agreed to non-decrement the case.)
On a much more positive front, I received an excellent response from Rand Morimoto ([EMAIL PROTECTED]), author of the book "Exchange 2003 Unleashed". My query to Rand was to help explain the two most problematic character blocks (from a customer irritation point a view) - the '..' and the '&'. Rand's response was as follows: "The '..' in a URL allows for traversal of the directory tree. This means that when I get access to one location on an Exchange server, I can send a .. command and walk "up" the directory tree. This can actually be minimized by having tight security rights, so I really don't see a problem with that issue. The '&' is more of a problem because that allows you to "string together" multiple commands. So you can tell an IIS server to open an email and to launch an executable at the same time. However this too can be minimized as a risk by hardening the server so that someone cannot hack the server to then launch an executable (i.e. I send an email to someone with an attachment, I somehow know that persons logon/password, I then "open and launch" the executable that brings the whole network down). This "presumes" that you allow executables into your network AND it presumes that someone has their user account compromised. But it's possible." "So by themselves, the ability to bypass URLScan for these commands, while it does weaken security, requires a couple other compromises to take place in your environment. Another option is go to IIS6 / Exchange 2003 OWA. IIS6 has functionality that allows you to run and access messages that may otherwise be URLScan compromising, however Exchange 2003 / IIS6 have better protections to allow access without restricting accessibility while minimizing security risks." The bottom line in our environment is that we will open the '..' and '&' for OWA, and let other security measures handle the potential risks. Jon -----Original Message----- From: Martin, Jon Sent: Thursday, October 16, 2003 5:20 PM Posted To: exchange - new Conversation: OWA and URLScan-Blocked Special Characters Subject: OWA and URLScan-Blocked Special Characters OK, we all know that when you run Urlscan on an Exchange server that you will not be able to view certain notes in OWA, specifically those notes with special characters in the subject line. The special characters are below, along with the reason, according to MS documentation, that these should be blocked. .. Allows directory traversals ./ Allows trailing dot on a directory name \ Allows backslashes in URL % Allows escaping after normalization & Allows multiple CGI processes to run on a single request My management wants these characters unblocked. To prevent this I need a better understanding of what potential problems are being prevented by the disabling of these characters. The above explanation in the MS documentation is probably not going to be sufficient. Does anyone have a more detailed explanation of the possible exploits being blocked by disabling these characters?? Thanks. Jon Martin _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
