Ticket #2941 (closed defect: fixed)

Opened 5 years ago

Last modified 3 years ago

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

Changed 5 years ago by sdlime

  • status changed from new to assigned

Changed 5 years ago by sdlime

  • priority changed from normal to high

Changed 5 years ago by sdlime

Referencing CVE-2009-0842...

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

Changed 5 years ago by sdlime

  • milestone changed from 5.2.2 release to 5.4 release

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

Steve

Changed 5 years ago by jmckenna

  • cc jmckenna added

Changed 5 years ago by dmorissette

  • cc dmorissette added

Changed 5 years ago by sdlime

For completeness, fixed in r8823 for 4.10 branch.

Steve

Changed 5 years ago by sdlime

  • milestone changed from 5.4 release to 6.0 release

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

Steve

Changed 5 years ago by sdlime

  • component changed from MapServer C Library to MapServer Documentation

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

Steve

Changed 5 years ago by aboudreault

Backported to branch-5-0 in r9199

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

Changed 4 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.

Steve

Changed 4 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.

Changed 3 years ago by sdlime

  • status changed from assigned to closed
  • resolution set to fixed

This ones done, closing...

Steve

Note: See TracTickets for help on using tickets.