Windows Media Player bug

From: "Zach Robinson" 
Subject: WMP error -- an explanation three years later...
Date: Tue, 14 Feb 2006 18:18:02 -0800


> In reference to:
>  http://davesource.com/Bugs/windows_media_player.1.html
> , I don't think there is a good public way of reporting 'bugs' other
> than via product support.  Kevin [Microsoft Employee] used to publicly
> mention the [email protected] alias for this use,
> but the problem with that is staffing it, and also filtering out
> actual bugs vs random product support inquiries and the tons of spam.

Somehow other companies manage to handle this.  The difference, I
think, is in the quality of product, and perhaps the average
intelligence level of the product users.

Sorry if my anti-Microsoft slant is coming across too hard, but
I don't happily tolerate what Microsoft has managed to do for
decades to the software industry.  Urgh.

> Aaaaanyways, I ran across your page doing a semi-related search.  To
> clarify: your issue is a security feature.  By providing a scriptable
> plug-in that would allow the scripting page to walk the hard drive, WMP
> would expose serious privacy and security concerns.  I believe this was
> mentioned in the microsoft.public.windowsmedia.player newsgroups when it
> was discussed and implemented.  But since that information never got a
> KB or press release or anything of that nature... I figured I should
> pass on the explanation all these years later to help close the loop.

I thought of that possibility, but I don't buy it.

We're talking about playing a *URL* using a relative path.
There's no security reason that this can't be allowed.  It's
not *actually* walking the hard drive, it's passing a URL
to an http server. which will handle the security of ".." in the path,
as all http servers do.

> The error text "The URL would change the root" is the short summary of
> "The URL would change the root location for playback" - which is a
> mangled way of saying that directory traversal is being attempted by the
> page, and that is something we would get excorciated for allowing.
> There's always trade-offs, and this was one.  =\

And the fact that the error message is so poor doesn't exactly help
the situation, does it?

> Regards,
> -Zach
> Windows Media Development Team

I appreciate the email, and it somewhat explains the *motivation*
behind the decision, but it is still, quite clearly, a very ridiculous
implementation decision in my mind.

If I'm wrong about the security of it, can you enlighten me with
a possible security violation that could be created by allowing
'..' in URL relative paths (as all other media players do)?

And care to explain this bug?

http://davesource.com/Bugs/windows_media_player.2.html

Zach responds:

Subject: RE: WMP error -- an explanation three years later...
Date: Tue, 14 Feb 2006 19:59:08 -0800
From: "Zach Robinson" 

> We're talking about playing a *URL* using a relative path.
> There's no security reason that this can't be allowed....

That assumes we always have full usage context, which we don't always
get from the browsing agent.  This is where the story fell down.
Back around 2002 or so, there actually were a number of Very Angry
People who were ready to throttle us because there were vague cases
wherein you could do a theoretical walk of local directories by forcing
local relative paths and checking error results.  This particular error
code pretty completely wiped out that 'privacy attack' vector.

> And the fact that the error message is so poor doesn't
> exactly help the situation, does it?

Nope, not at all.  That's part of something I try to help with on an
on-going basis.  If there's current Web Help errors that could have
better information associated to them, let me know.  It's not my job,
but where I can help, I try to do so.

> If I'm wrong about the security of it, can you enlighten me
> with a possible security violation that could be created by
> allowing '..' in URL relative paths (as all other media players do)?

Hopefully the above explains it.  It was something like:
  hres = WMP.openURL(..\path)
  if( succeeded( hres ) )
  { log_valid_path, traverse for files }
  else{ invalid_path }
, and generally get some sort of local system profile.  Cutting
security/privacy vectors off at the knees saves you years of iterating
horribly in public.  Nobody wants that kind of mess.

Re: "All other media players" -- Microsoft gets held to weird standards.
We can't do what other players do.  Consider the implementation decision
from a paranoid standpoint and it makes sense.  That's about the
standpoint we have to take.  Security First, as they say.