Wejn s.r.o.

Solving complicated IT problems is our hobby.

Why You Should Keep Properties and Logging Modules Out of Your Application.xml

Issue at hand

Not long ago I was spending some quality time with my client’s Application.xml and for some reason the presence of four default modules (base, properties, logging, flvplayback) bugged me.

So I did a quick recon and almost fell out of my chair when I read the description of properties module in Wowza API documentation.

The properties module exposes the following remotely callable functions:

  • [gs]etAppInstanceProperty
  • [gs]etApplicationProperty
  • [gs]etClientProperty
  • [gs]etStreamProperty

In other words – this innocent-looking little module, that’s included by default in all examples supplied with default WMS installation, allows you to read and write IClient, IMediaStream, IApplicationInstance, and IApplication properties!

Why should that worry me, you might ask?

Well, do you use SecureToken module? Either for securing your player-edge or even origin-edge connections? Or, do you perhaps have some <Properties> in your Application.xml you wouldn’t want anyone to read? (SQL connection parameters, backend passwords, etc)

Then you should be worried.

As anyone can read out (or even re-write) your secureTokenSharedSecret (and other properties) as soon as they get RTMP connection.

I alredy reported this problem to Wowza. And while I’m sure they will solve it in the future releases, I would advise anyone running Wowza Media Server to disable both properties and logging modules in their applications unless they’re actively using them and understand the risk(s).

Demo

It’d be boring post without a demo. I wrote a fairly straightforward patch to JWPlayer 6.3 that will bypass SecureToken protection on any server it’s allowed to connect to.

If you connect with regular JWPlayer (or any other Flash player) to the following RTMP URL:

rtmp://wms-dev.wejn.com/vod/_definst_/mp4:sample

you will be required to reply with valid SecureToken response before the video starts playing.

Well, this JWPlayer (modified with the abovementioned patch) works around that problem:

Player here

by requesting the secureTokenSharedSecret AppInstance property from the server and then decrypting the SecureToken challenge with it.

Note: If the demo doesn’t work, I’ve probably hit the 10 connections limit on my development license. In that case you’ll have to try it against your own wowza instance.

Conclusion

Don’t use properties and logging modules in your Application.xml unless you fully understand the risks and absolutely need the remotely-callable functions these modules expose to Flash clients.

Addendum

Sure, you can try combating this problem by checking referrer and perhaps even by employing SWF hash. But both checks can be easily worked around (check the source of rtmpdump or mplayer if you need convincing).

As for why should the logging module be kept out – I’ll leave this to your darker side to figure out.

Timeline

  • 2013-04-06 Wowza Media Services contacted about this issue
  • 2013-04-08 Wowza rep states that this is a non-issue and accuses me of scaremongering
  • 2013-04-19 After subsequent rounds of communication, Wowza rep threatens to “reevaluate” my “independent” consultant status if this info disclosed
  • 2013-04-27 Contacting Wowza rep with non-public preview of this post including the JWPlayer demo (last shot at responsible disclosure)
  • 2013-04-28 Wowza rep responds with more indirect threats, info that this will be resolved sometime in the future and a plea “won’t you please think of the users”
  • 2013-04-30 Public release due to vendor’s non-cooperation