Opened 14 years ago

Closed 12 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

Description

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 something.map 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 by sdlime, 14 years ago

Status: newassigned

comment:2 by sdlime, 14 years ago

Priority: normalhigh

comment:3 by sdlime, 14 years ago

Referencing CVE-2009-0842...

comment:4 by sdlime, 14 years ago

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 by sdlime, 14 years ago

Milestone: 5.2.2 release5.4 release

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

Steve

comment:6 by jmckenna, 14 years ago

Cc: jmckenna added

comment:7 by dmorissette, 14 years ago

Cc: dmorissette added

comment:8 by sdlime, 14 years ago

For completeness, fixed in r8823 for 4.10 branch.

Steve

comment:9 by sdlime, 14 years ago

Milestone: 5.4 release6.0 release

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

Steve

comment:10 by sdlime, 14 years ago

Component: MapServer C LibraryMapServer Documentation

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

Steve

comment:11 by aboudreault, 13 years ago

Backported to branch-5-0 in r9199

comment:12 by mko, 13 years ago

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 by sdlime, 13 years ago

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.

Steve

comment:14 by dmorissette, 13 years ago

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 by sdlime, 12 years ago

Resolution: fixed
Status: assignedclosed

This ones done, closing...

Steve

Note: See TracTickets for help on using tickets.