mapserver: multiple vulnerabilities

Debian Bug report logs - #523027
mapserver: multiple vulnerabilities

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Michael S. Gilbert" <michael.s.gilbert@gmail.com>

To: submit@bugs.debian.org

Subject: mapserver: multiple vulnerabilities

Date: Tue, 7 Apr 2009 18:50:52 -0400

Package: mapserver
Severity: important
Tags: security

Hi,
the following CVE (Common Vulnerabilities & Exposures) ids were
published for mapserver.

CVE-2009-0839[0]:
| Stack-based buffer overflow in mapserv.c in mapserv in MapServer 4.x
| before 4.10.4 and 5.x before 5.2.2, when the server has a map with a
| long IMAGEPATH or NAME attribute, allows remote attackers to execute
| arbitrary code via a crafted id parameter in a query action.

CVE-2009-0840[1]:
| Heap-based buffer underflow in the readPostBody function in cgiutil.c
| in mapserv in MapServer 4.x before 4.10.4 and 5.x before 5.2.2 allows
| remote attackers to have an unknown impact via a negative value in the
| Content-Length HTTP header.

CVE-2009-0841[2]:
| Directory traversal vulnerability in mapserv.c in mapserv in MapServer
| 4.x before 4.10.4 and 5.x before 5.2.2, when running on Windows with
| Cygwin, allows remote attackers to create arbitrary files via a ..
| (dot dot) in the id parameter.

CVE-2009-0842[3]:
| mapserv in MapServer 4.x before 4.10.4 and 5.x before 5.2.2 allows
| remote attackers to read arbitrary invalid .map files via a full
| pathname in the map parameter, which triggers the display of partial
| file contents within an error message, as demonstrated by a
| /tmp/sekrut.map symlink.

CVE-2009-0843[4]:
| The msLoadQuery function in mapserv in MapServer 4.x before 4.10.4 and
| 5.x before 5.2.2 allows remote attackers to determine the existence of
| arbitrary files via a full pathname in the queryfile parameter, which
| triggers different error messages depending on whether this pathname
| exists.

CVE-2009-1176[5]:
| mapserv.c in mapserv in MapServer 4.x before 4.10.4 and 5.x before
| 5.2.2 does not ensure that the string holding the id parameter ends in
| a '\0' character, which allows remote attackers to conduct
| buffer-overflow attacks or have unspecified other impact via a long id
| parameter in a query action.

CVE-2009-1177[6]:
| Multiple stack-based buffer overflows in maptemplate.c in mapserv in
| MapServer 4.x before 4.10.4 and 5.x before 5.2.2 have unknown impact
| and remote attack vectors.

Please coordinate with the security team to prepare packages for the
stable releases.

If you fix the vulnerabilities please also make sure to include the
CVE ids in your changelog entry.

For further information see:

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0839
    http://security-tracker.debian.net/tracker/CVE-2009-0839
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0840
    http://security-tracker.debian.net/tracker/CVE-2009-0840
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0841
    http://security-tracker.debian.net/tracker/CVE-2009-0841
[3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0842
    http://security-tracker.debian.net/tracker/CVE-2009-0842
[4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0843
    http://security-tracker.debian.net/tracker/CVE-2009-0843
[5] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1176
    http://security-tracker.debian.net/tracker/CVE-2009-1176
[6] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1177
    http://security-tracker.debian.net/tracker/CVE-2009-1177

Message #14 received at 523027@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <oss-security+ml@ngolde.de>

To: oss-security@lists.openwall.com

Cc: aboudreault@mapgears.com, coley@mitre.org, 523027@bugs.debian.org, warmerdam@pobox.com

Subject: incorrect upstream fix for CVE-2009-0840 (mapserver)

Date: Mon, 22 Jun 2009 15:24:35 +0200

[Message part 1 (text/plain, inline)]

Hi,
from the CVE description:
| Heap-based buffer underflow in the readPostBody function in cgiutil.c in
| mapserv in MapServer 4.x before 4.10.4 and 5.x before 5.2.2 allows remote
| attackers to have an unknown impact via a negative value in the Content-Length
| HTTP header.

The affected code is in cgiutil.c:
41 static char *readPostBody( cgiRequestObj *request ) 
42 {
43   char *data; 
44   int data_max, data_len, chunk_size;
45 
46   msIO_needBinaryStdin();
47 
48   /* -------------------------------------------------------------------- */
49   /*      If the length is provided, read in one gulp.                    */
50   /* -------------------------------------------------------------------- */
51   if( getenv("CONTENT_LENGTH") != NULL ) {
52     data_max = atoi(getenv("CONTENT_LENGTH"));
53     data = (char *) malloc(data_max+1);
54     if( data == NULL ) {
55       msIO_printf("Content-type: text/html%c%c",10,10);
56       msIO_printf("malloc() failed, Content-Length: %d unreasonably large?\n", data_max );
57       exit( 1 );
58     }
59 
60     if( (int) msIO_fread(data, 1, data_max, stdin) < data_max ) {

There is obviously a problem in case the content-length is negative.
The following is the upstream patch which was used to "fix" this issue:
 static char *readPostBody( cgiRequestObj *request ) 
 {
   char *data; 
-  int data_max, data_len, chunk_size;
+  unsigned int data_max, data_len; 
+  int chunk_size;


Unfortunately this doesn't fix the issue and I wonder why people always think
changing signed types to unsigned will fix such errors.
If I pass 0xffffffff as the content-length according to type conversion rules
in C atoi() will convert this to -1 which is again converted to 0xffff when
assigning it to an unsigned int. data_max+1 in line 53 will then overflow and
malloc is called with a parameter of 0. This causes malloc to allocated the smallest
possible chunk but it will _not_ return NULL (well, implementation defined). So it
is still possible to perform a heap-based buffer overflow after the upstream
fix.

I'm not sure if this should get a new CVE id but the versions in the CVE id
description should be adjusted and the upstream patch revised.

Cheers
Nico
P.S. @Alan, this is also the reason I have to reject your packages in our
security queue again.



-- 
Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.

[Message part 2 (application/pgp-signature, inline)]

Message #19 received at 523027@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <oss-security+ml@ngolde.de>

To: oss-security@lists.openwall.com

Cc: aboudreault@mapgears.com, coley@mitre.org, 523027@bugs.debian.org, warmerdam@pobox.com

Subject: Re: [oss-security] incorrect upstream fix for CVE-2009-0840 (mapserver)

Date: Mon, 22 Jun 2009 15:46:28 +0200

[Message part 1 (text/plain, inline)]

Hi,
* Nico Golde <oss-security+ml@ngolde.de> [2009-06-22 15:45]:
[...] 
> Unfortunately this doesn't fix the issue and I wonder why people always think
> changing signed types to unsigned will fix such errors.
> If I pass 0xffffffff as the content-length according to type conversion rules
> in C atoi() will convert this to -1 which is again converted to 0xffff when
                                                            0xffffffff^^
-- 
Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.

[Message part 2 (application/pgp-signature, inline)]

Message #24 received at 523027@bugs.debian.org (full text, mbox, reply):

From: Alan Boudreault <aboudreault@mapgears.com>

To: Nico Golde <oss-security+ml@ngolde.de>

Cc: oss-security@lists.openwall.com, coley@mitre.org, 523027@bugs.debian.org

Subject: Re: incorrect upstream fix for CVE-2009-0840 (mapserver)

Date: Thu, 25 Jun 2009 11:12:52 -0400

Hi

I've reported that to the devs. They should fix that as soon as possible.

ALan

On June 22, 2009 09:24:35 am Nico Golde wrote:
> Hi,
>
> from the CVE description:
> | Heap-based buffer underflow in the readPostBody function in cgiutil.c in
> | mapserv in MapServer 4.x before 4.10.4 and 5.x before 5.2.2 allows remote
> | attackers to have an unknown impact via a negative value in the
> | Content-Length HTTP header.
>
> The affected code is in cgiutil.c:
> 41 static char *readPostBody( cgiRequestObj *request )
> 42 {
> 43   char *data;
> 44   int data_max, data_len, chunk_size;
> 45
> 46   msIO_needBinaryStdin();
> 47
> 48   /*
> -------------------------------------------------------------------- */ 49 
>  /*      If the length is provided, read in one gulp.                    */
> 50   /*
> -------------------------------------------------------------------- */ 51 
>  if( getenv("CONTENT_LENGTH") != NULL ) {
> 52     data_max = atoi(getenv("CONTENT_LENGTH"));
> 53     data = (char *) malloc(data_max+1);
> 54     if( data == NULL ) {
> 55       msIO_printf("Content-type: text/html%c%c",10,10);
> 56       msIO_printf("malloc() failed, Content-Length: %d unreasonably
> large?\n", data_max ); 57       exit( 1 );
> 58     }
> 59
> 60     if( (int) msIO_fread(data, 1, data_max, stdin) < data_max ) {
>
> There is obviously a problem in case the content-length is negative.
> The following is the upstream patch which was used to "fix" this issue:
>  static char *readPostBody( cgiRequestObj *request )
>  {
>    char *data;
> -  int data_max, data_len, chunk_size;
> +  unsigned int data_max, data_len;
> +  int chunk_size;
>
>
> Unfortunately this doesn't fix the issue and I wonder why people always
> think changing signed types to unsigned will fix such errors.
> If I pass 0xffffffff as the content-length according to type conversion
> rules in C atoi() will convert this to -1 which is again converted to
> 0xffff when assigning it to an unsigned int. data_max+1 in line 53 will
> then overflow and malloc is called with a parameter of 0. This causes
> malloc to allocated the smallest possible chunk but it will _not_ return
> NULL (well, implementation defined). So it is still possible to perform a
> heap-based buffer overflow after the upstream fix.
>
> I'm not sure if this should get a new CVE id but the versions in the CVE id
> description should be adjusted and the upstream patch revised.
>
> Cheers
> Nico
> P.S. @Alan, this is also the reason I have to reject your packages in our
> security queue again.

-- 
Alan Boudreault
Mapgears
http://www.mapgears.com

Message #29 received at 523027@bugs.debian.org (full text, mbox, reply):

From: "Steven M. Christey" <coley@linus.mitre.org>

To: oss-security@lists.openwall.com

Cc: aboudreault@mapgears.com, coley@mitre.org, 523027@bugs.debian.org, warmerdam@pobox.com

Subject: Re: [oss-security] incorrect upstream fix for CVE-2009-0840 (mapserver)

Date: Wed, 1 Jul 2009 07:32:52 -0400 (EDT)

On Mon, 22 Jun 2009, Nico Golde wrote:

> I'm not sure if this should get a new CVE id but the versions in the CVE id
> description should be adjusted and the upstream patch revised.

This looks like even though there was a source code modification, the
previous issue was not fixed at all.  That is, any attack that would have
worked before the fix, will still work after the fix.

However, Fedora FEDORA-2009-3383 at least claims a fix for CVE-2009-0840,
so a new CVE is probably in order to "signal" to admins that they have
another issue to handle.

Use CVE-2009-2281 for the "new" issue.  What versions are affected by
this?

- Steve

Message #34 received at 523027@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <oss-security+ml@ngolde.de>

To: oss-security@lists.openwall.com

Cc: aboudreault@mapgears.com, coley@mitre.org, 523027@bugs.debian.org, warmerdam@pobox.com

Subject: Re: [oss-security] incorrect upstream fix for CVE-2009-0840 (mapserver)

Date: Wed, 1 Jul 2009 19:41:05 +0200

[Message part 1 (text/plain, inline)]

Hi,
* Steven M. Christey <coley@linus.mitre.org> [2009-07-01 13:43]:
> On Mon, 22 Jun 2009, Nico Golde wrote:
> 
> > I'm not sure if this should get a new CVE id but the versions in the CVE id
> > description should be adjusted and the upstream patch revised.
> 
> This looks like even though there was a source code modification, the
> previous issue was not fixed at all.  That is, any attack that would have
> worked before the fix, will still work after the fix.
> 
> However, Fedora FEDORA-2009-3383 at least claims a fix for CVE-2009-0840,
> so a new CVE is probably in order to "signal" to admins that they have
> another issue to handle.
> 
> Use CVE-2009-2281 for the "new" issue.  What versions are affected by
> this?

Should be every currently available release, I'm currently 
working with upstream on a better fix.

Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.

[Message part 2 (application/pgp-signature, inline)]

Message #39 received at 523027-done@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <nion@debian.org>

To: 523027-done@bugs.debian.org

Subject: closing

Date: Wed, 1 Jul 2009 19:43:20 +0200

[Message part 1 (text/plain, inline)]

Version: 5.2.2-1

-- 
Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.

[Message part 2 (application/pgp-signature, inline)]

Message #44 received at 523027@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <nion@debian.org>

To: 523027@bugs.debian.org

Subject: Re: mapserver: multiple vulnerabilities

Date: Wed, 1 Jul 2009 19:44:32 +0200

[Message part 1 (text/plain, inline)]

Hi,
as the incomplete fix got a new CVE id I closed this bug and 
opened a new one for the incomplete fix.

Cheers
Nico

-- 
Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.

[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.