Build failed in Hudson: 3.2-amd64-CentOS-5.3 #15
See http://build.squid-cache.org/job/3.2-amd64-CentOS-5.3/15/changes Changes: [Amos Jeffries amosjeffr...@squid-cache.org] Unit-tests for the new HTTP request-line parser [Amos Jeffries amosjeffr...@squid-cache.org] Harden and speed up HTTP request-line parser An upgrade/fix to handling HTTP request-lines as specific by section 5.1 of the RFCs. Specifically to handle a sequence of unknown bytes up to a terminating LF (\n) octet. * The semantics as previously documented are taken on. No changes there, but documentation clarified a bit. Some things previously not erroring are now doing so. External code impact is in the nature of reduced special cases to be handled. Specifically raw-CR weirdness in the request line fields. This occuring in URL was a vulnerability at least once before. * Prior updates to HttpParser object for other parse stages opens the possibility of this parse action returning HTTP status code directly. Additions are done to make use of this (with the existing status codes only). * Input permutations where the unit-tests showed the old parser was violating its own documentation have been fixed to produce expected outputs. * Old parser operated three distinct potentially long parse loops. Added several local variables to remember various octets seen while searching for the terminal LF. This removed the need for two of the parse re-scans (length of method, length of URI). * relaxed_header_parser will enable it to also skip prefix whitespace (space character only) and multiple-\r sequences at the end of line. * --enable-http-violations is still required before it will accept non-HTTP version types 'downgraded' to HTTP/0.9 [Amos Jeffries amosjeffr...@squid-cache.org] Author: Alex Rousskov rouss...@measurement-factory.com Improve request smuggling attack detection. Tolerate valid benign HTTP headers. Removed double CR check from parseHttpRequest() for several reasons: 1) The check was most likely introduced as a short-term defense against HTTP request smuggling attacks identified in an influential 2004 paper. The paper documented certain vulnerabilities related to requests with double CR sequences, and Squid was quickly hacked to prohibit such requests as malformed. However, a more careful reading of the paper indicates that only LF CR CR LF (a.k.a. CR header) sequences were identified as dangerous (note the leading LF). The quick fix was too aggressive and blocked _all_ requests with CR CR LF sequences, including benign requests. 2) The check duplicated a HttpHeader::parse() check. 3) The check was slower than the code it duplicated. Improved double CR handling in HttpHeader::parse() to detect potentially dangerous empty headers, that is header fields that contain nothing but CR character(s). Requests with such headers are rejected as malformed. We used to reject similar requests (and more) in parseHttpRequest() as described above. After the change, potentially malicious requests with CR+ headers are still denied. Other, benign headers ending with CRs are now allowed. If the HTTP header parser is not relaxed, benign and valid requests with extra CR characters are blocked as before. -- [...truncated 5524 lines...] OK (0) PASS: testIcmp == All 2 tests passed == make[5]: Leaving directory `http://build.squid-cache.org/job/3.2-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.2.0.1-BZR/_build/src/icmp' make[4]: Leaving directory `http://build.squid-cache.org/job/3.2-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.2.0.1-BZR/_build/src/icmp' Making check in ident make[4]: Entering directory `http://build.squid-cache.org/job/3.2-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.2.0.1-BZR/_build/src/ident' make make[5]: Entering directory `http://build.squid-cache.org/job/3.2-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.2.0.1-BZR/_build/src/ident' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `http://build.squid-cache.org/job/3.2-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.2.0.1-BZR/_build/src/ident' make check-TESTS make[5]: Entering directory `http://build.squid-cache.org/job/3.2-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.2.0.1-BZR/_build/src/ident' /bin/sh ../../../test-suite/testheaders.sh g++ -DHAVE_CONFIG_H -I../../.. -I../../../include -I../../../src -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 ../../../src/ident || exit 1 Testing ../../../src/ident ...Ok. PASS: testHeaders == All 1 tests passed == make[5]: Leaving directory `http://build.squid-cache.org/job/3.2-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.2.0.1-BZR/_build/src/ident' make[4]: Leaving directory `http://build.squid-cache.org/job/3.2-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.2.0.1-BZR/_build/src/ident' Making check in log make[4]: Entering directory
Re: CrossCompile
ok .. all warnings against, I tried with a host_cf_gen and changed in src/Makefile ./cf_gen ... to ./host_cf_gen ... .. It seems to work .. seems .. configure runs ok ... l/liblru.a repl/libheap.a libBlocking.a libDiskDaemon.a libDiskThreads.a -lpthread -lcrypt -lssl -lcrypto -lmiscutil -lm ../libltdl/.libs/libltdlc.a -ldl -Wl,-rpath -Wl,/home/kromonos/buildroot/buildroot/output/staging/usr/i486-unknown-linux-uclibc/lib -Wl,-rpath -Wl,/home/kromonos/buildroot/buildroot/output/staging/usr/i486-unknown-linux-uclibc/lib /home/kromonos/buildroot/buildroot/output/staging/usr/lib/libcrypto.so: warning: gethostbyname is obsolescent, use getnameinfo() instead. ip/.libs/libip.a(IpAddress.o): In function `IpAddress::SetLocalhost()': /home/kromonos/buildroot/build/squid-3.1.7/build/src/ip/../../../src/ip/IpAddress.cc:258: undefined reference to `in6addr_loopback' collect2: ld returned 1 exit status libtool: link: rm -f .libs/squidS.o make[3]: *** [squid] Error 1 make[3]: Leaving directory `/home/kromonos/buildroot/build/squid-3.1.7/build/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/kromonos/buildroot/build/squid-3.1.7/build/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/kromonos/buildroot/build/squid-3.1.7/build/src' make: *** [all-recursive] Error 1 I've attached config.log Am Sun, 29 Aug 2010 schrieb Henrik Nordström: sön 2010-08-29 klockan 15:17 +0200 skrev kromo...@user-helfen-usern.de: A No need to do, I think. It's like cross compiling python. maybe, it's possible to first create cf_gen with host compiler and set a variable for make command, which says, which cf_gen to use. So, host cf_gen could be renamed to hostcf_gen. cf_gen='hostcf_gen' make Problem here is that cf_gen gets a lot of configure details compiled ín. The above only works if the configure arguments when you compile cf_gen is very close to what you use for building squid. But it's also pretty much what the cross compile setups I have seen for Squid is doing. Regards Henrik -- Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.gnu.org/philosophy/no-word-attachments.de.html -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s-: a- C UL+++ P L E- W+++ N++ o++ K- w--- O- M- V- PS+++ PE- Y PGP++ t+++ 5+++ X+ R++ tv++ b- DI- D- G+++ e h-- r+++ y+++ --END GEEK CODE BLOCK-- config.log.squid.bz2 Description: BZip2 compressed data pgpZFOjvCXhwL.pgp Description: PGP signature
Format of variable names
Quick question please: Should variables be named in the form outgoingNetfilterMark or outgoing_netfilter_mark, or does it not matter? There appears to be a variety of formats in use in the existing code. Thanks, Andy
Re: OPTIONS/TRACE denial patch condition is wrong
(08:28:14 AM) amosjeffries: rousskov: two priority things for you. please review the OPTIONS/TRACE denial patch against your intentions. the new return condition is wrong. false==emit 400, true == continue processing/passthru the request. (sorry) Hi Amos, The code looks correct to me. The outcome is also correct: Max-Forwards URL Action 0 nonstar501 0*501 1+ nonstar forwarded 1+*501 none nonstar forwarded none*501 You may be confused because the first two 501s mean here is our compliant response to your OPTIONS request directed at Squid while the other two 501s mean we do not support forwarding of OPTIONS requests with a * URI. These two cases might become different if we start providing some useful information in the OPTIONS responses directed at us. FWIW, if we let *-URIs through the urlCheckRequest() check, the user will get a misleading ERR_DNS_FAIL when Squid tries to forward the request. Fixing *-URI forwarding is outside the scope of the committed patch. Hope this clarifies, Alex. P.S. I added a comment to urlCheckRequest(), reflecting the above.
Re: Format of variable names
Andrew Beverley wrote: Quick question please: Should variables be named in the form outgoingNetfilterMark or outgoing_netfilter_mark, or does it not matter? There appears to be a variety of formats in use in the existing code. We are trying to polish it all up towards camelCase please. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.7 Beta testers wanted for 3.2.0.1
Re: OPTIONS/TRACE denial patch condition is wrong
Alex Rousskov wrote: (08:28:14 AM) amosjeffries: rousskov: two priority things for you. please review the OPTIONS/TRACE denial patch against your intentions. the new return condition is wrong. false==emit 400, true == continue processing/passthru the request. (sorry) Hi Amos, The code looks correct to me. The outcome is also correct: Max-Forwards URL Action 0 nonstar501 0*501 1+ nonstar forwarded 1+*501 none nonstar forwarded none*501 You may be confused because the first two 501s mean here is our compliant response to your OPTIONS request directed at Squid while the other two 501s mean we do not support forwarding of OPTIONS requests with a * URI. These two cases might become different if we start providing some useful information in the OPTIONS responses directed at us. FWIW, if we let *-URIs through the urlCheckRequest() check, the user will get a misleading ERR_DNS_FAIL when Squid tries to forward the request. Fixing *-URI forwarding is outside the scope of the committed patch. Hope this clarifies, It does. And thanks for the extra code docs. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.7 Beta testers wanted for 3.2.0.1
Hudson build is back to normal : 3.HEAD-amd64-CentOS-5.3 #808
See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/808/changes
Hudson build is back to normal : 3.2-amd64-CentOS-5.3 #16
See http://build.squid-cache.org/job/3.2-amd64-CentOS-5.3/16/changes
