Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CEA2972DB for ; Fri, 2 Sep 2011 07:40:25 +0000 (UTC) Received: (qmail 94363 invoked by uid 500); 2 Sep 2011 07:40:23 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 93663 invoked by uid 500); 2 Sep 2011 07:40:16 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 93640 invoked by uid 99); 2 Sep 2011 07:40:14 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Sep 2011 07:40:14 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [193.227.124.2] (HELO mx01.bfk.de) (193.227.124.2) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Sep 2011 07:40:09 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QzOLr-00071P-B5; Fri, 02 Sep 2011 07:39:47 +0000 Received: by bfk.de with local id 1QzOLr-0003yk-6Q; Fri, 02 Sep 2011 07:39:47 +0000 From: Florian Weimer To: Reindl Harald Cc: dev@httpd.apache.org Subject: Re: CVE-2003-1418 - still affects apache 2 current References: <20110901123911.GE13838@suse.de> <20110901153057.7b866160@baldur> <20110901143624.GI13838@suse.de> <20110901155528.01644b98@baldur> <20110901150947.GL13838@suse.de> <4E5FA1FC.70907@thelounge.net> Date: Fri, 02 Sep 2011 07:39:47 +0000 In-Reply-To: <4E5FA1FC.70907@thelounge.net> (Reindl Harald's message of "Thu, 01 Sep 2011 17:17:16 +0200") Message-ID: <82bov38kak.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable * Reindl Harald: > mtime -> well, is directly in the header -> Last-Modified > size -> well, directly in the header -> Content-Length > inode -> well, where is there any security implication? I guess you could use it to form an NFS handle, and use that to bypass intended access restrictions. But that's the fault of NFS, and systems which do not use cryptographic NFS handles probably use non-random or 32-bit inodes, which are open to guessing anyway. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99