[RFC] Translate and Unless-Modified-Since headers
Both of these are non-standard headers created by microsoft. These are both weird ones. We seem to need them, but only because they need to be stripped away in certain circumstances. The Translate: header is the trickiest. After reading the docs it appears we should be always stripping it away for security. It's entire purpose is to perform code disclosure 'attacks' on targeted dynamic sites. With perhapse a fast-ACL to allow admins to use it and control the requests using it when they really need to. Pending any objections I'll add as registered headers in 3.0 and the above handling for Translate in 3.1. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15 Current Beta Squid 3.1.0.7
Re: [squid-users] Error making squid-3.1.0.7-20090412 on Mac OS X 10.4
vollkom...@gmx.net wrote:
Here's what I did and the outcome, with squid-3.HEAD-20090511:
patch -p0 b9683.patch
vi src/asn.cc
/* template cbdata_type CbDataListint::CBDATA_CbDataList;
*/
Then 2) 3).
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I../..
-I../../include -I../../src -I../../include -I/usr/include/libxml2 -Werror
-Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -c -o Asn.lo Asn.cc
g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../src -I../../include
-I/usr/include/libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments
-g -O2 -c Asn.cc -fno-common -DPIC -o .libs/Asn.o
Asn.cc:44: error: expected unqualified-id before 'template'
make[3]: *** [Asn.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
Original-Nachricht
I wonder.
Lets experiment then. If you would please:
1. comment out the annoying line:
template cbdata_type CbDataListint::CBDATA_CbDataList;
2. add this to src/asn.cc:
class FubarA {
public:
char a;
}
template cbdata_type CbDataListFubarA::CBDATA_CbDataList;
3. add this to acl/Asn.cc:
class FubarB {
public:
char b;
}
template cbdata_type CbDataListFubarB::CBDATA_CbDataList;
4. rebuild and see what happens...
Have been working on this a little. Seems asn.cc and Asn.cc were not
both needed anyway, so merging and killing one.
The clash is looking more like a clash between pure int and a type which
has been typedef'd from int. int vs ssl_error_t.
I find it very strange that the compiler is doing that.
The next snapshot should be 3.HEAD-20090519. Can you please test that
when its bundled to see if all this fixing has had any effect on your
latest problem.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15
Current Beta Squid 3.1.0.7
Re: [RFC] Translate and Unless-Modified-Since headers
On Mon, May 18, 2009 at 1:05 PM, Amos Jeffries squ...@treenet.co.nz wrote: Both of these are non-standard headers created by microsoft. These are both weird ones. We seem to need them, but only because they need to be stripped away in certain circumstances. The Translate: header is the trickiest. After reading the docs it appears we should be always stripping it away for security. It's entire purpose is to perform code disclosure 'attacks' on targeted dynamic sites. With perhapse a fast-ACL to allow admins to use it and control the requests using it when they really need to. Pending any objections I'll add as registered headers in 3.0 and the above handling for Translate in 3.1. Do you have any reference document to point me to? +1 to registering them, but I'd like to understand a bit more before default-stripping. -- /kinkie
Re: [RFC] Translate and Unless-Modified-Since headers
Kinkie wrote: On Mon, May 18, 2009 at 1:05 PM, Amos Jeffries squ...@treenet.co.nz wrote: Both of these are non-standard headers created by microsoft. These are both weird ones. We seem to need them, but only because they need to be stripped away in certain circumstances. The Translate: header is the trickiest. After reading the docs it appears we should be always stripping it away for security. It's entire purpose is to perform code disclosure 'attacks' on targeted dynamic sites. With perhapse a fast-ACL to allow admins to use it and control the requests using it when they really need to. Pending any objections I'll add as registered headers in 3.0 and the above handling for Translate in 3.1. Do you have any reference document to point me to? +1 to registering them, but I'd like to understand a bit more before default-stripping. http://trac2.assembla.com/Nikto_2/ticket/21 http://msdn.microsoft.com/en-us/library/cc250063(PROT.10).aspx Looking a lot closer than the doc page it seems to be buried in WebDAV. I get hints that it may be needed. Which screws any hope of closing that hole in the general external case. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15 Current Beta Squid 3.1.0.7
Re: [RFC] Translate and Unless-Modified-Since headers
Sorry to be blunt, but shouldn't these sites be securing themselves? Having Squid strip this header hardly closes any significant attack vectors off... and doing so creates yet another special case for people to work around. -1 on Translate (default strip; registering it, I suppose, although it's a vendor-specific extension header that they haven't bothered to register; I'd rather the focus be on those headers that people have actually tried to do the right thing for -- especially when they have *not* said they'll license patents for this specification). WRT Unless-Modified-Since -- IIRC this is a very old, pre-2068 version of If-Range. /me looks around... see: http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15847a-s96/web/draft-luotonen-http-url-byterange-02.txt What's the issue with it? Amusingly, MSFT thinks it's a response header: http://msdn.microsoft.com/en-us/library/aa917918.aspx On 18/05/2009, at 9:05 PM, Amos Jeffries wrote: Both of these are non-standard headers created by microsoft. These are both weird ones. We seem to need them, but only because they need to be stripped away in certain circumstances. The Translate: header is the trickiest. After reading the docs it appears we should be always stripping it away for security. It's entire purpose is to perform code disclosure 'attacks' on targeted dynamic sites. With perhapse a fast-ACL to allow admins to use it and control the requests using it when they really need to. Pending any objections I'll add as registered headers in 3.0 and the above handling for Translate in 3.1. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15 Current Beta Squid 3.1.0.7 -- Mark Nottingham m...@yahoo-inc.com
Re: [RFC] Translate and Unless-Modified-Since headers
Mark Nottingham wrote: Sorry to be blunt, but shouldn't these sites be securing themselves? Having Squid strip this header hardly closes any significant attack vectors off... and doing so creates yet another special case for people to work around. -1 on Translate (default strip; registering it, I suppose, although it's a vendor-specific extension header that they haven't bothered to register; I'd rather the focus be on those headers that people have actually tried to do the right thing for -- especially when they have *not* said they'll license patents for this specification). Well, thats 2:1 against any special treatment. WRT Unless-Modified-Since -- IIRC this is a very old, pre-2068 version of If-Range. /me looks around... see: http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15847a-s96/web/draft-luotonen-http-url-byterange-02.txt Range? yeesh, truly mixed bag of garbage there then. What's the issue with it? Amusingly, MSFT thinks it's a response header: http://msdn.microsoft.com/en-us/library/aa917918.aspx :) The 'issue' with them is that at least one brand of commercial box views them as a security hazard and rejects requests from clients using them outright. Fair enough IMO. but ... something involved with PDF somehow still insists on sending them. http://www.mail-archive.com/squid-us...@squid-cache.org/msg63980.html Amos On 18/05/2009, at 9:05 PM, Amos Jeffries wrote: Both of these are non-standard headers created by microsoft. These are both weird ones. We seem to need them, but only because they need to be stripped away in certain circumstances. The Translate: header is the trickiest. After reading the docs it appears we should be always stripping it away for security. It's entire purpose is to perform code disclosure 'attacks' on targeted dynamic sites. With perhapse a fast-ACL to allow admins to use it and control the requests using it when they really need to. Pending any objections I'll add as registered headers in 3.0 and the above handling for Translate in 3.1. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15 Current Beta Squid 3.1.0.7 -- Mark Nottingham m...@yahoo-inc.com -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15 Current Beta Squid 3.1.0.7
Re: [squid-users] Error making squid-3.1.0.7-20090412 on Mac OS X 10.4
Thanks. Since I didn't want to wait for 3.HEAD-20090519, I simply applied your patch to the 3.HEAD-20090518 source. Here's the output: patch -p0 b9686.patch ... g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../src -I../../include -I/usr/include/libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -c StringData.cc -fno-common -DPIC -o .libs/StringData.o g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../src -I../../include -I/usr/include/libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -c StringData.cc -o StringData.o /dev/null 21 /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../src -I../../include -I/usr/include/libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -c -o Time.lo Time.cc g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../src -I../../include -I/usr/include/libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -c Time.cc -fno-common -DPIC -o .libs/Time.o g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../src -I../../include -I/usr/include/libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -c Time.cc -o Time.o /dev/null 21 /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../src -I../../include -I/usr/include/libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -c -o TimeData.lo TimeData.cc g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../src -I../../include -I/usr/include/libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -c TimeData.cc -fno-common -DPIC -o .libs/TimeData.o g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../src -I../../include -I/usr/include/libxml2 -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 -c TimeData.cc -o TimeData.o /dev/null 21 make[3]: *** No rule to make target `Asn.cc', needed by `Asn.lo'. Stop. make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 Original-Nachricht Have been working on this a little. Seems asn.cc and Asn.cc were not both needed anyway, so merging and killing one. The clash is looking more like a clash between pure int and a type which has been typedef'd from int. int vs ssl_error_t. I find it very strange that the compiler is doing that. The next snapshot should be 3.HEAD-20090519. Can you please test that when its bundled to see if all this fixing has had any effect on your latest problem. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15 Current Beta Squid 3.1.0.7 -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
Re: [squid-users] Error making squid-3.1.0.7-20090412 on Mac OS X 10.4
Thanks. Since I didn't want to wait for 3.HEAD-20090519, I simply applied your patch to the 3.HEAD-20090518 source. Here's the output: We do have to wait unfortunately. The autotools bootstrapping is not part of the patches. The snapshot is out now. Amos
Re: [squid-users] Error making squid-3.1.0.7-20090412 on Mac OS X 10.4
Please find below the output of make -w -d against the 3.HEAD-20090519 source. ... rm -f .libs/squid.nm .libs/squid.nmS .libs/squid.nmT creating .libs/squidS.c (cd .libs gcc -g -O2 -c -fno-builtin squidS.c) rm -f .libs/squidS.c .libs/squid.nm .libs/squid.nmS .libs/squid.nmT g++ -Werror -Wall -Wpointer-arith -Wwrite-strings -Wcomments -g -O2 .libs/squidS.o -g -o squid AclRegs.o AuthReg.o access_log.o AsyncEngine.o cache_cf.o ProtoPort.o CacheDigest.o cache_manager.o carp.o cbdata.o ChunkedCodingParser.o client_db.o client_side.o client_side_reply.o client_side_request.o BodyPipe.o clientStream.o CompletionDispatcher.o comm_select.o comm_select_win32.o comm_poll.o comm_epoll.o comm_kqueue.o ConfigOption.o ConfigParser.o debug.o delay_pools.o DelayId.o DelayBucket.o DelayConfig.o DelayPool.o DelaySpec.o DelayTagged.o DelayUser.o DelayVector.o NullDelayId.o disk.o DiskIO/DiskIOModule.o DiskIO/ReadRequest.o DiskIO/WriteRequest.o dlink.o dns_internal.o errorpage.o ETag.o event.o EventLoop.o external_acl.o ExternalACLEntry.o fd.o fde.o filemap.o forward.o fqdncache.o ftp.o gopher.o helper.o htcp.o http.o HttpStatusLine.o HttpHdrCc.o HttpHdrRange.o HttpHdrSc.o HttpHdrScTarget.o HttpHdrContRange.o HttpHeader.o HttpHeaderTools.o HttpBody.o HttpMsg.o HttpReply.o HttpRequest.o HttpRequestMethod.o icp_v2.o icp_v3.o int.o internal.o ipc.o ipcache.o list.o logfile.o main.o mem.o mem_node.o MemBuf.o MemObject.o mime.o multicast.o neighbors.o Packer.o Parsing.o pconn.o peer_digest.o peer_select.o peer_sourcehash.o peer_userhash.o redirect.o referer.o refresh.o RemovalPolicy.o send-announce.o snmp_core.o snmp_agent.o SquidNew.o ssl_support.o stat.o StatHist.o String.o stmem.o store.o StoreFileSystem.o store_io.o StoreIOState.o store_client.o store_digest.o store_dir.o store_key_md5.o store_log.o store_rebuild.o store_swapin.o store_swapmeta.o store_swapout.o StoreMeta.o StoreMetaMD5.o StoreMetaSTD.o StoreMetaSTDLFS.o StoreMetaUnpacker.o StoreMetaURL.o StoreMetaVary.o StoreSwapLogData.o Server.o SwapDir.o time.o tools.o tunnel.o unlinkd.o url.o URLScheme.o urn.o useragent.o wccp.o wccp2.o whois.o wordlist.o LoadableModule.o LoadableModules.o DiskIO/DiskIOModules_gen.o repl_modules.o globals.o string_arrays.o DiskIO/Blocking/BlockingDiskIOModule.o -Wl,-bind_at_load ./.libs/libsquid.a auth/.libs/libacls.a acl/.libs/libacls.a acl/.libs/libstate.a auth/.libs/libauth.a acl/.libs/libapi.a base/.libs/libbase.a ip/.libs/libip.a fs/.libs/libfs.a icmp/.libs/libicmp.a icmp/.libs/libicmp-core.a -L/Users/raymont/squid-3.HEAD-20090519/lib repl/libheap.a repl/liblru.a libBlocking.a ../snmplib/libsnmp.a adaptation/.libs/libadaptation.a -lssl -lcrypto -lmiscutil -lm -lresolv ../lib/libLtdl/.libs/libltdlc.a -ldl /usr/libexec/gcc/i686-apple-darwin8/4.2.1/ld: multiple definitions of symbol CbDataListint::CBDATA_CbDataList acl/.libs/libacls.a(Asn.o) definition of CbDataListint::CBDATA_CbDataList in section (__DATA,__data) acl/.libs/libacls.a(SslErrorData.o) definition of CbDataListint::CBDATA_CbDataList in section (__DATA,__data) collect2: ld returned 1 exit status rm -f .libs/squidS.o Got a SIGCHLD; 1 unreaped children. Reaping losing child 0x00350220 PID 360 make[3]: *** [squid] Error 1 Removing child 0x00350220 PID 360 from chain. Original-Nachricht We do have to wait unfortunately. The autotools bootstrapping is not part of the patches. The snapshot is out now. Amos -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
Is it really necessary for fatal() to dump core?
tools.c:fatal() dumps core because it calls abort. Considering that the core can be quite large (esp. on a 64bit system), and that there's fatal_dump() as well if you really want one, can we just make fatal() exit(1) instead of abort()ing? Cheers, -- Mark Nottingham m...@yahoo-inc.com
Re: Is it really necessary for fatal() to dump core?
just make that behaviour configurable?
core_on_fatal {on|off}
Adrian
2009/5/19 Mark Nottingham m...@yahoo-inc.com:
tools.c:fatal() dumps core because it calls abort.
Considering that the core can be quite large (esp. on a 64bit system), and
that there's fatal_dump() as well if you really want one, can we just make
fatal() exit(1) instead of abort()ing?
Cheers,
--
Mark Nottingham m...@yahoo-inc.com
