From dirk at owasp.org Thu Feb 6 15:58:35 2014 From: dirk at owasp.org (Dirk Wetter) Date: Thu, 06 Feb 2014 16:58:35 +0100 Subject: [Mod_nss-list] mod_nss and faked header = unvalidated redirect? Message-ID: <52F3B12B.5020909@owasp.org> Hi, one to two questions. Are there any known bugs or config variables which prevent this from happening and is that reproducible? ----snip curl -v -L -i -k -X 'GET' -H 'Host: ' [..SSL handshake..] GET / HTTP/1.1 > Accept: */* > [..rest of header omitted ..] > Host: BADHOST <---------! * upload completely sent off: 48out of 48 bytes < HTTP/1.1 302 Moved Temporarily HTTP/1.1 302 Moved Temporarily < Date: Mon, 03 Feb 2014 15:00:04 GMT Date: Mon, 03 Feb 2014 15:00:04 GMT < Server: Apache Server: Apache < Location: /<302PATH_ON_TARGET> Location: /<302PATH_ON_TARGET> <---------! < Content-Length: 0 Content-Length: 0 < Content-Type: text/plain Content-Type: text/plain < * Connection #0 to host left intact * Issue another request to this URL: '/<302PATH_ON_TARGET>' * About to connect() to BADHOST port 443 (#1) [..SSL handshake..] GET /<302PATH_ON_TARGET> HTTP/1.1 Host: BADHOST [..] HTTP/1.1 404 Not Found HTTP/1.1 404 Not Found < Server: nginx Server: nginx < Date: Mon, 03 Feb 2014 15:00:05 GMT Date: Mon, 03 Feb 2014 15:00:05 GMT < Content-Type: text/html Content-Type: text/html < Content-Length: 162 Content-Length: 162 < Connection: keep-alive Connection: keep-alive ---snap The <302PATH_ON_TARGET> is in this example an URL for retrying form-based authentication, so that issue has a quite dramatic security impact if the server doesn't throw e.g. a 400 but takes user input (here: host header) and redirects thereto. Needless to ask: It's certainly mod_nss. mod_ssl (same machine, rest of configuration not touched) doesn't show this. Cheers, Dirk From dirk at owasp.org Fri Feb 21 11:37:50 2014 From: dirk at owasp.org (Dirk Wetter) Date: Fri, 21 Feb 2014 12:37:50 +0100 Subject: [Mod_nss-list] mod_nss and faked header = unvalidated redirect? In-Reply-To: <52F3B12B.5020909@owasp.org> References: <52F3B12B.5020909@owasp.org> Message-ID: <53073A8E.8050109@owasp.org> Hi there, Am 02/06/2014 04:58 PM, schrieb Dirk Wetter: > > Hi, > > one to two questions. > > Are there any known bugs or config variables which prevent this from > happening and is that reproducible? > > > ----snip > curl -v -L -i -k -X 'GET' -H 'Host: ' > > [..SSL handshake..] > > GET / HTTP/1.1 >> Accept: */* >> [..rest of header omitted ..] >> Host: BADHOST <---------! > > > * upload completely sent off: 48out of 48 bytes > < HTTP/1.1 302 Moved Temporarily > HTTP/1.1 302 Moved Temporarily > < Date: Mon, 03 Feb 2014 15:00:04 GMT > Date: Mon, 03 Feb 2014 15:00:04 GMT > < Server: Apache > Server: Apache > < Location: /<302PATH_ON_TARGET> > Location: /<302PATH_ON_TARGET> <---------! > < Content-Length: 0 > Content-Length: 0 > < Content-Type: text/plain > Content-Type: text/plain > > < > * Connection #0 to host left intact > * Issue another request to this URL: '/<302PATH_ON_TARGET>' > * About to connect() to BADHOST port 443 (#1) > [..SSL handshake..] > GET /<302PATH_ON_TARGET> HTTP/1.1 > Host: BADHOST > [..] > > > HTTP/1.1 404 Not Found > HTTP/1.1 404 Not Found > < Server: nginx > Server: nginx > < Date: Mon, 03 Feb 2014 15:00:05 GMT > Date: Mon, 03 Feb 2014 15:00:05 GMT > < Content-Type: text/html > Content-Type: text/html > < Content-Length: 162 > Content-Length: 162 > < Connection: keep-alive > Connection: keep-alive > > ---snap > > The <302PATH_ON_TARGET> is in this example an URL for retrying form-based authentication, > so that issue has a quite dramatic security impact if the server doesn't throw e.g. a > 400 but takes user input (here: host header) and redirects thereto. > > Needless to ask: It's certainly mod_nss. mod_ssl (same machine, rest of configuration > not touched) doesn't show this. I hope there's something going on behind the scenes, as my posting is > 2 weeks ago. Please let me know if this is the wrong list or further input/explanation is needed -- IMHO this bug (if reproducible) should be labeled at least as medium if not high risk. Cheers, Dirk From rcritten at redhat.com Fri Feb 21 15:56:57 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Feb 2014 10:56:57 -0500 Subject: [Mod_nss-list] mod_nss and faked header = unvalidated redirect? In-Reply-To: <53073A8E.8050109@owasp.org> References: <52F3B12B.5020909@owasp.org> <53073A8E.8050109@owasp.org> Message-ID: <53077749.1060601@redhat.com> Dirk Wetter wrote: > Hi there, > > > Am 02/06/2014 04:58 PM, schrieb Dirk Wetter: >> >> Hi, >> >> one to two questions. >> >> Are there any known bugs or config variables which prevent this from >> happening and is that reproducible? >> >> >> ----snip >> curl -v -L -i -k -X 'GET' -H 'Host: ' >> >> [..SSL handshake..] >> >> GET / HTTP/1.1 >>> Accept: */* >>> [..rest of header omitted ..] >>> Host: BADHOST <---------! >> >> >> * upload completely sent off: 48out of 48 bytes >> < HTTP/1.1 302 Moved Temporarily >> HTTP/1.1 302 Moved Temporarily >> < Date: Mon, 03 Feb 2014 15:00:04 GMT >> Date: Mon, 03 Feb 2014 15:00:04 GMT >> < Server: Apache >> Server: Apache >> < Location: /<302PATH_ON_TARGET> >> Location: /<302PATH_ON_TARGET> <---------! >> < Content-Length: 0 >> Content-Length: 0 >> < Content-Type: text/plain >> Content-Type: text/plain >> >> < >> * Connection #0 to host left intact >> * Issue another request to this URL: '/<302PATH_ON_TARGET>' >> * About to connect() to BADHOST port 443 (#1) >> [..SSL handshake..] >> GET /<302PATH_ON_TARGET> HTTP/1.1 >> Host: BADHOST >> [..] >> >> >> HTTP/1.1 404 Not Found >> HTTP/1.1 404 Not Found >> < Server: nginx >> Server: nginx >> < Date: Mon, 03 Feb 2014 15:00:05 GMT >> Date: Mon, 03 Feb 2014 15:00:05 GMT >> < Content-Type: text/html >> Content-Type: text/html >> < Content-Length: 162 >> Content-Length: 162 >> < Connection: keep-alive >> Connection: keep-alive >> >> ---snap >> >> The <302PATH_ON_TARGET> is in this example an URL for retrying form-based authentication, >> so that issue has a quite dramatic security impact if the server doesn't throw e.g. a >> 400 but takes user input (here: host header) and redirects thereto. >> >> Needless to ask: It's certainly mod_nss. mod_ssl (same machine, rest of configuration >> not touched) doesn't show this. > > > I hope there's something going on behind the scenes, as my > posting is > 2 weeks ago. > > Please let me know if this is the wrong list or further input/explanation is needed -- > IMHO this bug (if reproducible) should be labeled at least as medium if not high risk. I can reproduce this but I see the same behavior with both mod_nss and mod_ssl. What version of Apache, mod_ssl and mod_nss are you using, and what distro? I'm seeing the same 301 for both mod_ssl and mod_nss in Fedora 20. What I did was create /var/www/html/foo and added a short index.html there. Then I fetch https://`hostname`/foo and for both I get a 301 with a Location to the "bad" host. rob From dirk at owasp.org Sat Feb 22 10:45:04 2014 From: dirk at owasp.org (Dirk Wetter) Date: Sat, 22 Feb 2014 11:45:04 +0100 Subject: [Mod_nss-list] mod_nss and faked header = unvalidated redirect? In-Reply-To: <53077749.1060601@redhat.com> References: <52F3B12B.5020909@owasp.org> <53073A8E.8050109@owasp.org> <53077749.1060601@redhat.com> Message-ID: <53087FB0.9070702@owasp.org> Hi Rob, Am 02/21/2014 04:56 PM, schrieb Rob Crittenden: > Dirk Wetter wrote: >> Hi there, >> >> >> Am 02/06/2014 04:58 PM, schrieb Dirk Wetter: >>> >>> Hi, >>> >>> one to two questions. >>> >>> Are there any known bugs or config variables which prevent this from >>> happening and is that reproducible? >>> >>> >>> ----snip >>> curl -v -L -i -k -X 'GET' -H 'Host: ' >>> >>> [..SSL handshake..] >>> >>> GET / HTTP/1.1 >>>> Accept: */* >>>> [..rest of header omitted ..] >>>> Host: BADHOST <---------! >>> >>> >>> * upload completely sent off: 48out of 48 bytes >>> < HTTP/1.1 302 Moved Temporarily >>> HTTP/1.1 302 Moved Temporarily >>> < Date: Mon, 03 Feb 2014 15:00:04 GMT >>> Date: Mon, 03 Feb 2014 15:00:04 GMT >>> < Server: Apache >>> Server: Apache >>> < Location: /<302PATH_ON_TARGET> >>> Location: /<302PATH_ON_TARGET> <---------! >>> < Content-Length: 0 >>> Content-Length: 0 >>> < Content-Type: text/plain >>> Content-Type: text/plain >>> >>> < >>> * Connection #0 to host left intact >>> * Issue another request to this URL: '/<302PATH_ON_TARGET>' >>> * About to connect() to BADHOST port 443 (#1) >>> [..SSL handshake..] >>> GET /<302PATH_ON_TARGET> HTTP/1.1 >>> Host: BADHOST >>> [..] >>> >>> >>> HTTP/1.1 404 Not Found >>> HTTP/1.1 404 Not Found >>> < Server: nginx >>> Server: nginx >>> < Date: Mon, 03 Feb 2014 15:00:05 GMT >>> Date: Mon, 03 Feb 2014 15:00:05 GMT >>> < Content-Type: text/html >>> Content-Type: text/html >>> < Content-Length: 162 >>> Content-Length: 162 >>> < Connection: keep-alive >>> Connection: keep-alive >>> >>> ---snap >>> >>> The <302PATH_ON_TARGET> is in this example an URL for retrying form-based authentication, >>> so that issue has a quite dramatic security impact if the server doesn't throw e.g. a >>> 400 but takes user input (here: host header) and redirects thereto. >>> >>> Needless to ask: It's certainly mod_nss. mod_ssl (same machine, rest of configuration >>> not touched) doesn't show this. >> >> I hope there's something going on behind the scenes, as my >> posting is > 2 weeks ago. >> >> Please let me know if this is the wrong list or further input/explanation is needed -- >> IMHO this bug (if reproducible) should be labeled at least as medium if not high risk. > > I can reproduce this but I see the same behavior with both mod_nss and mod_ssl. What version of Apache, mod_ssl and mod_nss are you using, and what distro? Distribution is SLES 11 SP3. As with RHEL you can't trust the version numbers, as some features are backported. Literally it's Apache 2.2.12, OpenSSL 0.9.8j. > I'm seeing the same 301 for both mod_ssl and mod_nss in Fedora 20. > > What I did was create /var/www/html/foo and added a short index.html there. > > Then I fetch https://`hostname`/foo and for both I get a 301 with a Location to the "bad" host. Two remarks: For both that seems a bit hard to believe to me. That would mean that FC 20 general would have this problem. Or do I overlook s.th.? Secondly: it's a 302 in my case. The result is in fact the same, however I wonder where this subtle difference comes from. Cheers, Dirk From rcritten at redhat.com Mon Feb 24 16:36:50 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Feb 2014 11:36:50 -0500 Subject: [Mod_nss-list] mod_nss and faked header = unvalidated redirect? In-Reply-To: <53087FB0.9070702@owasp.org> References: <52F3B12B.5020909@owasp.org> <53073A8E.8050109@owasp.org> <53077749.1060601@redhat.com> <53087FB0.9070702@owasp.org> Message-ID: <530B7522.7030903@redhat.com> Dirk Wetter wrote: > Hi Rob, > > Am 02/21/2014 04:56 PM, schrieb Rob Crittenden: >> Dirk Wetter wrote: >>> Hi there, >>> >>> >>> Am 02/06/2014 04:58 PM, schrieb Dirk Wetter: >>>> >>>> Hi, >>>> >>>> one to two questions. >>>> >>>> Are there any known bugs or config variables which prevent this from >>>> happening and is that reproducible? >>>> >>>> >>>> ----snip >>>> curl -v -L -i -k -X 'GET' -H 'Host: ' >>>> >>>> [..SSL handshake..] >>>> >>>> GET / HTTP/1.1 >>>>> Accept: */* >>>>> [..rest of header omitted ..] >>>>> Host: BADHOST <---------! >>>> >>>> >>>> * upload completely sent off: 48out of 48 bytes >>>> < HTTP/1.1 302 Moved Temporarily >>>> HTTP/1.1 302 Moved Temporarily >>>> < Date: Mon, 03 Feb 2014 15:00:04 GMT >>>> Date: Mon, 03 Feb 2014 15:00:04 GMT >>>> < Server: Apache >>>> Server: Apache >>>> < Location: /<302PATH_ON_TARGET> >>>> Location: /<302PATH_ON_TARGET> <---------! >>>> < Content-Length: 0 >>>> Content-Length: 0 >>>> < Content-Type: text/plain >>>> Content-Type: text/plain >>>> >>>> < >>>> * Connection #0 to host left intact >>>> * Issue another request to this URL: '/<302PATH_ON_TARGET>' >>>> * About to connect() to BADHOST port 443 (#1) >>>> [..SSL handshake..] >>>> GET /<302PATH_ON_TARGET> HTTP/1.1 >>>> Host: BADHOST >>>> [..] >>>> >>>> >>>> HTTP/1.1 404 Not Found >>>> HTTP/1.1 404 Not Found >>>> < Server: nginx >>>> Server: nginx >>>> < Date: Mon, 03 Feb 2014 15:00:05 GMT >>>> Date: Mon, 03 Feb 2014 15:00:05 GMT >>>> < Content-Type: text/html >>>> Content-Type: text/html >>>> < Content-Length: 162 >>>> Content-Length: 162 >>>> < Connection: keep-alive >>>> Connection: keep-alive >>>> >>>> ---snap >>>> >>>> The <302PATH_ON_TARGET> is in this example an URL for retrying form-based authentication, >>>> so that issue has a quite dramatic security impact if the server doesn't throw e.g. a >>>> 400 but takes user input (here: host header) and redirects thereto. >>>> >>>> Needless to ask: It's certainly mod_nss. mod_ssl (same machine, rest of configuration >>>> not touched) doesn't show this. >>> >>> I hope there's something going on behind the scenes, as my >>> posting is > 2 weeks ago. >>> >>> Please let me know if this is the wrong list or further input/explanation is needed -- >>> IMHO this bug (if reproducible) should be labeled at least as medium if not high risk. >> >> I can reproduce this but I see the same behavior with both mod_nss and mod_ssl. What version of Apache, mod_ssl and mod_nss are you using, and what distro? > > Distribution is SLES 11 SP3. As with RHEL you can't trust the version numbers, > as some features are backported. Literally it's Apache 2.2.12, OpenSSL 0.9.8j. > >> I'm seeing the same 301 for both mod_ssl and mod_nss in Fedora 20. >> >> What I did was create /var/www/html/foo and added a short index.html there. >> >> Then I fetch https://`hostname`/foo and for both I get a 301 with a Location to the "bad" host. > > Two remarks: For both that seems a bit hard to believe to me. > That would mean that FC 20 general would have this problem. Or do I overlook > s.th.? > > Secondly: it's a 302 in my case. The result is in fact the same, however I wonder > where this subtle difference comes from. It may be something with the configurations which is why I outlined how I reproduced it. I also tried in RHEL 6.5 which uses a base of httpd 2.2.15 (+74 patches, but nothing related to 301/302) and I see the same thing there as well. I get the same 301 for both mod_ssl and mod_nss, but my steps were the same as well. rob