Custom Query (2292 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1 - 3 of 2292)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#1 fixed Incorrect parsing of IPv6 literal in Host header somebody id.seznam.cz/f49759d8b4c466810d3beaae455df049
Description

Hello,

this is a bug-repost from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607418 which also includes a patch.

I've noticed that nginx incorrectly parses IPv6 addresses from the HTTP requests Host header into its '$host' configuration variable. An HTTP request (via IPv4 or IPv5) in the following form:

GET / HTTP/1.0 Host: [::1]

results in a value of only '[::' in $host (excluding my quotes).

However, the following request:

GET / HTTP/1.0 Host: [::1]:80

results in the correct value of '[::1]' in $host.

For 'longer' IPv6 addresses the result is that a full two octets can be missing from the $host variable, e.g.:

GET / HTTP/1.0 Host: [fdf2:9468:665c:eaf6:2af6:c9ca:f24e:ae62]

results in only '[fdf2:9468:665c:eaf6:2af6:c9ca:f24e:' in $host.

After some experimentation it seems that the last colon and all characters following it are omitted. This may be the way the 'port' portion is normally stripped from IPv4 literal addresses.

This leads to a number of potential issues:

  1. Proxying

Consider the following configuration, which may be used to proxy traffic to an upstream server that serves multiple, name-based virtual hosts:

location / {

proxy_pass http://localhost:8000; proxy_set_header Host $host;

}

Due to the incorrect parsing of the Host header in the request, a malformed Host header is sent in the HTTP request to the upstream server, resulting in '400 Bad Request' from Apache at least.

If a website had an nginx reverse proxy server configured in this way, a visitor to http://[fc00::1]/ would likely receive this error.

  1. Logs

Consider the following log format which is the same as the default format, but prepended with '$host '. This may be used in virtual hosting environments or by awstats to distinguish traffic for different customers or websites:

log_format vhost '$host $remote_addr - $remote_user [$time_local] '

'"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"';

access_log /var/log/nginx/localhost.access.log vhost;

The resulting log entry is ambiguous, and may confused parsers:

[: ::1 - - [18/Dec/2010:06:29:42 +0000] "GET / HTTP/1.0" 404 169 "-" "-"

  1. Rewrites, access control, other uses of the $host variable

Obviously, any configuration that matches on the contents of the $host variable can fail to work as expected due to this bug.

The value of $host may sometimes be used as a 'key' for caching (such as the documented example for proxy_cache_key). In this case, it is possible that two different sites (eg. on [fc00::1234] and [fc00::5678]) could be given the same key due to the incorrect parsing. In the most extreme case this may cause one website's content to appear on the other (if the upstream server and path part of the URI were the same).

As well as fixing the parsing of the IPv6 literal address, I suggest nginx also sanitises it (e.g. removing unnecessary zeroes), otherwise a malicious user could try to influence the behaviour of proxy_cache by visiting [fc00::1], [fc00::01], [fc00::000:1], etc.

The bug is present in all the current nginx "stable" versions as well as in the latest 1.1.0 development unstable.

#2 fixed HttpRealIpModule only seems to work with one trusted proxy, you can't build a list of trusted proxies as only the first one will work Ruslan Ermilov cwjam.com
Description

HttpRealIpModule only seems to work with the first trusted proxy set via set_real_ip_from. Any additional trusted proxies are ignored which contradicts the example at http://wiki.nginx.org/HttpRealIpModule

Example 1: If you only supply one trusted proxy everything works as expected.

set_real_ip_from proxy_1_IP; real_ip_header X-Forwarded-For;

X-Forwarded-For: client1, proxy_1_IP $remote_addr = client1 (which is expected)

Example 2: However if you provide a list of trusted proxies, only the first one is applied.

set_real_ip_from proxy_1_IP; set_real_ip_from proxy_2_IP; real_ip_header X-Forwarded-For;

X-Forwarded-For: client1, proxy_2_IP, proxy_1_IP $remote_addr = proxy_2_IP (which is unexpected)

It looks like I'm not the only person to encounter this issue: http://forum.nginx.org/read.php?2,154968,154996

The poster of that thread has supplied a patch (which I have not tested) http://treehou.se/~omar/nginx-0.8.53-xff.patch

Thanks, Ciaran

#3 fixed POSIX Semaphores can be used at Solaris somebody dsdiv.moikrug.ru
Description

Here is Nginx 1.0.5 patch:

--- auto/unix.orig      Fri Aug  5 18:17:24 2011
+++ auto/unix   Fri Aug  5 18:19:38 2011
@@ -620,6 +620,19 @@
 fi


+if [ $ngx_found = no ]; then
+
+    # Solaris has POSIX semaphores in librt
+    ngx_feature="POSIX semaphores in librt"
+    ngx_feature_libs=-lrt
+    . auto/feature
+
+    if [ $ngx_found = yes ]; then
+        CORE_LIBS="$CORE_LIBS -lrt"
+    fi
+fi
+
+
 ngx_feature="struct msghdr.msg_control"
 ngx_feature_name="NGX_HAVE_MSGHDR_MSG_CONTROL"
 ngx_feature_run=no
1 2 3 4 5 6 7 8 9 10 11
Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.