RE: Question on ap_method_* functions
-Original Message-
From: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
Sent: Montag, 14. Juli 2014 22:55
To: dev@httpd.apache.org
Subject: Question on ap_method_* functions
Hi,
I was about to submit a patch in order to remove the 'register' keyword
in a variable declaration in 'modules/http/http_protocol.c'.
See 'ap_method_list_remove()'
I also wanted to simplify code in the surrounding ap_method_* functions.
However, I think that:
- in 'ap_method_list_add()',
l-method_mask |= (AP_METHOD_BIT methnum);
should be in the
if (methnum != M_INVALID) { ... }
block
- in 'ap_method_list_remove()',
l-method_mask |= ~(AP_METHOD_BIT methnum);
Doesn't this need to be
l-method_mask = ~(AP_METHOD_BIT methnum);
in order to remove it? Otherwise I set all methods but methnum.
should be in the
if (methnum != M_INVALID) { ... }
block
Do you agree ?
Yes.
Regards
Rüdiger
Re: FYI: Looking for a release of 2.4.x soonish
I will be tagging and rolling today, right around noon eastern.
Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
On Tue, Jul 15, 2014 at 12:27:00PM -, jor...@apache.org wrote: Author: jorton Date: Tue Jul 15 12:27:00 2014 New Revision: 1610674 URL: http://svn.apache.org/r1610674 Log: SECURITY (CVE-2014-0117): Fix a crash in mod_proxy. In a reverse proxy configuration, a remote attacker could send a carefully crafted request which could crash a server process, resulting in denial of service. Backporting this to 2.4.x is non-trivial since trunk has diverged from 2.4.x via at least this change to how r-headers_in is handled: http://svn.apache.org/viewvc?view=revisionrevision=1588527 I am not sure how/whether that impacts the backport. We have a simpler version of the crasher fix which doesn't add strict interpretation of the Connection header - I am going to propose that for 2.4.x. If somebody wants to propose a backport of r1610674 for 2.4.x please jump to it ASAP! Regards, Joe
Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
On Tue, Jul 15, 2014 at 2:38 PM, Joe Orton jor...@redhat.com wrote:
If somebody wants to propose a backport of r1610674 for 2.4.x
please jump to it ASAP!
Attached is a 2.4.x version of r1610674 that should work.
r1588527 copies headers_in sooner in the function but
ap_proxy_clear_connection() can still be called on the copy.
Regards,
Yann.
Property changes on: .
___
Modified: svn:mergeinfo
Merged /httpd/httpd/trunk:r1610674
Index: server/util.c
===
--- server/util.c (revision 1610675)
+++ server/util.c (working copy)
@@ -1451,6 +1451,95 @@ AP_DECLARE(int) ap_find_etag_weak(apr_pool_t *p, c
return find_list_item(p, line, tok, AP_ETAG_WEAK);
}
+/* Grab a list of tokens of the format 1#token (from RFC7230) */
+AP_DECLARE(const char *) ap_parse_token_list_strict(apr_pool_t *p,
+const char *str_in,
+apr_array_header_t **tokens,
+int skip_invalid)
+{
+int in_leading_space = 1;
+int in_trailing_space = 0;
+int string_end = 0;
+const char *tok_begin;
+const char *cur;
+
+if (!str_in) {
+return NULL;
+}
+
+tok_begin = cur = str_in;
+
+while (!string_end) {
+const unsigned char c = (unsigned char)*cur;
+
+if (!TEST_CHAR(c, T_HTTP_TOKEN_STOP) c != '\0') {
+/* Non-separator character; we are finished with leading
+ * whitespace. We must never have encountered any trailing
+ * whitespace before the delimiter (comma) */
+in_leading_space = 0;
+if (in_trailing_space) {
+return Encountered illegal whitespace in token;
+}
+}
+else if (c == ' ' || c == '\t') {
+/* Linear whitespace only includes ASCII CRLF, space, and tab;
+ * we can't get a CRLF since headers are split on them already,
+ * so only look for a space or a tab */
+if (in_leading_space) {
+/* We're still in leading whitespace */
+++tok_begin;
+}
+else {
+/* We must be in trailing whitespace */
+++in_trailing_space;
+}
+}
+else if (c == ',' || c == '\0') {
+if (!in_leading_space) {
+/* If we're out of the leading space, we know we've read some
+ * characters of a token */
+if (*tokens == NULL) {
+*tokens = apr_array_make(p, 4, sizeof(char *));
+}
+APR_ARRAY_PUSH(*tokens, char *) =
+apr_pstrmemdup((*tokens)-pool, tok_begin,
+ (cur - tok_begin) - in_trailing_space);
+}
+/* We're allowed to have null elements, just don't add them to the
+ * array */
+
+tok_begin = cur + 1;
+in_leading_space = 1;
+in_trailing_space = 0;
+string_end = (c == '\0');
+}
+else {
+/* Encountered illegal separator char */
+if (skip_invalid) {
+/* Skip to the next separator */
+const char *temp;
+temp = ap_strchr_c(cur, ',');
+if(!temp) {
+temp = ap_strchr_c(cur, '\0');
+}
+
+/* Act like we haven't seen a token so we reset */
+cur = temp - 1;
+in_leading_space = 1;
+in_trailing_space = 0;
+}
+else {
+return apr_psprintf(p, Encountered illegal separator
+'\\x%.2x', (unsigned int)c);
+}
+}
+
+++cur;
+}
+
+return NULL;
+}
+
/* Retrieve a token, spacing over it and returning a pointer to
* the first non-white byte afterwards. Note that these tokens
* are delimited by semis and commas; and can also be delimited
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c (revision 1610675)
+++ modules/proxy/proxy_util.c (working copy)
@@ -3122,68 +3122,58 @@ PROXY_DECLARE(proxy_balancer_shared *) ap_proxy_fi
typedef struct header_connection {
apr_pool_t *pool;
apr_array_header_t *array;
-const char *first;
-unsigned int closed:1;
+const char *error;
+int is_req;
} header_connection;
static int find_conn_headers(void *data, const char *key, const char *val)
{
header_connection *x = data;
-const char *name;
-
-do {
-while (*val == ',') {
-val++;
-}
-name = ap_get_token(x-pool, val, 0);
-if (!strcasecmp(name, close)) {
-x-closed = 1;
-}
-if
RE: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
Isn't x.is_req = (headers == r-headers_in); in ap_proxy_clear_connection an issue, when only called with the copy of r-headers_in? Regards Rüdiger -Original Message- From: Yann Ylavic Sent: Dienstag, 15. Juli 2014 15:00 To: httpd Subject: Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c On Tue, Jul 15, 2014 at 2:38 PM, Joe Orton jor...@redhat.com wrote: If somebody wants to propose a backport of r1610674 for 2.4.x please jump to it ASAP! Attached is a 2.4.x version of r1610674 that should work. r1588527 copies headers_in sooner in the function but ap_proxy_clear_connection() can still be called on the copy. Regards, Yann.
Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
On Tue, Jul 15, 2014 at 3:07 PM, Plüm, Rüdiger, Vodafone Group
ruediger.pl...@vodafone.com wrote:
Isn't
x.is_req = (headers == r-headers_in);
in ap_proxy_clear_connection an issue, when only called with the copy of
r-headers_in?
Hm, you are right.
Here is a v2 which introduces ap_proxy_clear_connection_ex(), with
ap_proxy_clear_connection(..., headers) =
ap_proxy_clear_connection_ex(..., headers, headers == r-headers_in)
Regards,
Yann.
Property changes on: .
___
Modified: svn:mergeinfo
Merged /httpd/httpd/trunk:r1610674
Index: server/util.c
===
--- server/util.c (revision 1610675)
+++ server/util.c (working copy)
@@ -1451,6 +1451,95 @@ AP_DECLARE(int) ap_find_etag_weak(apr_pool_t *p, c
return find_list_item(p, line, tok, AP_ETAG_WEAK);
}
+/* Grab a list of tokens of the format 1#token (from RFC7230) */
+AP_DECLARE(const char *) ap_parse_token_list_strict(apr_pool_t *p,
+const char *str_in,
+apr_array_header_t **tokens,
+int skip_invalid)
+{
+int in_leading_space = 1;
+int in_trailing_space = 0;
+int string_end = 0;
+const char *tok_begin;
+const char *cur;
+
+if (!str_in) {
+return NULL;
+}
+
+tok_begin = cur = str_in;
+
+while (!string_end) {
+const unsigned char c = (unsigned char)*cur;
+
+if (!TEST_CHAR(c, T_HTTP_TOKEN_STOP) c != '\0') {
+/* Non-separator character; we are finished with leading
+ * whitespace. We must never have encountered any trailing
+ * whitespace before the delimiter (comma) */
+in_leading_space = 0;
+if (in_trailing_space) {
+return Encountered illegal whitespace in token;
+}
+}
+else if (c == ' ' || c == '\t') {
+/* Linear whitespace only includes ASCII CRLF, space, and tab;
+ * we can't get a CRLF since headers are split on them already,
+ * so only look for a space or a tab */
+if (in_leading_space) {
+/* We're still in leading whitespace */
+++tok_begin;
+}
+else {
+/* We must be in trailing whitespace */
+++in_trailing_space;
+}
+}
+else if (c == ',' || c == '\0') {
+if (!in_leading_space) {
+/* If we're out of the leading space, we know we've read some
+ * characters of a token */
+if (*tokens == NULL) {
+*tokens = apr_array_make(p, 4, sizeof(char *));
+}
+APR_ARRAY_PUSH(*tokens, char *) =
+apr_pstrmemdup((*tokens)-pool, tok_begin,
+ (cur - tok_begin) - in_trailing_space);
+}
+/* We're allowed to have null elements, just don't add them to the
+ * array */
+
+tok_begin = cur + 1;
+in_leading_space = 1;
+in_trailing_space = 0;
+string_end = (c == '\0');
+}
+else {
+/* Encountered illegal separator char */
+if (skip_invalid) {
+/* Skip to the next separator */
+const char *temp;
+temp = ap_strchr_c(cur, ',');
+if(!temp) {
+temp = ap_strchr_c(cur, '\0');
+}
+
+/* Act like we haven't seen a token so we reset */
+cur = temp - 1;
+in_leading_space = 1;
+in_trailing_space = 0;
+}
+else {
+return apr_psprintf(p, Encountered illegal separator
+'\\x%.2x', (unsigned int)c);
+}
+}
+
+++cur;
+}
+
+return NULL;
+}
+
/* Retrieve a token, spacing over it and returning a pointer to
* the first non-white byte afterwards. Note that these tokens
* are delimited by semis and commas; and can also be delimited
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c (revision 1610675)
+++ modules/proxy/proxy_util.c (working copy)
@@ -3122,70 +3122,66 @@ PROXY_DECLARE(proxy_balancer_shared *) ap_proxy_fi
typedef struct header_connection {
apr_pool_t *pool;
apr_array_header_t *array;
-const char *first;
-unsigned int closed:1;
+const char *error;
+int is_req;
} header_connection;
static int find_conn_headers(void *data, const char *key, const char *val)
{
header_connection *x = data;
-const char *name;
-
-do {
-while (*val == ',') {
-val++;
-}
-name =
Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
On Tue, Jul 15, 2014 at 03:14:56PM +0200, Yann Ylavic wrote: On Tue, Jul 15, 2014 at 3:07 PM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: Isn't x.is_req = (headers == r-headers_in); in ap_proxy_clear_connection an issue, when only called with the copy of r-headers_in? Hm, you are right. Here is a v2 which introduces ap_proxy_clear_connection_ex(), with ap_proxy_clear_connection(..., headers) = ap_proxy_clear_connection_ex(..., headers, headers == r-headers_in) OK, great. That works for me with both test cases I have triggering a 400 now. Votes for 2.4.x on that please! +1 from me. Regards, Joe
Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
I am +1 on folding in the simpler patch that fixes the immediate problem and holding off on anything more complicated for the next release On Jul 15, 2014, at 8:38 AM, Joe Orton jor...@redhat.com wrote: On Tue, Jul 15, 2014 at 12:27:00PM -, jor...@apache.org wrote: Author: jorton Date: Tue Jul 15 12:27:00 2014 New Revision: 1610674 URL: http://svn.apache.org/r1610674 Log: SECURITY (CVE-2014-0117): Fix a crash in mod_proxy. In a reverse proxy configuration, a remote attacker could send a carefully crafted request which could crash a server process, resulting in denial of service. Backporting this to 2.4.x is non-trivial since trunk has diverged from 2.4.x via at least this change to how r-headers_in is handled: http://svn.apache.org/viewvc?view=revisionrevision=1588527 I am not sure how/whether that impacts the backport. We have a simpler version of the crasher fix which doesn't add strict interpretation of the Connection header - I am going to propose that for 2.4.x. If somebody wants to propose a backport of r1610674 for 2.4.x please jump to it ASAP! Regards, Joe
Re: stop copying footers to r-headers_in?
Candidate patch uses %I and %O but they are used by mod_logio. It is
hard to find two good unused characters.
What do people think about allowing two-character log formats? I
think patch below only breaks someone who had a %XX where XX is a
registered two digit tag and they expect the 1 char + literal (seems
safe enough to me even for 2.2)
http://people.apache.org/~covener/patches/httpd-trunk-logger-2chars.diff
Patch includes the trailers stuff in mod_log_config.
Test seems to work, normal access log unchanged and %{foo}Ti hits with
printf GET / HTTP/1.1\r\nHost: localhost\r\nTransfer-Encoding:
chunked\r\n\r\n0\r\nFoo: bar\r\n\r\n |nc 0 80
On Wed, Jun 25, 2014 at 1:23 PM, Edward Lu chaos...@gmail.com wrote:
Patch for trunk as well
On Wed, Jun 25, 2014 at 1:20 PM, Edward Lu chaos...@gmail.com wrote:
Wanted to follow up on this thread again; here's my latest patch on 2.2.x
that takes some ideas from Joe's patch. I also merge the trailers into the
headers after reading them now, instead of directly appending them into the
headers.
I will leave the PROXYREQ_RESPONSE case to someone else, as I still don't
fully understand it.
On Thu, May 15, 2014 at 3:20 PM, Yann Ylavic ylavic@gmail.com wrote:
I did not realize your mail is 8 days old, I just received it -- gmail
is having fun these days :(
Sorry for this misunderstanding and the reply that goes along...
Regards,
Yann.
--
Eric Covener
cove...@gmail.com
Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
I am very hesitant about adding this with so little review time... I would like to propose that we simply release 2.4.10 with the simple, trivial crash-fixer and allow us to spend more time on the below, in order to ensure it's solid. I'm -0.99 (for 2.4.x) :) On Jul 15, 2014, at 9:18 AM, Joe Orton jor...@redhat.com wrote: On Tue, Jul 15, 2014 at 03:14:56PM +0200, Yann Ylavic wrote: On Tue, Jul 15, 2014 at 3:07 PM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: Isn't x.is_req = (headers == r-headers_in); in ap_proxy_clear_connection an issue, when only called with the copy of r-headers_in? Hm, you are right. Here is a v2 which introduces ap_proxy_clear_connection_ex(), with ap_proxy_clear_connection(..., headers) = ap_proxy_clear_connection_ex(..., headers, headers == r-headers_in) OK, great. That works for me with both test cases I have triggering a 400 now. Votes for 2.4.x on that please! +1 from me. Regards, Joe
Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
On Tue, Jul 15, 2014 at 09:25:20AM -0400, Jim Jagielski wrote: I am very hesitant about adding this with so little review time... I would like to propose that we simply release 2.4.10 with the simple, trivial crash-fixer and allow us to spend more time on the below, in order to ensure it's solid. I'm -0.99 (for 2.4.x) :) That is my preference too, perhaps not quite as strong - Yann's patch fixes the issues and issues a 400 in the right places now, and passes the test suite here too. I've stuck it in STATUS. Any other opinions?
Re: stop copying footers to r-headers_in?
something odd in proxy path when backend has
#0 0x7f16f51b92e1 in apr_table_clear (t=0x0) at tables/apr_tables.c:467
467 t-a.nelts = 0;
(gdb) where
#0 0x7f16f51b92e1 in apr_table_clear (t=0x0) at tables/apr_tables.c:467
#1 0x00483bfc in read_chunked_trailers (ctx=0x7f16ac0125c0,
f=0x7f16ac012378, b=0x7f16ac00eec8, merge=0) at http_filters.c:198
#2 0x0048493d in ap_http_filter (f=0x7f16ac012378,
b=0x7f16ac00eec8, mode=AP_MODE_READBYTES, block=APR_NONBLOCK_READ,
readbytes=8192) at http_filters.c:448
#3 0x00439d8e in ap_get_brigade (next=0x7f16ac012378,
bb=0x7f16ac00eec8, mode=AP_MODE_READBYTES, block=APR_NONBLOCK_READ,
readbytes=8192) at util_filter.c:553
#4 0x7f16edb39794 in ap_proxy_http_process_response
(p=0x7f16ac004908, r=0x7f16ac004980, backend_ptr=0x7f16ea0c1a30,
worker=0x10154c8, conf=0x1015238,
server_portstr=0x7f16ea0c1a70 ) at mod_proxy_http.c:1693
#5 0x7f16edb3 in proxy_http_handler (r=0x7f16ac004980,
worker=0x10154c8, conf=0x1015238, url=0x7f16ac0063e6
http://127.0.0.1:81/trailer.asis;, proxyname=0x0, proxyport=0)
at mod_proxy_http.c:2049
#6 0x7f16edf51858 in proxy_run_scheme_handler (r=0x7f16ac004980,
worker=0x10154c8, conf=0x1015238, url=0x7f16ac0063e6
http://127.0.0.1:81/trailer.asis;, proxyhost=0x0,
proxyport=0) at mod_proxy.c:2798
#7 0x7f16edf4c650 in proxy_handler (r=0x7f16ac004980) at mod_proxy.c:1157
#8 0x00463ad1 in ap_run_handler (r=0x7f16ac004980) at config.c:169
#9 0x00464524 in ap_invoke_handler (r=0x7f16ac004980) at config.c:433
#10 0x004827ba in ap_process_async_request (r=0x7f16ac004980)
at http_request.c:317
#11 0x0047ebbb in ap_process_http_async_connection
(c=0x7f16e40b3790) at http_core.c:143
#12 0x0047eda8 in ap_process_http_connection
(c=0x7f16e40b3790) at http_core.c:228
#13 0x00471fc9 in ap_run_process_connection (c=0x7f16e40b3790)
at connection.c:41
#14 0x7f16ecea8f2c in process_socket (thd=0x111da28,
p=0x7f16e40b3488, sock=0x7f16e40b3500, cs=0x7f16e40b3708,
my_child_num=0, my_thread_num=0) at event.c:1077
#15 0x7f16eceabd98 in worker_thread (thd=0x111da28,
dummy=0x7f16e40008c0) at event.c:2141
#16 0x7f16f51d1f2a in dummy_worker (opaque=0x111da28) at
threadproc/unix/thread.c:142
#17 0x7f16f4f8c182 in start_thread (arg=0x7f16ea0c2700) at
pthread_create.c:312
(gdb) print *r
$1 = {pool = 0x7f16ac010a48, connection = 0x7f16ac008bb0, server =
0xfe2d08, next = 0x0, prev = 0x0, main = 0x0, the_request = 0x0,
assbackwards = 0, proxyreq = 3, header_only = 0,
proto_num = 0, protocol = 0x0, hostname = 0x0, request_time =
1405432560125880, status_line = 0x0, status = 200, method_number = 0,
method = 0x0, allowed = 0,
allowed_xmethods = 0x0, allowed_methods = 0x0, sent_bodyct = 0,
bytes_sent = 0, mtime = 0, range = 0x0, clength = 0, chunked = 0,
read_body = 0, read_chunked = 0,
expecting_100 = 0, kept_body = 0x0, body_table = 0x0, remaining = 0,
read_length = 0, headers_in = 0x0, headers_out = 0x7f16ac011938,
err_headers_out = 0x7f16ac011d20,
subprocess_env = 0x7f16ac011360, notes = 0x7f16ac011ec0,
content_type = 0x0, handler = 0x0, content_encoding = 0x0,
content_languages = 0x0, vlist_validator = 0x0, user = 0x0,
ap_auth_type = 0x0, unparsed_uri = 0x0, uri = 0x0, filename = 0x0,
canonical_filename = 0x0, path_info = 0x0, args = 0x0, used_path_info
= 0, eos_sent = 0, per_dir_config = 0x0,
request_config = 0x7f16ac012060, log = 0xfe2d28, log_id = 0x0,
htaccess = 0x0, output_filters = 0x7f16ac00cea8, input_filters =
0x7f16ac012378,
proto_output_filters = 0x7f16ac00cea8, proto_input_filters =
0x7f16ac012378, no_cache = 0, no_local_copy = 0, invoke_mtx = 0x0,
parsed_uri = {scheme = 0x0, hostinfo = 0x0,
user = 0x0, password = 0x0, hostname = 0x0, port_str = 0x0, path =
0x0, query = 0x0, fragment = 0x0, hostent = 0x0, port = 0,
is_initialized = 0, dns_looked_up = 0,
dns_resolved = 0}, finfo = {pool = 0x0, valid = 0, protection = 0,
filetype = APR_NOFILE, user = 0, group = 0, inode = 0, device = 0,
nlink = 0, size = 0, csize = 0, atime = 0,
mtime = 0, ctime = 0, fname = 0x0, name = 0x0, filehand = 0x0},
useragent_addr = 0x7f16ac008ab0, useragent_ip = 0x7f16ac008ca0
127.0.0.1, trailers_in = 0x0,
trailers_out = 0x7f16ac011b80}
I use mod_asis + proxy
Status: 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
1
a
0
Foo: quux
On Wed, Jun 25, 2014 at 1:23 PM, Edward Lu chaos...@gmail.com wrote:
Patch for trunk as well
On Wed, Jun 25, 2014 at 1:20 PM, Edward Lu chaos...@gmail.com wrote:
Wanted to follow up on this thread again; here's my latest patch on 2.2.x
that takes some ideas from Joe's patch. I also merge the trailers into the
headers after reading them now, instead of directly appending them into the
headers.
I will leave the PROXYREQ_RESPONSE case to someone else, as I still don't
fully understand it.
On Thu, May 15, 2014 at 3:20 PM, Yann Ylavic ylavic@gmail.com wrote:
RE: stop copying footers to r-headers_in?
Can you try if the following patch on top fixes this: Index: mod_proxy_http.c === --- mod_proxy_http.c(revision 1610607) +++ mod_proxy_http.c(working copy) @@ -1003,9 +1003,11 @@ rp-status = HTTP_OK; rp-headers_in = apr_table_make(pool, 50); +rp-trailers_in = apr_table_make(pool, 5); rp-subprocess_env = apr_table_make(pool, 50); rp-headers_out = apr_table_make(pool, 12); rp-err_headers_out = apr_table_make(pool, 5); +rp-trailers_out= apr_table_make(pool, 5); rp-notes = apr_table_make(pool, 5); rp-server = r-server; Regards Rüdiger -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Dienstag, 15. Juli 2014 16:02 To: Apache HTTP Server Development List Subject: Re: stop copying footers to r-headers_in? something odd in proxy path when backend has
Re: stop copying footers to r-headers_in?
Yes, thanks! The patch I started with had out but not in initialized there On Tue, Jul 15, 2014 at 10:20 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: Can you try if the following patch on top fixes this: Index: mod_proxy_http.c === --- mod_proxy_http.c(revision 1610607) +++ mod_proxy_http.c(working copy) @@ -1003,9 +1003,11 @@ rp-status = HTTP_OK; rp-headers_in = apr_table_make(pool, 50); +rp-trailers_in = apr_table_make(pool, 5); rp-subprocess_env = apr_table_make(pool, 50); rp-headers_out = apr_table_make(pool, 12); rp-err_headers_out = apr_table_make(pool, 5); +rp-trailers_out= apr_table_make(pool, 5); rp-notes = apr_table_make(pool, 5); rp-server = r-server; Regards Rüdiger -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Dienstag, 15. Juli 2014 16:02 To: Apache HTTP Server Development List Subject: Re: stop copying footers to r-headers_in? something odd in proxy path when backend has -- Eric Covener cove...@gmail.com
RE: stop copying footers to r-headers_in?
-Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Dienstag, 15. Juli 2014 15:25 To: Apache HTTP Server Development List Subject: Re: stop copying footers to r-headers_in? Candidate patch uses %I and %O but they are used by mod_logio. It is hard to find two good unused characters. What do people think about allowing two-character log formats? I think patch below only breaks someone who had a %XX where XX is a registered two digit tag and they expect the 1 char + literal (seems safe enough to me even for 2.2) Is there a way for people with such a setup to fix this with a different config? From the top of my head I would say no and that would be a blocker. Regards Rüdiger
Re: stop copying footers to r-headers_in?
On Jul 15, 2014, at 10:38 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Dienstag, 15. Juli 2014 15:25 To: Apache HTTP Server Development List Subject: Re: stop copying footers to r-headers_in? Candidate patch uses %I and %O but they are used by mod_logio. It is hard to find two good unused characters. What do people think about allowing two-character log formats? I think patch below only breaks someone who had a %XX where XX is a registered two digit tag and they expect the 1 char + literal (seems safe enough to me even for 2.2) Is there a way for people with such a setup to fix this with a different config? From the top of my head I would say no and that would be a blocker. Agreed
Re: stop copying footers to r-headers_in?
On Tue, Jul 15, 2014 at 10:38 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: Is there a way for people with such a setup to fix this with a different config? From the top of my head I would say no and that would be a blocker. Do you think the required '^' prefix in the followup is enough? In this case, to be broken, you would have a custom module that accepted %^ AND you would have had two constant characters in your format that match a newly added format. -- Eric Covener cove...@gmail.com
RE: stop copying footers to r-headers_in?
-Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Dienstag, 15. Juli 2014 16:52 To: Apache HTTP Server Development List Subject: Re: stop copying footers to r-headers_in? On Tue, Jul 15, 2014 at 10:38 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: Is there a way for people with such a setup to fix this with a different config? From the top of my head I would say no and that would be a blocker. Do you think the required '^' prefix in the followup is enough? In I think I missed the follow up. Where can I find it? Regards Rüdiger
Re: stop copying footers to r-headers_in?
On Tue, Jul 15, 2014 at 10:56 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Dienstag, 15. Juli 2014 16:52 To: Apache HTTP Server Development List Subject: Re: stop copying footers to r-headers_in? On Tue, Jul 15, 2014 at 10:38 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: Is there a way for people with such a setup to fix this with a different config? From the top of my head I would say no and that would be a blocker. Do you think the required '^' prefix in the followup is enough? In I think I missed the follow up. Where can I find it? http://svn.apache.org/viewvc?view=revisionrevision=r1610707
RE: stop copying footers to r-headers_in?
-Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Dienstag, 15. Juli 2014 17:02 To: Apache HTTP Server Development List Subject: Re: stop copying footers to r-headers_in? On Tue, Jul 15, 2014 at 10:56 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Dienstag, 15. Juli 2014 16:52 To: Apache HTTP Server Development List Subject: Re: stop copying footers to r-headers_in? On Tue, Jul 15, 2014 at 10:38 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: Is there a way for people with such a setup to fix this with a different config? From the top of my head I would say no and that would be a blocker. Do you think the required '^' prefix in the followup is enough? In I think I missed the follow up. Where can I find it? http://svn.apache.org/viewvc?view=revisionrevision=r1610707 This should work. But don't you need to register then ^Ti instead of Ti? Regards Rüdiger
Re: stop copying footers to r-headers_in?
On Tue, Jul 15, 2014 at 11:07 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: This should work. But don't you need to register then ^Ti instead of Ti? yeah, it needs to be registered and used in httpd.conf w/ the ^ -- Eric Covener cove...@gmail.com
RE: stop copying footers to r-headers_in?
That would be at least half my fault for responding off-list... Here it is: Thanks -- I went with ^ Shouldn't have much worry about responding to dev@ On Tue, Jul 15, 2014 at 9:42 AM, Houser, Rick rick.hou...@us.pgds.com wrote: New to this list, so responding directly until I have a better feel Wouldn't a three character tag be safer with the first being a dedicated (unused) prefix to unlock the additional bytes, like Unicode? Something like this: _char1char2 (note, I didn't check if _ was used -- just using it as an example) Rick Houser Rick Houser Web Administration (517)367-3516 -Original Message- From: Plüm, Rüdiger, Vodafone Group [mailto:ruediger.pl...@vodafone.com] Sent: Tuesday, July 15, 2014 10:56 AM To: dev@httpd.apache.org Subject: RE: stop copying footers to r-headers_in? -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Dienstag, 15. Juli 2014 16:52 To: Apache HTTP Server Development List Subject: Re: stop copying footers to r-headers_in? On Tue, Jul 15, 2014 at 10:38 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: Is there a way for people with such a setup to fix this with a different config? From the top of my head I would say no and that would be a blocker. Do you think the required '^' prefix in the followup is enough? In I think I missed the follow up. Where can I find it? Regards Rüdiger
VOTE PLEASE! Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
On Tue, Jul 15, 2014 at 02:41:44PM +0100, Joe Orton wrote: I've stuck it in STATUS. Any other opinions? Come on... one more for this, either way? * mod_proxy Connection handling crasher, CVE-2014-0117 trunk patch: http://svn.apache.org/r1610674 ALTERNATIVE #1 2.4.x patch: http://people.apache.org/~jorton/CVE-2014-0117-simple.patch +1: jorton, jim ALTERNATIVE #2 2.4.x patch: http://people.apache.org/~jorton/2.4.x-CVE-2014-0117_v2.patch (ylavic) +1: jorton, ylavic -0.99: jim (not enough time for a serious review for inclusion in 2.4.10) ylavic: works here, and checking RFC compliance if the Connection header looks quite important to me.
Re: VOTE PLEASE! Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
On Tue, Jul 15, 2014 at 11:59 AM, Joe Orton jor...@redhat.com wrote: On Tue, Jul 15, 2014 at 02:41:44PM +0100, Joe Orton wrote: I've stuck it in STATUS. Any other opinions? Come on... one more for this, either way? * mod_proxy Connection handling crasher, CVE-2014-0117 trunk patch: http://svn.apache.org/r1610674 ALTERNATIVE #1 2.4.x patch: http://people.apache.org/~jorton/CVE-2014-0117-simple.patch +1: jorton, jim dirty deed done ALTERNATIVE #2 2.4.x patch: http://people.apache.org/~jorton/2.4.x-CVE-2014-0117_v2.patch (ylavic) +1: jorton, ylavic -0.99: jim (not enough time for a serious review for inclusion in 2.4.10) ylavic: works here, and checking RFC compliance if the Connection header looks quite important to me. -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: VOTE PLEASE! Re: svn commit: r1610674 - in /httpd/httpd/trunk: include/ap_mmn.h include/httpd.h modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c server/util.c
On Tue, Jul 15, 2014 at 11:59 AM, Joe Orton jor...@redhat.com wrote: On Tue, Jul 15, 2014 at 02:41:44PM +0100, Joe Orton wrote: I've stuck it in STATUS. Any other opinions? Come on... one more for this, either way? * mod_proxy Connection handling crasher, CVE-2014-0117 trunk patch: http://svn.apache.org/r1610674 ALTERNATIVE #1 2.4.x patch: http://people.apache.org/~jorton/CVE-2014-0117-simple.patch +1: jorton, jim dirty deed done ALTERNATIVE #2 2.4.x patch: http://people.apache.org/~jorton/2.4.x-CVE-2014-0117_v2.patch (ylavic) +1: jorton, ylavic -0.99: jim (not enough time for a serious review for inclusion in 2.4.10) ylavic: works here, and checking RFC compliance if the Connection header looks quite important to me. -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
[VOTE] Release Apache httpd 2.4.10 as GA
The pre-release test tarballs for Apache httpd 2.4.10 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.10 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience.
Time for httpd 2.2.28??
If so, I can RM.
Re: [VOTE] Release Apache httpd 2.4.10 as GA
Testing Linux and OSX 1st (all using Event MPM): So far, +1 on all the below: CentOS 7 Linux centos7.localdomain 3.10.0-123.4.2.el7.x86_64 #1 SMP Mon Jun 30 16:09:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux OSX 10.9.4 / Xcode 5.1.1 Darwin jimsys 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64 CentOS 6 Linux centos6.localdomain 2.6.32-431.17.1.el6.x86_64 #1 SMP Wed May 7 23:32:49 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux CentOS 5 Linux centos5.localdomain 2.6.18-371.9.1.el5 #1 SMP Tue Jun 10 17:49:56 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux FreeBSD coming up. On Jul 15, 2014, at 1:20 PM, Jim Jagielski j...@jagunet.com wrote: The pre-release test tarballs for Apache httpd 2.4.10 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.10 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience.
Re: svn commit: r1610814 - in /httpd/httpd/trunk: ./ docs/manual/mod/ include/ modules/http/ modules/loggers/ modules/proxy/ server/
cove...@apache.org wrote: Author: covener Date: Tue Jul 15 19:11:02 2014 New Revision: 1610814 URL: http://svn.apache.org/r1610814 Log: *) SECURITY: CVE-2013-5704 (cve.mitre.org) core: HTTP trailers could be used to replace HTTP headers late during request processing, potentially undoing or otherwise confusing modules that examined or modified request headers earlier. Adds MergeTrailers directive to restore legacy behavior. Submitted By: Edward Lu, Yann Ylavic, Joe Orton, Eric Covener Committed By: covener Modified: httpd/httpd/trunk/CHANGES httpd/httpd/trunk/docs/manual/mod/core.xml httpd/httpd/trunk/docs/manual/mod/mod_log_config.xml httpd/httpd/trunk/include/ap_mmn.h httpd/httpd/trunk/include/http_core.h httpd/httpd/trunk/include/httpd.h httpd/httpd/trunk/modules/http/http_filters.c httpd/httpd/trunk/modules/http/http_request.c httpd/httpd/trunk/modules/loggers/mod_log_config.c httpd/httpd/trunk/modules/proxy/mod_proxy_http.c httpd/httpd/trunk/server/core.c httpd/httpd/trunk/server/protocol.c I now see one regression in the test suite, but maybe the test is wrong now. t/apache/chunkinput.t .. 1..9 # Running under perl version 5.010001 for linux # Current time local: Tue Jul 15 21:42:16 2014 # Current time GMT: Tue Jul 15 19:42:16 2014 # Using Test.pm version 1.25_02 # Using Apache/Test.pm version 1.38 testing default ok 1 # testing : response codes # expected: 'HTTP/1.1 200 OK' # received: 'HTTP/1.1 200 OK' ok 2 # testing : trailer (pid) # expected: '25829' # received: 'No chunked trailer available!' not ok 3 ok 4 # Failed test 3 in t/apache/chunkinput.t at line 71 # testing : response codes # expected: 'HTTP/1.1 404 Not Found' # received: 'HTTP/1.1 404 Not Found' ok 5 ok 6 # testing : response codes # expected: 'HTTP/1.1 413 Request Entity Too Large' # received: 'HTTP/1.1 413 Request Entity Too Large' ok 7 ok 8 # testing : response codes # expected: 'HTTP/1.1 413 Request Entity Too Large' # received: 'HTTP/1.1 413 Request Entity Too Large' ok 9 Failed 1/9 subtests Test Summary Report --- t/apache/chunkinput.t (Wstat: 0 Tests: 9 Failed: 1) Failed test: 3 Files=1, Tests=9, 0 wallclock secs ( 0.01 usr 0.00 sys + 0.34 cusr 0.09 csys = 0.44 CPU) Result: FAIL Failed 1/1 test programs. 1/9 subtests failed. [warning] server localhost:8529 shutdown [ error] error running tests (please examine t/logs/error_log) Regards Rüdiger
Re: svn commit: r1610814 - in /httpd/httpd/trunk: ./ docs/manual/mod/ include/ modules/http/ modules/loggers/ modules/proxy/ server/
On Tue, Jul 15, 2014 at 3:44 PM, Ruediger Pluem rpl...@apache.org wrote: # testing : trailer (pid) # expected: '25829' # received: 'No chunked trailer available!' not ok 3 thanks, r1610833: #ifdef APACHE1 trailer_header = ap_table_get(r-headers_in, X-Chunk-Trailer); +#elif (MODULE_MAGIC_COOKIE = 0x41503235UL) AP_MODULE_MAGIC_AT_LEAST(20140627,5) +trailer_header = apr_table_get(r-trailers_in, X-Chunk-Trailer); #else trailer_header = apr_table_get(r-headers_in, X-Chunk-Trailer); -- Eric Covener cove...@gmail.com
Re: Question on ap_method_* functions
Le 15/07/2014 10:15, Plüm, Rüdiger, Vodafone Group a écrit :
- in 'ap_method_list_remove()',
l-method_mask |= ~(AP_METHOD_BIT methnum);
Doesn't this need to be
l-method_mask = ~(AP_METHOD_BIT methnum);
in order to remove it? Otherwise I set all methods but methnum.
should be in the
if (methnum != M_INVALID) { ... }
block
Do you agree ?
Yes.
Regards
Rüdiger
Thanks for your comment.
Applied to trunk in r1610813 with your comment.
Proposed for 2.4.x.
Best regards,
CJ
Re: stop copying footers to r-headers_in?
On 15 Jul 2014, at 15:38, Rüdiger Plüm ruediger.pl...@vodafone.com wrote:
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Dienstag, 15. Juli 2014 15:25
To: Apache HTTP Server Development List
Subject: Re: stop copying footers to r-headers_in?
What do people think about allowing two-character log formats? I
think patch below only breaks someone who had a %XX where XX is a
registered two digit tag and they expect the 1 char + literal (seems
safe enough to me even for 2.2)
Is there a way for people with such a setup to fix this with a different
config?
From the top of my head I would say no and that would be a blocker.
%{thing}[label] perhaps? Maybe it's too confusing / contrived, maybe it's not
needed (yet).
Like this, for an imaginary new format string label %[foo]
LogFormat %{%Y-%m-%d}tT%{%H:%M:%S}t%{usec_frac}t %{usec_frac}[foo]
and for another label %[bar]:
LogFormat %{sec}t%{msec_frac}t %s %[bar] %L %{REQUEST_STATUS} -strcmatch
'5*'
--
Tim Bannister – is...@jellybaby.net
Re: Time for httpd 2.2.28??
If you have the similar tool chain revs as .27, terrific! Otherwise, I'll tag in the a.m. +1 from me, of course. Jim Jagielski j...@jagunet.com wrote: If so, I can RM.
