|
/
Zope
/
Apsis
/
Pound Mailing List
/
Archive
/
2011
/
2011-11
/
RE: [Pound Mailing List] Disabling SSLv2
[
Disabling SSLv2 / Robert Hicks ... ]
[
Unsubscibe / Nelson Pereira ... ]
RE: [Pound Mailing List] Disabling SSLv2
Joe Gooch <mrwizard(at)k12system.com> |
2011-11-28 19:13:14 |
[ SNIP ]
|
You probably want to do something more like:
Ciphers “HIGH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL”
But that should pretty much do it.
Maybe try the tester at https://www.ssllabs.com/ssldb/index.html and see what
it says about your sslv2 support.
There’s an option that can be set in the pound code (SSL_OP_NO_SSLv2)… But I’m
not sure if it’s going to help or not. If you want to try it, open config.c
and replace all instances of SSL_OP_ALL with SSL_OP_ALL|SSL_OP_NO_SSLv2
Otherwise, you may want to try compiling openssl without sslv2 support.
(http://adamyoung.net/Disable-SSLv2-System-Wide) I believe ubuntu does this
as part of their distro. (which is making it harder for me to test, because my
libraries don’t support sslv2 anyway)
Let me know what you find!
Joe
From: Robert Hicks [mailto:rob(at)hixfamily.org]
Sent: Monday, November 28, 2011 11:57 AM
To: pound(at)apsis.ch
Subject: [Pound Mailing List] Disabling SSLv2
All,
I'm new the list but have been using Pound for several years.
I'm trying to get Pound to pass PCI/DSS.
My scanning vendor is failing it, indicating that SSLv2 is enabled. My Ciphers
parameter in pound.cfg is as follows:
ListenHTTPS
Address 0.0.0.0
Port 443
Cert "/etc/contractpal.net.pem"
Err414 "/etc/pound_414.html"
Err500 "/etc/pound_500.html"
Err501 "/etc/pound_501.html"
Err503 "/etc/pound_503.html"
Ciphers "-ALL +SSLv3 +TLSv1"
When I run a test to see if Pound is accepting SSLv2 connections, I get the
following:
New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv2
What do I need to do to disable SSLv2?
Rob
|
|
|
|
|
RE: [Pound Mailing List] Pound CSRF vulnerability in redirects
Joe Gooch <mrwizard(at)k12system.com> |
2011-11-28 22:18:51 |
[ SNIP ]
|
You can define a CheckURL directive to trap the invalid characters. (for
instance, I don't believe < or > can appear inline in a URL, it would have to
be % escaped)
http://stackoverflow.com/questions/1547899/which-characters-make-a-url-invalid
Thus you might want to include a line such as:
CheckURL "^[!#$&-;=?-[]_a-zA-Z~]+$"
(note the regex is based on the Leif Wickland responder... You might want to
check the &-; and ?-[ ranges, for instance. I take no responsibility for
correctness in your environment)
Given the URL you have supplied the URL would throw a 500 error based on the "
in your request and the <> characters.
Joe
> -----Original Message-----
> From: Kevin Bowling [mailto:kevin.bowling(at)kev009.com]
> Sent: Friday, November 18, 2011 1:04 AM
> To: pound(at)apsis.ch
> Subject: Re: [Pound Mailing List] Pound CSRF vulnerability in redirects
>
> Here is what the system claims the actual exploit looks like>
>
> HTTP/1.0 301 Moved Permanently
> Location:
> https://<domain>.com:7443/"><script>alert(document.domain)</script>.htm
> l
> Content-Type: text/html
> Content-Length: 264
>
> <html><head><title>Redirect</title></head><body> Redirect You should
> go to
> <script>alert(document.domain)</script>.html">https://<domain>.com:7443
> /"><script>alert(document.domain)</script>.html
> (https://<domain>.com:7443/)</p></body></html>
>
> GET /"><script>alert(document.domain)</script>.html HTTP/1.0
> Host: <ip>:7080
> User-Agent: QualysGuard
>
> On Thu, Nov 17, 2011 at 5:07 PM, Kevin Bowling
> <kevin.bowling(at)kev009.com> wrote:
> > Hi,
> >
> > This is very low risk because any browser that doesn't obey the HTTP
> > 301 code is likely ancient and vulnerable.
> >
> > One place this matters is automated scanning tools. I have a system
> > that is being audited for PCI compliance by a tool from qualys which
> > is basically a glorified port scanner. It passes in a
> > <script></script> nonsense on the URL and sure enough pound repeats
> > this in the document fallback if the HTTP 301 redirect is not obeyed.
> >
> > It is a bad idea, the URL should be scrubbed (hard), or simply
> > repeated without an <a href=...> and let the user figure it out?
> >
> > Regards,
> > Kevin
> >
> > --
> > To unsubscribe send an email with subject unsubscribe to
> pound(at)apsis.ch.
> > Please contact roseg(at)apsis.ch for questions.
> >
>
> --
> To unsubscribe send an email with subject unsubscribe to
> pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
|
|
|
RE: [Pound Mailing List] Disabling SSLv2
Joe Gooch <mrwizard(at)k12system.com> |
2011-11-28 22:27:17 |
[ SNIP ]
|
Glad to hear it!
Joe
From: Robert Hicks [mailto:rob(at)hixfamily.org]
Sent: Monday, November 28, 2011 4:25 PM
To: Joe Gooch
Subject: Re: [Pound Mailing List] Disabling SSLv2
Joe,
Your Ciphers suggestion worked.
Thanks!
Rob
On Mon, Nov 28, 2011 at 11:13 AM, Joe Gooch
<mrwizard(at)k12system.com<mailto:mrwizard(at)k12system.com>> wrote:
You probably want to do something more like:
Ciphers “HIGH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL”
But that should pretty much do it.
Maybe try the tester at https://www.ssllabs.com/ssldb/index.html and see what
it says about your sslv2 support.
There’s an option that can be set in the pound code (SSL_OP_NO_SSLv2)… But I’m
not sure if it’s going to help or not. If you want to try it, open config.c
and replace all instances of SSL_OP_ALL with SSL_OP_ALL|SSL_OP_NO_SSLv2
Otherwise, you may want to try compiling openssl without sslv2 support.
(http://adamyoung.net/Disable-SSLv2-System-Wide) I believe ubuntu does this
as part of their distro. (which is making it harder for me to test, because my
libraries don’t support sslv2 anyway)
Let me know what you find!
Joe
From: Robert Hicks [mailto:rob(at)hixfamily.org<mailto:rob(at)hixfamily.org>]
Sent: Monday, November 28, 2011 11:57 AM
To: pound(at)apsis.ch<mailto:pound(at)apsis.ch>
Subject: [Pound Mailing List] Disabling SSLv2
All,
I'm new the list but have been using Pound for several years.
I'm trying to get Pound to pass PCI/DSS.
My scanning vendor is failing it, indicating that SSLv2 is enabled. My Ciphers
parameter in pound.cfg is as follows:
ListenHTTPS
Address 0.0.0.0
Port 443
Cert "/etc/contractpal.net.pem"
Err414 "/etc/pound_414.html"
Err500 "/etc/pound_500.html"
Err501 "/etc/pound_501.html"
Err503 "/etc/pound_503.html"
Ciphers "-ALL +SSLv3 +TLSv1"
When I run a test to see if Pound is accepting SSLv2 connections, I get the
following:
New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv2
What do I need to do to disable SSLv2?
Rob
|
|
|
|
|
RE: [Pound Mailing List] AddHeader directive honored
Joe Gooch <mrwizard(at)k12system.com> |
2011-11-28 23:32:36 |
[ SNIP ]
|
I agree this should be fixed... and your solution looks workable. Not sure if
Robert would rather a linked list, a char *[] array, or the resizing buffer...
Regardless we should be using the rm_eo-rm_so to determine length and probably
can use realloc instead of malloc.
The cookie generation patch was posted and should work for you, but has not
been merged into mainline.
Joe
> -----Original Message-----
> From: Francisco Ruiz [mailto:francisco.ruiz(at)juntaextremadura.es]
> Sent: Tuesday, November 15, 2011 4:42 PM
> To: pound(at)apsis.ch
> Subject: [Pound Mailing List] AddHeader directive honored
>
> Hi,
>
> I send a patch to the list so that it can be considered and merged to
> the main code if accepted.
>
> We need to add several headers to the request but it seems that
> AddHeader just honors the last occurrence of the directive. Even more,
> several AddHeader directives doesn't rise an error or warning. All of
> them are processed and the string created with previus strdup() call
> seems not to be freed.
>
> The patch sent:
> * modify config.c to concatenate all the headers in the LISTENER
> struct member add_head with the needed "\r\n".
> * modify the comment to LISTENER struct member add_head to reflect
> that AddHeader works also with HTTP an not only HTTPS, in pound.h
> * modify man page pound.8 to reflect the changes.
>
> I hope it can be of any help for others.
>
> On the other hand, I would like to know about the patch that someone
> send to the list to get sticky sessions by injecting cookies in the
> replies to client, as other commercial products do. Are there any plans
> to merge it?
>
> Thanks for pound and to all the community arround it.
>
> --
> Francisco Ruiz
> francisco.ruiz(at)juntaextremadura.es
>
> Ahorrar papel protege el medio ambiente
|
|
|
RE: [Pound Mailing List] Pound CSRF vulnerability in redirects
Joe Gooch <mrwizard(at)k12system.com> |
2011-11-29 16:23:56 |
[ SNIP ]
|
This may be more realistic... at least for most urls I've worked with. It's not
all-inclusive of every possible url pattern.
CheckURL "^[A-Za-z0-9\.\/]+(\?[A-Za-z0-9=\.&]*)?(;[A-Za-z0-9=\.&]*)?$"
Also note from looking at the code, it looks like CheckURL runs *after* URL
encoded expansion. Which means, if your url has a %3c in it, it'll be expanded
to <, and then checked against the regex, and get rejected. Which might not be
a problem for you.
Ultimately I think the solution is Pound needs to write the redirect page using
URL encoding for the href link, and maybe the word "here" for the link text.
(like, for instance, apache would) If it's going to write out the link text it
should be html entity encoded.
I passed the URLs you gave into apache and it had no problem printing an
appropriate redirect page, and/or attempting to find that type of file on the
filesystem.... so... yeah.
Joe
> -----Original Message-----
> From: Kevin Bowling [mailto:kevin.bowling(at)kev009.com]
> Sent: Tuesday, November 29, 2011 1:43 AM
> To: pound(at)apsis.ch
> Subject: Re: [Pound Mailing List] Pound CSRF vulnerability in redirects
>
> This looks like pretty close to what I want but there's an error (i.e.
> the regex fails to work on any normal URL I've tried). Not
> particularly strong here, any help?
>
> Regards,
> Kevin
>
> On Mon, Nov 28, 2011 at 2:18 PM, Joe Gooch <mrwizard(at)k12system.com>
> wrote:
> > You can define a CheckURL directive to trap the invalid characters.
> (for instance, I don't believe < or > can appear inline in a URL, it
> would have to be % escaped)
> >
> > http://stackoverflow.com/questions/1547899/which-characters-make-a-
> url-invalid
> >
> > Thus you might want to include a line such as:
> > CheckURL "^[!#$&-;=?-[]_a-zA-Z~]+$"
> >
> > (note the regex is based on the Leif Wickland responder... You might
> want to check the &-; and ?-[ ranges, for instance. I take no
> responsibility for correctness in your environment)
> >
> > Given the URL you have supplied the URL would throw a 500 error based
> on the " in your request and the <> characters.
> >
> > Joe
> >
> >> -----Original Message-----
> >> From: Kevin Bowling [mailto:kevin.bowling(at)kev009.com]
> >> Sent: Friday, November 18, 2011 1:04 AM
> >> To: pound(at)apsis.ch
> >> Subject: Re: [Pound Mailing List] Pound CSRF vulnerability in
> redirects
> >>
> >> Here is what the system claims the actual exploit looks like>
> >>
> >> HTTP/1.0 301 Moved Permanently
> >> Location:
> >>
> https://<domain>.com:7443/"><script>alert(document.domain)</script>.htm
> >> l
> >> Content-Type: text/html
> >> Content-Length: 264
> >>
> >> <html><head><title>Redirect</title></head><body> Redirect You
> should
> >> go to
> >>
> <script>alert(document.domain)</script>.html">https://<domain>.com:7443
> >> /"><script>alert(document.domain)</script>.html
> >> (https://<domain>.com:7443/)</p></body></html>
> >>
> >> GET /"><script>alert(document.domain)</script>.html HTTP/1.0
> >> Host: <ip>:7080
> >> User-Agent: QualysGuard
> >>
> >> On Thu, Nov 17, 2011 at 5:07 PM, Kevin Bowling
> >> <kevin.bowling(at)kev009.com> wrote:
> >> > Hi,
> >> >
> >> > This is very low risk because any browser that doesn't obey the
> HTTP
> >> > 301 code is likely ancient and vulnerable.
> >> >
> >> > One place this matters is automated scanning tools. I have a
> system
> >> > that is being audited for PCI compliance by a tool from qualys
> which
> >> > is basically a glorified port scanner. It passes in a
> >> > <script></script> nonsense on the URL and sure enough pound
> repeats
> >> > this in the document fallback if the HTTP 301 redirect is not
> obeyed.
> >> >
> >> > It is a bad idea, the URL should be scrubbed (hard), or simply
> >> > repeated without an <a href=...> and let the user figure it out?
> >> >
> >> > Regards,
> >> > Kevin
> >> >
> >> > --
> >> > To unsubscribe send an email with subject unsubscribe to
> >> pound(at)apsis.ch.
> >> > Please contact roseg(at)apsis.ch for questions.
> >> >
> >>
> >> --
> >> To unsubscribe send an email with subject unsubscribe to
> >> pound(at)apsis.ch.
> >> Please contact roseg(at)apsis.ch for questions.
> >
> > --
> > To unsubscribe send an email with subject unsubscribe to
> pound(at)apsis.ch.
> > Please contact roseg(at)apsis.ch for questions.
> >
>
> --
> To unsubscribe send an email with subject unsubscribe to
> pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
|
|
|
RE: [Pound Mailing List] Pound CSRF vulnerability in redirects
Joe Gooch <mrwizard(at)k12system.com> |
2011-11-29 19:03:06 |
[ SNIP ]
|
It works for me here in testing... Are you linked against pcreposix?
Even so, yeah if you have the time, patches against http.c redirect_reply()
would probably be the best solution.
Joe
> -----Original Message-----
> From: Kevin Bowling [mailto:kevin.bowling(at)kev009.com]
> Sent: Tuesday, November 29, 2011 12:42 PM
> To: pound(at)apsis.ch
> Subject: Re: [Pound Mailing List] Pound CSRF vulnerability in redirects
>
> Still not working for even the simplest of URLs.
>
> I agree with the Apache style redirect (escaped URL/"here" text).
> I'll write some patches later today when I have time.
>
> Regards,
> Kevin
>
> On Tue, Nov 29, 2011 at 8:23 AM, Joe Gooch <mrwizard(at)k12system.com>
> wrote:
> > This may be more realistic... at least for most urls I've worked
> with. It's not all-inclusive of every possible url pattern.
> >
> > CheckURL "^[A-Za-z0-9\.\/]+(\?[A-Za-z0-9=\.&]*)?(;[A-Za-z0-
> 9=\.&]*)?$"
> >
> >
> > Also note from looking at the code, it looks like CheckURL runs
> *after* URL encoded expansion. Which means, if your url has a %3c in
> it, it'll be expanded to <, and then checked against the regex, and get
> rejected. Which might not be a problem for you.
> >
> > Ultimately I think the solution is Pound needs to write the redirect
> page using URL encoding for the href link, and maybe the word "here"
> for the link text. (like, for instance, apache would) If it's going to
> write out the link text it should be html entity encoded.
> >
> > I passed the URLs you gave into apache and it had no problem printing
> an appropriate redirect page, and/or attempting to find that type of
> file on the filesystem.... so... yeah.
> >
> > Joe
|
|
|
RE: [Pound Mailing List] Pound CSRF vulnerability in redirects
Joe Gooch <mrwizard(at)k12system.com> |
2011-11-29 19:32:49 |
[ SNIP ]
|
Or I could do it!
http://goochfriend.org/pound_2.6f_xss_redirect_fix.patch
Joe
> -----Original Message-----
> From: Joe Gooch [mailto:mrwizard(at)k12system.com]
> Sent: Tuesday, November 29, 2011 1:03 PM
> To: 'pound(at)apsis.ch'
> Subject: RE: [Pound Mailing List] Pound CSRF vulnerability in redirects
>
> It works for me here in testing... Are you linked against pcreposix?
>
> Even so, yeah if you have the time, patches against http.c
> redirect_reply() would probably be the best solution.
>
> Joe
>
> > -----Original Message-----
> > From: Kevin Bowling [mailto:kevin.bowling(at)kev009.com]
> > Sent: Tuesday, November 29, 2011 12:42 PM
> > To: pound(at)apsis.ch
> > Subject: Re: [Pound Mailing List] Pound CSRF vulnerability in
> redirects
> >
> > Still not working for even the simplest of URLs.
> >
> > I agree with the Apache style redirect (escaped URL/"here" text).
> > I'll write some patches later today when I have time.
> >
> > Regards,
> > Kevin
> >
> > On Tue, Nov 29, 2011 at 8:23 AM, Joe Gooch <mrwizard(at)k12system.com>
> > wrote:
> > > This may be more realistic... at least for most urls I've worked
> > with. It's not all-inclusive of every possible url pattern.
> > >
> > > CheckURL "^[A-Za-z0-9\.\/]+(\?[A-Za-z0-9=\.&]*)?(;[A-Za-z0-
> > 9=\.&]*)?$"
> > >
> > >
> > > Also note from looking at the code, it looks like CheckURL runs
> > *after* URL encoded expansion. Which means, if your url has a %3c in
> > it, it'll be expanded to <, and then checked against the regex, and
> get
> > rejected. Which might not be a problem for you.
> > >
> > > Ultimately I think the solution is Pound needs to write the
> redirect
> > page using URL encoding for the href link, and maybe the word "here"
> > for the link text. (like, for instance, apache would) If it's going
> to
> > write out the link text it should be html entity encoded.
> > >
> > > I passed the URLs you gave into apache and it had no problem
> printing
> > an appropriate redirect page, and/or attempting to find that type of
> > file on the filesystem.... so... yeah.
> > >
> > > Joe
>
> --
> To unsubscribe send an email with subject unsubscribe to
> pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
|
|
|
|
