Opened 13 years ago

Closed 11 years ago

#2941 closed defect (fixed)

Mapfile parser could leak sensitive data

Reported by: sdlime Owned by: sdlime
Priority: high Milestone: 6.0 release
Component: Documentation - MapServer Version: unspecified
Severity: normal Keywords:
Cc: jmckenna, dmorissette, mko


The MapServer mapfile parser could leak sensitive data by opening a arbitrary file and erroring out. Problem is that the error will output the offending token as part of an error message. It's possible then for someone to create a symlink to a sensitive file with the link named and the CGI (if running as a privileged user) could return a portion (the first token) of that file.

An initial solution is to force the mapfile parser to look for the MAP token to start a file and if not present to issue a "this doesn't look like a mapfile" error.

Note this is not a complete fix. It's possible that in the future sensitive data files starting with the token MAP could be defined. We'll look for ways to tighten this up in an upcoming release (6.0).

Change History (15)

comment:1 Changed 13 years ago by sdlime

Status: newassigned

comment:2 Changed 13 years ago by sdlime

Priority: normalhigh

comment:3 Changed 13 years ago by sdlime

Referencing CVE-2009-0842...

comment:4 Changed 13 years ago by sdlime

Symbolsets also don't require their first token and could leak as well although this would require direct manipulation of an existing mapfile or creation of a new bogus one. Need to require that token. (committed in 5.2 branch, r8807).

comment:5 Changed 13 years ago by sdlime

Milestone: 5.2.2 release5.4 release

Note that this is fixed in 5.2 in r8805. Changing milestone to 5.4.


comment:6 Changed 13 years ago by jmckenna

Cc: jmckenna added

comment:7 Changed 13 years ago by dmorissette

Cc: dmorissette added

comment:8 Changed 13 years ago by sdlime

For completeness, fixed in r8823 for 4.10 branch.


comment:9 Changed 13 years ago by sdlime

Milestone: 5.4 release6.0 release

Fixed in 5.4 branch in r8854, moving to 6.0/trunk.


comment:10 Changed 13 years ago by sdlime

Component: MapServer C LibraryMapServer Documentation

Fixed in trunk a while ago, moving to docs component...


comment:11 Changed 12 years ago by aboudreault

Backported to branch-5-0 in r9199

comment:12 Changed 12 years ago by mko

Cc: mko added

MapServer does also leak environment variables as msEvalRegex() error message when using &map=ENV_VAR in the query string. Either msEvalRegex should not return any content to the client or - at least - do a getenv() only if MS_MAP_NO_PATH is set and otherwise msEvalRegex(ENV_VAR) in stead of msEvalRegex( getenv(ENV_VAR) ).

comment:13 Changed 12 years ago by sdlime

Dan: Since there official 5.6 release hasn't gone out, this could be fixed ahead of the final. I'd vote for changing msEvalRegex to not echo the string being checked.


comment:14 Changed 12 years ago by dmorissette

You're right, good catch! I have implemented a fix in trunk r9622 and branch-5-6 r9623 to not echo the value being checked in msEvalRegex(), and also improved the error messages in places that called msEvalRegex() to make it easier for users to figure what's going on.

The 5.6.0 release tag has been re-done in SVN, and the source re-packaged to include that fix.

comment:15 Changed 11 years ago by sdlime

Resolution: fixed
Status: assignedclosed

This ones done, closing...


Note: See TracTickets for help on using tickets.