You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marcus Meissner <me...@suse.de> on 2011/09/01 14:39:11 UTC
CVE-2003-1418 - still affects apache 2 current
Hi,
CVE-2003-1418, a minor security issue, is still affecting the current codebase.
someone opened a tracker bug a year ago without feedback:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49623
Do you have a statement?
The Qualys security scanner detects and reports this issue and continues
to confuse Apache users :/
The OpenBSD patch referenced adds some hashing and backing store
for the etags.
Ciao, Marcus
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Daniel Ruggeri <DR...@primary.net>.
On 9/5/2011 8:21 AM, Joe Orton wrote:
> => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
>
> Is there consensus to treat the issues described there as not being
> security-sensitive? If so we can probably put tihs on the vulnerability
> list is as a not-a-bug as an "official statement".
>
> Regards, Joe
If we are taking score, count me as a +1.
--
--
Daniel Ruggeri
Re: CVE-2003-1418 - still affects apache 2 current
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/5/2011 8:21 AM, Joe Orton wrote:
>
> => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
>
> Is there consensus to treat the issues described there as not being
> security-sensitive? If so we can probably put tihs on the vulnerability
> list is as a not-a-bug as an "official statement".
+1 to treat this as "not a vulnerability" on the vulnerability page. It
would help to serve as an FAQ.
RE: CVE-2003-1418 - still affects apache 2 current
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Joe Orton [mailto:jorton@redhat.com]
> Sent: Montag, 5. September 2011 15:21
> To: dev@httpd.apache.org
> Cc: thoger@redhat.com
> Subject: Re: CVE-2003-1418 - still affects apache 2 current
>
> On Thu, Sep 01, 2011 at 06:27:35PM +0200, "Plüm, Rüdiger,
> VF-Group" wrote:
> > Can't find the discussion either, but I remember that it
> was not seen
> > as a security issue. For those still concerned about this,
> the advice
> > was as you said "FileETag -INode". So IMHO no need for a patch here
> > except for documentation and default config
>
> Ah - I found the discussion, it was on security@.
>
> Tomas (CC'ed) pointed out that CVE-2003-1418 also covers the
> fact that
> the byterange filter leaks pids. I don't think that is worth
> treating
> as a vulnerability, either; but I changed it in r1165268
> anyway - that
> is still leaking some MPM-specific data, but it doesn't seem
> worth going
> to any more effort.
>
> => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
>
> Is there consensus to treat the issues described there as not being
> security-sensitive? If so we can probably put tihs on the
> vulnerability
> list is as a not-a-bug as an "official statement".
>
+1
Regards
Rüdiger
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Sep 01, 2011 at 06:27:35PM +0200, "Plüm, Rüdiger, VF-Group" wrote:
> Can't find the discussion either, but I remember that it was not seen
> as a security issue. For those still concerned about this, the advice
> was as you said "FileETag -INode". So IMHO no need for a patch here
> except for documentation and default config
Ah - I found the discussion, it was on security@.
Tomas (CC'ed) pointed out that CVE-2003-1418 also covers the fact that
the byterange filter leaks pids. I don't think that is worth treating
as a vulnerability, either; but I changed it in r1165268 anyway - that
is still leaking some MPM-specific data, but it doesn't seem worth going
to any more effort.
=> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
Is there consensus to treat the issues described there as not being
security-sensitive? If so we can probably put tihs on the vulnerability
list is as a not-a-bug as an "official statement".
Regards, Joe
RE: CVE-2003-1418 - still affects apache 2 current
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Joe Orton [mailto:jorton@redhat.com]
> Sent: Donnerstag, 1. September 2011 16:46
> To: Marcus Meissner
> Cc: dev@httpd.apache.org
> Subject: Re: CVE-2003-1418 - still affects apache 2 current
>
> On Thu, Sep 01, 2011 at 02:39:11PM +0200, Marcus Meissner wrote:
> > Hi,
> >
> > CVE-2003-1418, a minor security issue, is still affecting
> the current codebase.
> >
> > someone opened a tracker bug a year ago without feedback:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49623
> >
> > Do you have a statement?
>
> Use "FileETag -INode" if you care about leaking inode numbers.
>
> I think there was consensus that the default should be
> changed to that,
> but I can't find the discussion.
Can't find the discussion either, but I remember that it was not seen as a security issue.
For those still concerned about this, the advice was as you said "FileETag -INode".
So IMHO no need for a patch here except for documentation and default config
Regards
Rüdiger
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Sep 01, 2011 at 02:39:11PM +0200, Marcus Meissner wrote:
> Hi,
>
> CVE-2003-1418, a minor security issue, is still affecting the current codebase.
>
> someone opened a tracker bug a year ago without feedback:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49623
>
> Do you have a statement?
Use "FileETag -INode" if you care about leaking inode numbers.
I think there was consensus that the default should be changed to that,
but I can't find the discussion.
Regards, Joe
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Nick Kew <ni...@webthing.com>.
On 2 Sep 2011, at 08:49, Reindl Harald wrote:
>
>
> Am 02.09.2011 09:39, schrieb Florian Weimer:
>> * 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
>
> independend of the fact that i can guess it, it is really really not the problem
> of httpd if some stupid guy has nFS opened on the internet
Indeed, how many webservers this century are sharing stuff over NFS?
And, erm, if you have an ETag then you have web access!
But it's a technical violation of "need to know" principle. Potential
use of that information through NFS is just a demo-of-concept for
how such information might hypothetically be of use to an attacker.
As for vulnerability in real life, the information that is intentionally
and necessarily shared through HTTP is far more obviously useful
to an attacker. Want your attack bot to check whether it's found
${some-php-upload-exploit}? A test file will tell you its content-length
and last-modified for very good reasons!
--
Nick Kew
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Reindl Harald <h....@thelounge.net>.
Am 02.09.2011 09:39, schrieb Florian Weimer:
> * 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
independend of the fact that i can guess it, it is really really not the problem
of httpd if some stupid guy has nFS opened on the internet
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Florian Weimer <fw...@bfk.de>.
* 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.
--
Florian Weimer <fw...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Daniel Ruggeri <DR...@primary.net>.
On 9/1/2011 10:23 AM, Marcus Meissner wrote:
> On Thu, Sep 01, 2011 at 05:17:16PM +0200, Reindl Harald wrote:
> ..
>> 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 could not directly think of one.
>
> The reason is just that there is a CVE entry that checkers check for
> and every user of those checkers asks back from their vendors.
>
> A statement from Apache project that its not seen as security issue is
> probably sufficient.
>
> Ciao, Marcus
This is a sane response to the "problem". I've been asking why this is a
vulnerability for years and have yet to receive an answer... Maybe I
haven't asked the right people.
--
--
Daniel Ruggeri
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Marcus Meissner <me...@suse.de>.
On Thu, Sep 01, 2011 at 05:17:16PM +0200, Reindl Harald wrote:
..
> 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 could not directly think of one.
The reason is just that there is a CVE entry that checkers check for
and every user of those checkers asks back from their vendors.
A statement from Apache project that its not seen as security issue is
probably sufficient.
Ciao, Marcus
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Reindl Harald <h....@thelounge.net>.
Am 01.09.2011 17:09, schrieb Marcus Meissner:
> On Thu, Sep 01, 2011 at 03:55:28PM +0100, Nick Kew wrote:
>> On Thu, 1 Sep 2011 16:36:24 +0200
>> Marcus Meissner <me...@suse.de> wrote:
>>
>>
>>> This just md5s the inodenr, right?
>>>
>>> If yes, this is just obfuscation if you do not add some kind of random salt.
>>>
>>> (You can still just do
>>> for (i=0;i<...;i++) md5($i)
>>> and compare, including use of Rainbow Tables.)
>>
>> Erm, yeah. I guess brute force on 2^64 numbers is too easy,
>> even if the information leaked is of low value.
>>
>> Would you consider it strong enough if we aggregate
>> inode+size+mtime and make the etag an md5 hash of that?
>> Brings the benefit of a slightly shorter string with
>> a patch that's still simple.
>
> Both size and mtime are easily retrievable from remote,
> you need to add some stuff the attacker cannot derive ;)
where in the world is the security-problem here?
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?
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Marcus Meissner <me...@suse.de>.
On Thu, Sep 01, 2011 at 03:55:28PM +0100, Nick Kew wrote:
> On Thu, 1 Sep 2011 16:36:24 +0200
> Marcus Meissner <me...@suse.de> wrote:
>
>
> > This just md5s the inodenr, right?
> >
> > If yes, this is just obfuscation if you do not add some kind of random salt.
> >
> > (You can still just do
> > for (i=0;i<...;i++) md5($i)
> > and compare, including use of Rainbow Tables.)
>
> Erm, yeah. I guess brute force on 2^64 numbers is too easy,
> even if the information leaked is of low value.
>
> Would you consider it strong enough if we aggregate
> inode+size+mtime and make the etag an md5 hash of that?
> Brings the benefit of a slightly shorter string with
> a patch that's still simple.
Both size and mtime are easily retrievable from remote,
you need to add some stuff the attacker cannot derive ;)
Ciao, Marcus
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Nick Kew <ni...@webthing.com>.
On Thu, 1 Sep 2011 16:36:24 +0200
Marcus Meissner <me...@suse.de> wrote:
> This just md5s the inodenr, right?
>
> If yes, this is just obfuscation if you do not add some kind of random salt.
>
> (You can still just do
> for (i=0;i<...;i++) md5($i)
> and compare, including use of Rainbow Tables.)
Erm, yeah. I guess brute force on 2^64 numbers is too easy,
even if the information leaked is of low value.
Would you consider it strong enough if we aggregate
inode+size+mtime and make the etag an md5 hash of that?
Brings the benefit of a slightly shorter string with
a patch that's still simple.
--
Nick Kew
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Marcus Meissner <me...@suse.de>.
On Thu, Sep 01, 2011 at 03:30:57PM +0100, Nick Kew wrote:
> On Thu, 1 Sep 2011 14:39:11 +0200
> Marcus Meissner <me...@suse.de> wrote:
>
> > Hi,
> >
> > CVE-2003-1418, a minor security issue, is still affecting the current codebase.
> >
> > someone opened a tracker bug a year ago without feedback:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49623
>
> I've just hacked up a simple candidate patch. Review?
>
> (trunk patch - trivial offset when applied to 2.2.x)
This just md5s the inodenr, right?
If yes, this is just obfuscation if you do not add some kind of random salt.
(You can still just do
for (i=0;i<...;i++) md5($i)
and compare, including use of Rainbow Tables.)
Ciao, Marcus
> --
> Nick Kew
> Index: modules/http/http_etag.c
> ===================================================================
> --- modules/http/http_etag.c (revision 1164053)
> +++ modules/http/http_etag.c (working copy)
> @@ -26,6 +26,7 @@
> #include "http_core.h"
> #include "http_protocol.h" /* For index_of_response(). Grump. */
> #include "http_request.h"
> +#include "util_md5.h"
>
> /* Generate the human-readable hex representation of an apr_uint64_t
> * (basically a faster version of 'sprintf("%llx")')
> @@ -50,6 +51,13 @@
> *next++ = HEX_DIGITS[u & (apr_uint64_t)0xf];
> return next;
> }
> +static char *etag_uint64_to_md5(char *next, apr_uint64_t u, apr_pool_t *pool)
> +{
> + char *digest = ap_md5_binary(pool, (unsigned char*)&u, sizeof(u));
> + int len = strlen(digest);
> + memcpy(next, digest, len);
> + return next+len;
> +}
>
> #define ETAG_WEAK "W/"
> #define CHARS_PER_UINT64 (sizeof(apr_uint64_t) * 2)
> @@ -114,7 +122,7 @@
> * FileETag keywords.
> */
> etag = apr_palloc(r->pool, weak_len + sizeof("\"--\"") +
> - 3 * CHARS_PER_UINT64 + 1);
> + 2 * CHARS_PER_UINT64 + 2 * APR_MD5_DIGESTSIZE + 1);
> next = etag;
> if (weak) {
> while (*weak) {
> @@ -124,7 +132,7 @@
> *next++ = '"';
> bits_added = 0;
> if (etag_bits & ETAG_INODE) {
> - next = etag_uint64_to_hex(next, r->finfo.inode);
> + next = etag_uint64_to_md5(next, r->finfo.inode, r->pool);
> bits_added |= ETAG_INODE;
> }
> if (etag_bits & ETAG_SIZE) {
--
Working, but not speaking, for the following german company:
SUSE LINUX Products GmbH, HRB 16746 (AG Nuernberg)
Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Re: CVE-2003-1418 - still affects apache 2 current
Posted by Nick Kew <ni...@webthing.com>.
On Thu, 1 Sep 2011 14:39:11 +0200
Marcus Meissner <me...@suse.de> wrote:
> Hi,
>
> CVE-2003-1418, a minor security issue, is still affecting the current codebase.
>
> someone opened a tracker bug a year ago without feedback:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49623
I've just hacked up a simple candidate patch. Review?
(trunk patch - trivial offset when applied to 2.2.x)
--
Nick Kew