[Implemented] Fix the gaping security holes

Feature Suggestions
141

Yea, well I disagree with you. :)  And yes they can with MB3 acting as a server with some clients. But MB3 doesn't use "tokens" the same way Plex does so you can't even compare "apples" to "apples" because MB3 is a "bit better" (being polite) thought out in this regard.  But lets take MB3 out of the picture since we are concerned about Plex here.

If you already have a security problem, then you fix it, first and foremost.  What you don't do is intentionally expose yet more problems with additional clients that propitiate the problem even more which is what Plex did/is still doing UNLESS the security is 2nd to profit or to trying to dominate the market..  ANYONE, feel free to correct me on this but I'm pretty sure the security issues were known before the client acting as server feature was introduced.  It surely wasn't in all the clients as it is today,  so the problem is getting worse with each release that has this type of feature.

But this goes back to some of the posts in the thread.  Quit releasing new clients that are going to make fixing this harder.  Throw some resources on it OR bring in a software/hardware guy that specializes in this type of security issue to help you figure it out.  

There are other OPs in the forums that specialize in/or know security very well that could help with architecture and would probably do it for free to get this moving.  I've seen several measures suggested including a couple I threw out that would be easy to implement as a "stop gap", not the end game per say, but enough to make it hard to compromise.   While I don't like to say this out load. Sometimes, just making it difficult can buy you time.  If you make it much harder to compromise your server for semi-little dev time and can stop 95%+ of the easy exploits then you have at least done something.  Right now 2_ years later we have nothing and the same exploits still work just as they did then.  

That's not to say it should end there by any means, but it buys you time and secures your customers servers against the common/easy exploits that many of us know about. Something/Anything is better than nothing which is what we have for 2+ years.  Talk is cheap...

Don't get me wrong, I love Plex as much as the next guy, but sometimes you have to call something for what it is.  And in this case, IMHO, not enough has or is being done security wise.  I'm actually surprised there hasn't been a "big" news story about this considering how popular Plex is.  Plex has been lucky thus far in that no one has written a "big" article that gets a lot of circulation about this.  But as this becomes more and more "public" it's only a matter of time before they get a big "wack" from a leading publication about this and it will haunt them for quite a while.

142

If you already have a security problem, then you fix it, first and foremost.  What you don't do is intentionally expose yet more problems with additional clients that propitiate the problem even more 

On this, I agree.  All development should be (and should have been) focused on solving security issues first and foremost, regardless of how complex the issue is.

143

I wouldn't even go that far.  They do need to make a profit or they won't be in business and we all loose!  However, that doesn't mean they need to expose "more problems".  They could add new features and clients that use a common library that when patched/fixed will solve the problem.  BUT at the same time, don't expose more problems or ways to attack or exploit the system is what I was getting at (which they fail at).

But what bothers me the most is that we haven't see ANYTHING to even try and fix any of the well known exploits.  Surely something can be done to cover many of the easy stuff.

144

I didn't mean to set you off, Cayers, my apology..

145

![post-260987-0-49660900-1425518964.png|690x324](upload://rf6bPIplFVedkCnlcxRa5SNk2QR.png)

146

I've seen several measures suggested including a couple I threw out that would be easy to implement as a "stop gap"

Unfortunately, as I keep pointing out, unless some fundamental issues with the clients and PMS are fixed first, none of the stop-gaps suggested, including my initial suggestions, will fix the issue. 

There are other OPs in the forums that specialize in/or know security very well that could help with architecture and would probably do it for free to get this moving.

We've already been talking with Plex.  Plex is working on it.

147

Unfortunately, as I keep pointing out, unless some fundamental issues with the clients and PMS are fixed first, none of the stop-gaps suggested, including my initial suggestions, will fix the issue. 

We've already been talking with Plex.  Plex is working on it.

At some point, that they are 'working on it' isn't going to cut it anymore - especially as this is coming from a third party, nobody from plex has stated in an official capacity that they even acknowledge anything is wrong...

*edit* seems Elan acknowledged the problem in May 2014 and said that they are actively working on it, my mistake...

I've done some time in software product management - security issues normally get assigned the highest priority to get fixed - everything else such as new features, fancy client support, shiny things gets dumped to the back of the queue until the security issue is fixed - you put the roadmap on hold until it's sorted. There's been probably 15 or 20 releases of the server if not more since the vulnerabilities were disclosed, and countless client releases and new platforms and still nothing is fixed. 

148

I didn't mean to set you off, Cayers, my apology..

:)

149

Because the changes to the server and clients to add UI for installing/managing/pinning self signed certs would take away from time to implement it "properly".

A true statement in itself. But is it an acceptable approach if this "proper" solution won't arrive until the end of the decade? Those 2 weeks to come with an emergency solution won't matter significantly if your development time for the final solutions are getting measured in calendar years.

That is my fundamental problem. For my dayjob I am a security specialist for pretty scary stuff. Our principle assumption is that our solution will never be bulletproof: if we don't mess up at the application-layer, it probably will be a OS problem or even at the hardware level. That being said: I can't sell to customers to ignore a significant security problem for over 10 months (let alone over 24) without ANY visible attempt to improve the situation to bring the risk to an acceptable level.

In this specific case, "Better" is the mortal enemy of "Good enough". You CAN NOT sell to any commercial customer that you are fixing a security issue for over 24 months without any clear warning tot he userbase and/or providing stopgap solution. At some point you have to provide a stopgap measure to allow the devs to come with a final solution.

THis is quite similar to ER's stopping a patient bleeding for the time being with an emergency band-aid, before operating on them. During triage you have to estimate the delivery time of the final solution, and see if an emergency band-aid is needed for the time being. The 10 minute addition of an emergency band-aid over a open artery does provide the surgeon with the time to decently prepare for the operation and fix it decently.

Plex is still prepping for surgery, but is forgetting to stop the bleeding artery in the waiting room that in the meantime already killed the patient. A rooky mistake.

Jaap

PS: And do please note that on some platforms PMS runs under root-privileges.
150

Again, not that simple.  As just one example; I don't believe each MB3 client has the ability to act as its own mini-server, like many of the Plex clients do. Unfortunately, features like this were implemented before a solid plan for security was formed, making the hole they need to dig out of that much deeper.

Although an extremely cool feature, it should be asked if this had to be added before Plex had the capability of properly securing this feature. Besides increasing the attack surface, it also complicated the solution.

That, or they could eliminate such features, and then fend off an uprising of a different nature.  Rock <-> hard-place.

Or indicate they have a serious security issue and temporarily allow specific functionality/players for an internal network by default, and let the user actively decide for an insecure setup if he/she thinks the risks outweigh the benefits. I could live with Plex remote only working on internal networks, and Roku's being blocked from external communication, if that would mean a much more secure setup. Some other people might not, but then they might be running Plex in a DMZ-like setup anyway.

I currently am "forced" to use Plex in an insecure way because the lack of capabilities of clients I don't have. Instead of dumping Plex completely, I would like to turn off insecure features, of activate security features that might block specific clients.

Jaap
151

I think a lot of people really are lost on where the "most" vulnerabilities come from.

It's not you family or friends Roku sitting in their bedroom or living room.  It's not their PS4, xBox or Smart TV.

These devices are running in a "trusted" environment. Yes of course the network can be snooped and exploits found, but this isn't where the temp fixes could come into play with the most bang for dev effort.

Where some "fixes" could be implemented that would reduce the attack vector is on public networks.

Most of the exploits and "take overs" come from snooping on public networks.  It's the mobile clients and web browsers that are the biggest concern.  The clients can easily support some form of encryption as as this is directly controlled by Plex since it's their server and their client.  Even if the media itself is not encrypted (ios issues) that doesn't mean you can't encrypt all the control traffic from the client to the server. It's not perfect but it's better than what we have now.

It's when people are using "mobile" devices or web clients in the wild that potentially cause us the most grief.  These could be fixed in any number of ways.  For example the server itself could have a whitelist of allowed IPs the OP could setup. So for example the clients supporting encryption could be allowed access from anywhere but a web browser using only http won't be allowed to be used unless it's from a whitelist address.

More importantly, as I've pointed out previously.  There SHOULD be more security in management of the server itself.  So again using the whitelist IP approach.  Regardless of tokens, certain management features can not be used or accessed unless you are from a trusted IP address such as 192.168.x.x or 10.x.x.x or your work IP address or your VPN server address, etc...  Being able to authorize devices, etc...  Much of these types of things are what I'd consider basic management features that IMHO should be part of the server anyway.  If they were there they could be used to "help" with the problem.

So what I'm getting at is besides the REAL fixes needed across the board (encryption wise) as talked about there are other things that SHOULD be added to the server itself that controls who can and can't do things.  Other simple things that could be done is not allow a new user to be created unless it's from a trusted IP space AND the OP types the proper password to authorize it.  These are features that are good to have even if all the proper encryption is done.

I personally would have preferred if we had the ability to have an OP assigned cert and https from web browsers.  While I have a few certs for business use I would not even care about using self assigned certs.  I DO NOT see this as being bad either (I know some of you do).  The point of a cert is putting trust in the chain.  If I create the cert and I install this on my devices or those of my family or friends than I've accomplished this and KNOW the chain of trust.  So what I'm getting at is that there surely could have and should have been some stop gap measures put in place a long this 2.5 year period. Is it perfect? No of course not but a few simple (these are simple) things along this nature could help to reduce a very large portion of our attack vector.

I don't know if these types of things besides the management features are worth exploring at this point.  Really depends on Plex itself.  They could have a full blown solution about to be released.  Or of course we could be another year in the same situation.  I strongly disagree with the communication approach of Plex Inc on this.  While it might be fine to hold back info on new features and maybe even general bug fixes IT IS NOT ACCEPTABLE to without security information once the exploits are public knowledge.

With full disclosure of security issues people some people might want to remove "family" related media.  It's one thing to have your copy of "Top Gun" compromised and quite another to have personal video or pictures compromised or relatively open to the internet as it is now.

152

It just seems plex doesn’t care about security. As mentioned previously this has been an issue for a long time. But they priority making money/features over the security of their existing customers. Just seems like a complete lack of management on how to prioritize things.


Has a high level plex employee even post anything to shed light in this thread? Another sign (to me) that plex does not care at all about security.

153

So what I'm getting at is that there surely could have and should have been some stop gap measures put in place a long this 2.5 year period. Is it perfect? s people some people might want to remove "family" related media.  It's one thing to have your copy of "Top Gun" compromised and quite another to have personal video or pictures compromised or relatively open to the internet as it is now.

Where this argument fails is the simple fact that implementing this type of stop-gap is more work than just fixing it "correctly".

Why it hasn't been fixed yet is anyone's guess.  It really shouldn't take this long.

154

I'm not sure why you would say it's more work then just fixing it correctly.  How would enabling encryption of clients where they control both sides be more work?  What I was getting out (maybe not clear enough) is to do this for Android, PHT, ios, Windows apps while not worrying about Roku or other problem clients.  It's the "mobile" clients that pose the biggest risk, not the typical hardware devices used in homes.  There are exceptions of course like the person taking a Roku with them to hotels etc.  But my point is that for the pure software clients they could have done a lot already.  Each and every "client" that could be more protected is that much less exposure. This is especially true for the clients used on public networks.

Also, some of the things I mentioned are just plain useful things to have from a management standpoint and wouldn't be replaced or retired with a proper fix as they are "management" features that can be used for numerous things.

EDIT: I just don't see Plex taking security seriously.  Even with all the security talk the last year, look at the way entering passwords is handled on some of the newer clients.  They pop up a keyboard where anyone in the room can view what you type.  It's impossible to enter a password without clearing the room.

155

I'm not sure why you would say it's more work then just fixing it correctly.  How would enabling encryption of clients where they control both sides be more work?

It's not just "enabling encryption", as the MITM proxy fmstrat and I experimented with is able to do that; it also involves, at a minimum, changing the way local/remote servers are polled.  Things get even more complicated when you start adding a mixture of shared servers.

156

I get what your saying but I don't think you're understanding what I'm saying. I'm not talking about a total solution but a very easy mechanism that will stop 99% of the current exploits. I'm talking about clear tokens on public networks.  If these are encrypted on the specific clients used the most on public networks then it becomes a lot harder to exploit these systems.  There are other methods of exploiting the server and I'm not saying they won't still be a problem but this would help.

That and some reasonable management configuration changes go a long, long way. Again, not the end game solution but anything would have been better than nothing for 2.5 years.

157

If I create the cert and I install this on my devices or those of my family or friends than I've accomplished this and KNOW the chain of trust.

I am of the humble opinion that Self-Signed certs, when done with care, provide much more security than a chain of trust depending on a vague CA that trusts anybody willing to pay and jump some hoops....

With full disclosure of security issues people some people might want to remove "family" related media.  It's one thing to have your copy of "Top Gun" compromised and quite another to have personal video or pictures compromised or relatively open to the internet as it is now.

I would go beyond that. Some platforms (ReadyNAS for example) the PMS runs under full root-privileges. Effectively meaning that a compromised Plex server opens almost any door on the host.Providing both these parts of information is vital for the users to know if they want to make a well-educated assessment of the risks they introduce by installing Plex. I think many users might think otherwise about buying Plex clients and passes knowing this....

Jaap
158

 I'm not talking about a total solution but a very easy mechanism that will stop 99% of the current exploits. I'm talking about clear tokens on public networks.  

And that's exactly what I'm talking about as well.   Plex clients are currently very noisy when they poll for servers.  The clients always search for the local, insecure, servers because they always think they may be on the local network.   (There are other issues as well.)

If you believe this is not an issue, I encourage you to use the MITM proxy and reverse HTTPS proxy fmstrat and I created. 

I am of the humble opinion that Self-Signed certs, when done with care, provide much more security than a chain of trust depending on a vague CA that trusts anybody willing to pay and jump some hoops.

Of course self-signed certs, when used properly, are more secure.  But, when it comes to Plex web, they would be used insecurely more often than not.   Regardless, other things need to be fixed before self-signed OR ca-signed certs actually have a chance of securing Plex client<->server communication.

 

a vague CA that trusts anybody willing to pay and jump some hoops.

That's a bit disingenuous.   It's about as easy to hijack a domain name as it is to get a CA signed cert for a domain you don't own.  Yes, it can be done, mostly through social engineering, but that's true of just about anything -- and hardly applicable to the average Plex admin.   Additionally, if you're using a domain name anyway, what's to stop someone from getting a CA-signed cert through dubious means and using it to transparently MITM attack your self-signed cert when your server is accessed via a web browser?  (Non-browser clients could be hardened against such an attack.)

159

And that's exactly what I'm talking about as well.   Plex clients are currently very noisy when they poll for servers.  The clients always search for the local, insecure, servers because they always think they may be on the local network.   (There are other issues as well.)
 
If you believe this is not an issue, I encourage you to use the MITM proxy and reverse HTTPS proxy fmstrat and I created.  It'll be "secure enough" for you.

 And again I agree with you. But I still don't think you are hearing what I'm saying.  What part of fixing the mobile clients first doesn't make sense to you?  If the "chatter" was all encrypted this would not be as big a problem.  Again, surely better then we have had the last 2.5 years of knowing about this.  How you can not agree with this is beyond me.
 

Of course self-signed certs, when used properly, are more secure.  But, when it comes to Plex web, they would be used insecurely more often than not.   Regardless, other things need to be fixed before self-signed OR ca-signed certs actually have a chance of securing Plex client<->server communication.

Again, WHO CARES because it's adding a whole lot more protection. They could surely add a one page "intro" on first login to explain the need to install a cert on the client. This is a case of the good out weighs the bad.  And again it does not need to be self signed.  But a CERT (signed or unsigned).  This is one of the easier things they could do. A normal cert could be used without issue and a self-signed cert could use an "intro" page.  End result is now it has encryption.
 

That's a bit disingenuous.   It's about as easy to hijack a domain name as it is to get a CA signed cert for a domain you don't own.  Yes, it can be done, mostly through social engineering, but that's true of just about anything -- and hardly applicable to the average Plex admin.   Additionally, if you're using a domain name anyway, what's to stop someone from getting a CA-signed cert through dubious means and using it to transparently MITM attack your self-signed cert when your server is accessed via a web browser?  (Non-browser clients could be hardened against such an attack.)

This is jibber-jabber and just confuses the issue with things irrelevant.  This type of thing can happen on any system but there are ways to handle this as you are aware.

You seem to be against any type of stop gap type measures that would help reduce the problem.  You have indicated it's a waste of time to do anything because the time spent on any stop gap measures could have been used for the final solution.

WHAT IF:

1) They had this all working but have an issue with Rokus or PS4s but everything else could be patched today.  I'd say put in place what you have now especially if some of the devices that could cause a problem aren't mobile.

2) The solution they put in place if flawed as well and still has issues?  Are we then 2.5 years of wasted time since at least part of the solution would have to go back to the drawing board?

3) They have issues and we are still 6 month or more from a solution?

etc, etc, etc

I'd prefer to get this moving on the clients that typically would cause the most harm.  This also allows the customer base to test this out and see what's not working or if their new security still has issues. I really don't want to come off as an @ss but if this is done anything like some of the latest releases it's going to have problems or still isn't thought out well enough.  I commented earlier about the way you enter passwords in plain site.  This just shows that they are still NOT THINKING about security properly.  Granted this is a different type of security but it's still security and shows that things are being "vetted" properly by anyone in the know about security or this type of login would not be allowed to be released, architected, programmed, etc.  This is a true waste of dev time.

So I'd prefer to see something now and get an idea of what kind of real progress has been made and see if they really understand the problems at hand.

160

What part of fixing the mobile clients first doesn't make sense to you?  If the "chatter" was all encrypted this would not be as big a problem.  Again, surely better then we have had the last 2.5 years of knowing about this.  How you can not agree with this is beyond me.

Encrypting remote traffic and encrypting local traffic are, to over simplify, currently two different beasts.  Beasts that, once fixed, basically solve the problem.  In short -- you are not requesting a stop gap -- you are requesting "the fix".

This is jibber-jabber and just confuses the issue with things irrelevant.  This type of thing can happen on any system but there are ways to handle this as you are aware.

This "jibber-jabber" is anything but irrelevant.   If you don't find it interesting, you needn't engage in the jibber, or the jabber.

You seem to be against any type of stop gap type measures that would help reduce the problem. 

I've already taken a stab at a stop-gap solution, realized what needed to be fixed to make it a reality -- and then communicated that to Plex directly.

It's in Plex's court to make the changes necessary.  They are aware of what's needed, both minimum and ideal.  Why we haven't seen results yet is for Plex to say-- but in usual Plex fashion, expect it to be near when we have all but given up.

Anyway, I've invested far more effort in this endeavor, in both hours spent researching the problem, trying to work-around the problem, and trying to communicate the problem to both Plex users and Plex, than I ever thought I would.  I'm cutting my losses here.  I'll watch from the sidelines from now on.