Custom Query (2292 matches)
Results (1 - 3 of 2292)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#1 | fixed | Incorrect parsing of IPv6 literal in Host header | ||
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:
results in a value of only '[::' in $host (excluding my quotes). However, the following request:
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.:
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:
Consider the following configuration, which may be used to proxy traffic to an upstream server that serves multiple, name-based virtual hosts:
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.
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:
The resulting log entry is ambiguous, and may confused parsers:
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 | ||
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 | ||
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 |