Re: svn commit: r1492395 - in /httpd/httpd/trunk: CHANGES modules/aaa/mod_auth_digest.c
On Jun 12, 2013, at 12:34 PM, s...@apache.org wrote:
Author: sf
Date: Wed Jun 12 19:34:19 2013
New Revision: 1492395
URL: http://svn.apache.org/r1492395
Log:
Actually use the secret when generating nonces.
This change may cause problems if used with round robin load balancers.
Before it is backported, we should add a directive to use a user specified
secret.
PR: 54637
FWIW, I don't think this code can be released as is.
Yes, the prior code is broken, in that it creates the
nonce using a supposedly random value before that value is
actually initialized, and thus ends up creating a nonce that
is effectively just a timestamp.
However, fixing that is an error in itself, since the nonce
should not be random, which is why the existing code actually
works the way the reporter wanted.
The change from static global array to a static global pointer
into an allocated module config pool (?) obscures the bug fix
change of
@@ -453,6 +473,21 @@ static void *create_digest_dir_config(ap
static const char *set_realm(cmd_parms *cmd, void *config, const char *realm)
{
digest_config_rec *conf = (digest_config_rec *) config;
+int i;
+
+/* pass NULL because cmd-server may not have a valid log config yet */
+if (secret == NULL
+ initialize_secret(cmd-server-process-pool, NULL) !=
APR_SUCCESS)
+return Could not get random numbers for secret;
+
+#ifdef AP_DEBUG
+/* check that we got random numbers */
+for (i = 0; i SECRET_LEN; i++) {
+if (secret[i] != 0)
+break;
+}
+ap_assert(i SECRET_LEN);
+#endif
Using a global pointer to an allocated pool variable is
not even remotely safe when that pool gets deallocated.
And a routine that gets called within .htaccess files is not an
appropriate place to set a server-wide value.
The nonce is supposed to be window-valid and verifiable, not
random. Hence, this part of the nonce should be a configurable
salt shared by all servers for a given hostname. Likewise,
the request host:port needs to be in the nonce hash, but now
I see that the prior code for that was commented-out by Ronald.
The window seems to be handled elsewhere using a timestamp.
If we assume that something like the above is planned
as an actual fix, then this patch is only complicating matters.
So, I suggest that the new code is not an improvement.
I think a better solution would be to simply remove the secret
hash entirely and figure out why this code in gen_nonce_hash()
1074ronald 85341/*
1075dougm 88019apr_sha1_update_binary(ctx, (const unsigned char *)
server-server_hostname,
1076aaron 92626strlen(server-server_hostname));
1077dougm 88019apr_sha1_update_binary(ctx, (const unsigned char *)
server-port,
1078aaron 92626sizeof(server-port));
1079ronald 85341*/
was commented out by Ronald in
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/aaa/mod_auth_digest.c?r1=85340r2=85341pathrev=1492395view=patch
because that is where the real fix should be. The current secret
should be replaced here by a configurable string that is set in
the virtual host config.
However, I am no expert with this code, and have no convenient
means for testing whatever I'd screw up by making changes here.
I am hoping that others on the list can look at this discussion
and either confirm my worries or explain why the random secret
is needed.
Cheers,
Roy
Re: Apache 2.2 - Change default for SSLCompression to off
On 12 June 2013 23:00, William A. Rowe Jr. wr...@rowe-clan.net wrote: On Wed, 12 Jun 2013 21:05:05 +0100 Ben Laurie b...@links.org wrote: On 12 June 2013 20:49, William A. Rowe Jr. wr...@rowe-clan.net wrote: On Wed, 12 Jun 2013 21:24:31 +0200 Reindl Harald h.rei...@thelounge.net wrote: well, on Redhat systems in /etc/sysconfig/httpd put the line OPENSSL_NO_DEFAULT_ZLIB=1 did disable it before httpd offered a option, but IHMO any server software should come with as much as secure defaults if they do not hurt Nothing special about httpd. That is an OpenSSL flag (a patch still not adopted upstream AIUI) but it controls default behavior, not negotiated behavior. I believe our patch disables compression altogether, which is a very different toggle, but I could be wrong. In fact, the patch's docs text is wrong on the face of it; Enabling compression causes security issues in most setups (the so called +CRIME attack) This is true of specific setups where the user agent simultaneously shares a compression dictionary between different client applications where one may be nefarious. The vulnerability is to permit an untrusted agent (script) to share a single SSL and zlib session with a trusted/secured agent. This is a flaw on multiple levels, not just limited to zlib compression packet sizes. What is useful about the RH patch is that it allows zlib to default to disabled behavior (but elect to be enabled) for ANY affected user agent/server. What is further incorrect about **our claim** is that most user agents have been patched against this specific abuse. If our claim is to be believed, all services would appear vulnerable, not simply HTTP. CRIME-vulnerable browsers have already been patched. By perpetuating stupid claims, we perpetrate stupidity for our users and in the media (who then proceeds to further perpetuate stupidity for our users). I think we should hold ourselves to a higher standard than alarmist and inaccurate user docs notes. If we want to assign credit to a class of insecurities, we should cite primary sources (and let the security community publish meaningful analysis and guidance). Enabling compression may introduce security issues in specific user-agents, particularly un-patched, insecure older browsers, and other badly designed user agents (an example, the so called +CRIME attack). J Kelsey of Certicom described in Compression and Information Leakage of Plain Text [http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf] how a nefarious user agent or application may inject patterns when sharing an SSL session with an otherwise trusted agent or application and then inspect the actual compressed stream for variations, provided it has access to that raw transport stream. I think such a statement would be far more accurate, but I'll leave it to folks who are more expert than I to further wordsmith our claim. Actually, compression violates semantic security, and so, on general principle, should be avoided unless you accept that risk (which is hard to quantify, but sometimes large). Understood, so I interpret that you would be in favor of changing this sslcompression choice to disabled-by-default? In that case, I'm very willing to toggle my vote from -0 to +0. Yes. I'm very interested in your short observation of how the OpenSSL project is reacting, given this set of concerns and considerations? Its tricky for OpenSSL because compression is not a configurable option, its set (or not) by code, so we can't really change the default. The paranoid could build OpenSSL with OPENSSL_NO_COMP, but that might break applications.
mod_cache_socache onliner bugfix
Makes config merge work. Regards, Jens max_set.pat Description: Binary data
Re: mod_cache_socache onliner bugfix
On 13 Jun 2013, at 1:07 PM, Jens Låås jel...@gmail.com wrote: Makes config merge work. Thanks for this, committed to trunk in http://svn.apache.org/r1492663, proposed for backport to v2.4. Regards, Graham --
Re: svn commit: r1492706 - /httpd/httpd/branches/2.4.x/STATUS
j...@apache.org wrote: Author: jim Date: Thu Jun 13 15:30:01 2013 New Revision: 1492706 URL: http://svn.apache.org/r1492706 Log: other possible backports Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1492706r1=1492705r2=1492706view=diff == @@ -211,7 +211,29 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: trunk patch: https://svn.apache.org/viewvc?view=revisionrevision=1482522 2.4.x patch: trunk patch works modulo CHANGES and ap_mmn +1: - + +* mod_proxy: support Unix domain sockets + trunk patch: https://svn.apache.org/viewvc?view=revisionrevision=1451633 + https://svn.apache.org/viewvc?view=revisionrevision=1451905 + https://svn.apache.org/viewvc?view=revisionrevision=1451921 + https://svn.apache.org/viewvc?view=revisionrevision=1452259 + https://svn.apache.org/viewvc?view=revisionrevision=1453981 + 2.4.x patch: trunk patch works modulo CHANGES and ap_mmn + +1: + +* mod_proxy: Ensure network errors detected by the proxy are returned as + 504 Gateway Timout as opposed to 502 Bad Gateway + trunk patch: https://svn.apache.org/viewvc?view=revisionrevision=1480058 + 2.4.x patch: trunk patch works modulo CHANGES + +1: This one is still disputed and we are waiting for Roy's final judgement about what is correct here. So I would oppose backporting it at this point of time. Regards Rüdiger
Re: svn commit: r1492706 - /httpd/httpd/branches/2.4.x/STATUS
I just have it there as a place holder so we don't forget it. (notice that that +1 line is blank) On Jun 13, 2013, at 2:36 PM, Ruediger Pluem rpl...@apache.org wrote: j...@apache.org wrote: Author: jim Date: Thu Jun 13 15:30:01 2013 New Revision: 1492706 URL: http://svn.apache.org/r1492706 Log: other possible backports Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1492706r1=1492705r2=1492706view=diff == @@ -211,7 +211,29 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: trunk patch: https://svn.apache.org/viewvc?view=revisionrevision=1482522 2.4.x patch: trunk patch works modulo CHANGES and ap_mmn +1: - + +* mod_proxy: support Unix domain sockets + trunk patch: https://svn.apache.org/viewvc?view=revisionrevision=1451633 + https://svn.apache.org/viewvc?view=revisionrevision=1451905 + https://svn.apache.org/viewvc?view=revisionrevision=1451921 + https://svn.apache.org/viewvc?view=revisionrevision=1452259 + https://svn.apache.org/viewvc?view=revisionrevision=1453981 + 2.4.x patch: trunk patch works modulo CHANGES and ap_mmn + +1: + +* mod_proxy: Ensure network errors detected by the proxy are returned as + 504 Gateway Timout as opposed to 502 Bad Gateway + trunk patch: https://svn.apache.org/viewvc?view=revisionrevision=1480058 + 2.4.x patch: trunk patch works modulo CHANGES + +1: This one is still disputed and we are waiting for Roy's final judgement about what is correct here. So I would oppose backporting it at this point of time. Regards Rüdiger
Re: svn commit: r1492706 - /httpd/httpd/branches/2.4.x/STATUS
Jim Jagielski wrote: I just have it there as a place holder so we don't forget it. (notice that that +1 line is blank) Yes. http://mail-archives.apache.org/mod_mbox/httpd-dev/201305.mbox/%3C1B16B9E3-87BA-4EEF-939C-7C7313B54714%40gbiv.com%3E for the gory details. Regards Rüdiger
Re: looking for luv
On 12 Jun 2013, at 20:08, Stefan Fritsch s...@sfritsch.de wrote: There doesn't seem to be any user of the skiplist than register_timed_callback, and there doesn't seem to be any user of register_timed_callback besides mod_dialup.c. Is mod_dialup really that important? And is the inefficiency there a big problem? Maybe we could wait until there are more users of the API? APIs that don't exist don't attract users. From the perspective of ordinary people, the most recent code is httpd v2.4, and that is the latest code that actually exists in the minds of people doing development. I am interested in reviewing it, but have some other work to finish first. Regards, Graham --
Re: looking for luv
On Jun 13, 2013, at 6:21 PM, Graham Leggett minf...@sharp.fm wrote: I am interested in reviewing it, but have some other work to finish first. Thx. BTW, a reminder that it's based on Theo's code from mod_log_spread et.al.
