Mapfile parser could leak sensitive data

[sdlime]

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).

[sdlime]

Referencing CVE-2009-0842...

[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).

[sdlime]

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

Steve

[sdlime]

For completeness, fixed in r8823 for 4.10 branch.

Steve

[sdlime]

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

Steve

[sdlime]

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

Steve

[aboudreault]

Backported to branch-5-0 in r9199

[mko]

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) ).

[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.

Steve

[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.

[sdlime]

This ones done, closing...

Steve