0x50sec.org » nginx http://www.0x50sec.org Focus on web security! Fri, 13 Jan 2012 09:23:52 +0000 en hourly 1 http://wordpress.org/?v=3.1 Possible Arbitrary Code Execution with Null Bytes, PHP, and Old Versions of nginx http://www.0x50sec.org/possible-arbitrary-code-execution-with-null-bytes-php-and-old-versions-of-nginx/ http://www.0x50sec.org/possible-arbitrary-code-execution-with-null-bytes-php-and-old-versions-of-nginx/#comments Thu, 25 Aug 2011 13:27:09 +0000 admin http://www.0x50sec.org/?p=1160 from：https://nealpoole.com/blog/2011/07/possible-arbitrary-code-execution-with-null-bytes-php-and-old-versions-of-nginx/

After publishing my previous blog post on PHP, nginx configuration, and potential arbitrary code execution, I came across a separate null-byte injection vulnerability in older versions of nginx (0.5.*, 0.6.*, 0.7 <= 0.7.65, 0.8 <= 0.8.37). By taking advantage of this vulnerability, an attacker can cause a server that uses PHP-FastCGI to execute any publicly accessible file on the server as PHP.

In vulnerable versions of nginx, null bytes are allowed in URIs by default (their presence is indicated via a variable named zero_in_uri defined in ngx_http_request.h). Individual modules have the ability to opt-out of handling URIs with null bytes. However, not all of them do; in particular, the FastCGI module does not.

The attack itself is simple: a malicious user who makes a request to http://example.com/file.ext%00.php causes file.ext to be parsed as PHP. If an attacker can control the contents of a file served up by nginx (ie: using an avatar upload form) the result is arbitrary code execution. This vulnerability can not be mitigated by nginx configuration settings like try_files or PHP configuration settings like cgi.fix_pathinfo: the only defense is to upgrade to a newer version of nginx or to explicitly block potentially malicious requests to directories containing user-controlled content.

1
2
3
4
5
6
# This location block will prevent an attacker from exploiting
# this vulnerability using files in the 'uploads' or 'other_uploads' directory
location ~ ^/(uploads|other_uploads)/.*.php$
{
deny all;
}

Although the affected versions of nginx are relatively old (0.7.66 was released June 7th, 2010, 0.8.38 was released May 24th 2010), no mention of the change appears in the release notes. As a result, administrators may be running vulnerable servers without realizing their risk. I discovered a couple places where vulnerable packages were being distributed:

  1. Ubuntu Lucid Lynx (Ubuntu’s current LTS offering) and Hardy Heron (via both the hardy and hardy-backports repositories) provided vulnerable versions of nginx via apt-get. The lucid and hardy packages have been updated: hardy-backports is awaiting approval. [1] [2]
  2. Fedora provides a vulnerable version in its EPEL-4 repository. At this time, an updated package has not been released.

I sent several emails to igor@sysoev.ru regarding the vulnerability. I sent the first on June 24th and I sent followups on July 4th, July 20th, and August 2nd. I received the following reply to my August 2nd email:

Thank you for report.

I do not consider this as nginx security issue since every application
should validate its input data, so nginx passed the data to application.
Also this is PHP installation issue where scripts and user uploaded
data are not separated. This issue was discussed several times on mailing
list.

At some point I’ve decided that zero byte in URI should not appear
in any encoding, operating system, etc., and just makes more problems
than helps. So I have remove zero byte test.

For anyone who’s curious, the changes can be found at r3528 from svn://svn.nginx.org. At that time, it appears trunk corresponded to nginx 0.8: r3599 merged r3528 into the nginx 0.7 branch. The corresponding commit message is “remove r->zero_in_uri.” I’ve reproduced the output of svn diff below:

Index: src/http/ngx_http_request.h
===================================================================
--- src/http/ngx_http_request.h (revision 3527)
+++ src/http/ngx_http_request.h (revision 3528)
@@ -56,7 +56,7 @@
#define NGX_HTTP_PARSE_INVALID_HEADER 13
-#define NGX_HTTP_ZERO_IN_URI 1
+/* unused 1 */
#define NGX_HTTP_SUBREQUEST_IN_MEMORY 2
#define NGX_HTTP_SUBREQUEST_WAITED 4
#define NGX_HTTP_LOG_UNSAFE 8
@@ -435,9 +435,6 @@
/* URI with "+" */
unsigned plus_in_uri:1;
- /* URI with "\0" or "%00" */
- unsigned zero_in_uri:1;
-
unsigned invalid_header:1;
unsigned valid_location:1;
Index: src/http/ngx_http_core_module.c
===================================================================
--- src/http/ngx_http_core_module.c (revision 3527)
+++ src/http/ngx_http_core_module.c (revision 3528)
@@ -1341,7 +1341,7 @@
/* no content handler was found */
- if (r->uri.data[r->uri.len - 1] == '/' && !r->zero_in_uri) {
+ if (r->uri.data[r->uri.len - 1] == '/') {
if (ngx_http_map_uri_to_path(r, &path, &root, 0) != NULL) {
ngx_log_error(NGX_LOG_ERR, r->connection->log, 0,
@@ -2104,7 +2104,6 @@
ngx_log_debug2(NGX_LOG_DEBUG_HTTP, c->log, 0,
"http subrequest \"%V?%V\"", uri, &sr->args);
- sr->zero_in_uri = (flags & NGX_HTTP_ZERO_IN_URI) != 0;
sr->subrequest_in_memory = (flags & NGX_HTTP_SUBREQUEST_IN_MEMORY) != 0;
sr->waited = (flags & NGX_HTTP_SUBREQUEST_WAITED) != 0;
Index: src/http/ngx_http_special_response.c
===================================================================
--- src/http/ngx_http_special_response.c (revision 3527)
+++ src/http/ngx_http_special_response.c (revision 3528)
@@ -517,8 +517,6 @@
r->err_status = overwrite;
- r->zero_in_uri = 0;
-
if (ngx_http_complex_value(r, &err_page->value, &uri) != NGX_OK) {
return NGX_ERROR;
}
Index: src/http/ngx_http_upstream.c
===================================================================
--- src/http/ngx_http_upstream.c (revision 3527)
+++ src/http/ngx_http_upstream.c (revision 3528)
@@ -1815,10 +1815,6 @@
return NGX_DONE;
}
- if (flags & NGX_HTTP_ZERO_IN_URI) {
- r->zero_in_uri = 1;
- }
-
if (r->method != NGX_HTTP_HEAD) {
r->method = NGX_HTTP_GET;
}
Index: src/http/ngx_http_parse.c
===================================================================
--- src/http/ngx_http_parse.c (revision 3527)
+++ src/http/ngx_http_parse.c (revision 3528)
@@ -438,8 +438,7 @@
r->plus_in_uri = 1;
break;
case '\0':
- r->zero_in_uri = 1;
- break;
+ return NGX_HTTP_PARSE_INVALID_REQUEST;
default:
state = sw_check_uri;
break;
@@ -496,8 +495,7 @@
r->plus_in_uri = 1;
break;
case '\0':
- r->zero_in_uri = 1;
- break;
+ return NGX_HTTP_PARSE_INVALID_REQUEST;
}
break;
@@ -526,8 +524,7 @@
r->complex_uri = 1;
break;
case '\0':
- r->zero_in_uri = 1;
- break;
+ return NGX_HTTP_PARSE_INVALID_REQUEST;
}
break;
@@ -1202,7 +1199,7 @@
ch = *p++;
} else if (ch == '\0') {
- r->zero_in_uri = 1;
+ return NGX_HTTP_PARSE_INVALID_REQUEST;
}
state = quoted_state;
@@ -1304,8 +1301,7 @@
}
if (ch == '\0') {
- *flags |= NGX_HTTP_ZERO_IN_URI;
- continue;
+ goto unsafe;
}
if (ngx_path_separator(ch) && len > 2) {
@@ -1449,34 +1445,19 @@
void
ngx_http_split_args(ngx_http_request_t *r, ngx_str_t *uri, ngx_str_t *args)
{
- u_char ch, *p, *last;
+ u_char *p, *last;
- p = uri->data;
+ last = uri->data + uri->len;
- last = p + uri->len;
+ p = ngx_strlchr(uri->data, last, '?');
- args->len = 0;
+ if (p) {
+ uri->len = p - uri->data;
+ p++;
+ args->len = last - p;
+ args->data = p;
- while (p < last) {
-
- ch = *p++;
-
- if (ch == '?') {
- args->len = last - p;
- args->data = p;
-
- uri->len = p - 1 - uri->data;
-
- if (ngx_strlchr(p, last, '\0') != NULL) {
- r->zero_in_uri = 1;
- }
-
- return;
- }
-
- if (ch == '\0') {
- r->zero_in_uri = 1;
- continue;
- }
+ } else {
+ args->len = 0;
}
}
Index: src/http/modules/ngx_http_gzip_static_module.c
===================================================================
--- src/http/modules/ngx_http_gzip_static_module.c (revision 3527)
+++ src/http/modules/ngx_http_gzip_static_module.c (revision 3528)
@@ -89,10 +89,6 @@
return NGX_DECLINED;
}
- if (r->zero_in_uri) {
- return NGX_DECLINED;
- }
-
gzcf = ngx_http_get_module_loc_conf(r, ngx_http_gzip_static_module);
if (!gzcf->enable) {
Index: src/http/modules/ngx_http_index_module.c
===================================================================
--- src/http/modules/ngx_http_index_module.c (revision 3527)
+++ src/http/modules/ngx_http_index_module.c (revision 3528)
@@ -116,10 +116,6 @@
return NGX_DECLINED;
}
- if (r->zero_in_uri) {
- return NGX_DECLINED;
- }
-
ilcf = ngx_http_get_module_loc_conf(r, ngx_http_index_module);
clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);
Index: src/http/modules/ngx_http_random_index_module.c
===================================================================
--- src/http/modules/ngx_http_random_index_module.c (revision 3527)
+++ src/http/modules/ngx_http_random_index_module.c (revision 3528)
@@ -86,10 +86,6 @@
return NGX_DECLINED;
}
- if (r->zero_in_uri) {
- return NGX_DECLINED;
- }
-
if (!(r->method & (NGX_HTTP_GET|NGX_HTTP_HEAD|NGX_HTTP_POST))) {
return NGX_DECLINED;
}
Index: src/http/modules/ngx_http_dav_module.c
===================================================================
--- src/http/modules/ngx_http_dav_module.c (revision 3527)
+++ src/http/modules/ngx_http_dav_module.c (revision 3528)
@@ -146,10 +146,6 @@
ngx_int_t rc;
ngx_http_dav_loc_conf_t *dlcf;
- if (r->zero_in_uri) {
- return NGX_DECLINED;
- }
-
dlcf = ngx_http_get_module_loc_conf(r, ngx_http_dav_module);
if (!(r->method & dlcf->methods)) {
Index: src/http/modules/ngx_http_flv_module.c
===================================================================
--- src/http/modules/ngx_http_flv_module.c (revision 3527)
+++ src/http/modules/ngx_http_flv_module.c (revision 3528)
@@ -80,10 +80,6 @@
return NGX_DECLINED;
}
- if (r->zero_in_uri) {
- return NGX_DECLINED;
- }
-
rc = ngx_http_discard_request_body(r);
if (rc != NGX_OK) {
Index: src/http/modules/ngx_http_static_module.c
===================================================================
--- src/http/modules/ngx_http_static_module.c (revision 3527)
+++ src/http/modules/ngx_http_static_module.c (revision 3528)
@@ -66,10 +66,6 @@
return NGX_DECLINED;
}
- if (r->zero_in_uri) {
- return NGX_DECLINED;
- }
-
log = r->connection->log;
/*
Index: src/http/modules/ngx_http_autoindex_module.c
===================================================================
--- src/http/modules/ngx_http_autoindex_module.c (revision 3527)
+++ src/http/modules/ngx_http_autoindex_module.c (revision 3528)
@@ -160,10 +160,6 @@
return NGX_DECLINED;
}
- if (r->zero_in_uri) {
- return NGX_DECLINED;
- }
-
if (!(r->method & (NGX_HTTP_GET|NGX_HTTP_HEAD))) {
return NGX_DECLINED;
}
Index: src/http/modules/perl/ngx_http_perl_module.c
===================================================================
--- src/http/modules/perl/ngx_http_perl_module.c (revision 3527)
+++ src/http/modules/perl/ngx_http_perl_module.c (revision 3528)
@@ -168,10 +168,6 @@
static ngx_int_t
ngx_http_perl_handler(ngx_http_request_t *r)
{
- if (r->zero_in_uri) {
- return NGX_HTTP_NOT_FOUND;
- }
-
r->main->count++;
ngx_http_perl_handle_request(r);
]]> http://www.0x50sec.org/possible-arbitrary-code-execution-with-null-bytes-php-and-old-versions-of-nginx/feed/ 0 nginx文件类型错误解析漏洞 http://www.0x50sec.org/nginx%e6%96%87%e4%bb%b6%e7%b1%bb%e5%9e%8b%e9%94%99%e8%af%af%e8%a7%a3%e6%9e%90%e6%bc%8f%e6%b4%9e/ http://www.0x50sec.org/nginx%e6%96%87%e4%bb%b6%e7%b1%bb%e5%9e%8b%e9%94%99%e8%af%af%e8%a7%a3%e6%9e%90%e6%bc%8f%e6%b4%9e/#comments Mon, 24 May 2010 03:46:59 +0000 admin http://www.0x50sec.org/?p=901 nginx文件类型错误解析漏洞
来源:80sec.com
原文链接:http://www.80sec.com/nginx-securit.html

漏洞介绍：nginx是一款高性能的web服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好的支持PHP的运行。80sec发现其中存在一个较为严重的安全问题，默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持php的nginx服务器。

漏洞分析：nginx默认以cgi的方式支持php的运行，譬如在配置文件当中可以以

location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}

的方式支持对php的解析，location对请求进行选择的时候会使用URI环境变量进行选择，其中传递到后端Fastcgi的关键变量 SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定，而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的，这里就是产生问题的点。而为了较好的支持PATH_INFO的提取，在PHP 的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。
那么假设存在一个http://www.80sec.com/80sec.jpg，我们以如下的方式去访问

http://www.80sec.com/80sec.jpg/80sec.php

将会得到一个URI

/80sec.jpg/80sec.php

经过location指令，该请求将会交给后端的fastcgi处理，nginx为其设置环境变量SCRIPT_FILENAME，内容为

/scripts/80sec.jpg/80sec.php

而在其他的webserver如lighttpd当中，我们发现其中的SCRIPT_FILENAME被正确的设置为

/scripts/80sec.jpg

所以不存在此问题。
后端的fastcgi在接受到该选项时，会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理，一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用，所以该选项一般配置开启。Php通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为

/scripts/80sec.jpg和80sec.php

最后，以/scripts/80sec.jpg作为此次请求需要执行的脚本，攻击者就可以实现让nginx以php来解析任何类型的文件了。

POC： 访问一个nginx来支持php的站点，在一个任何资源的文件如robots.txt后面加上/80sec.php，这个时候你可以看到如下的区别：

访问http://www.80sec.com/robots.txt

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:05:30 GMT
Content-Type: text/plain
Content-Length: 18
Last-Modified: Thu, 20 May 2010 06:26:34 GMT
Connection: keep-alive
Keep-Alive: timeout=20
Accept-Ranges: bytes

访问访问http://www.80sec.com/robots.txt/80sec.php

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:06:49 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.6

其中的Content-Type的变化说明了后端负责解析的变化，该站点就可能存在漏洞。

漏洞厂商：http://www.nginx.org

解决方案：

我们已经尝试联系官方，但是此前你可以通过以下的方式来减少损失

关闭cgi.fix_pathinfo为0

或者

if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}

PS: 鸣谢laruence大牛在分析过程中给的帮助

]]> http://www.0x50sec.org/nginx%e6%96%87%e4%bb%b6%e7%b1%bb%e5%9e%8b%e9%94%99%e8%af%af%e8%a7%a3%e6%9e%90%e6%bc%8f%e6%b4%9e/feed/ 0