Jump to content

WAN Access treated like LAN when "X-Forwarded-For" header is set, allowing login w/o password


pse

Recommended Posts

pwhodges
1 hour ago, cayars said:

However, you need to keep in mind if you have a local proxy the burden of checking this is on the proxy and not Emby as it will always see the local proxy IP address.

Um, no!  The proxy should (if things are going to work right) pass on the originating IP address precisely so that Emby gets to make the right decisions.

Paul

Link to comment
Share on other sites

pwhodges

I'd say your conclusion is correct but your reason (as I read it) is wrong...

Paul

Link to comment
Share on other sites

Well if all processing is done via Emby then it can look at the source IP and tell if it's a local address or not and use this to override any header. As an example it should be impossible to have an external IP address with a header that is internal. That would be a spoofed address.

HOWEVER if you run a proxy server that is local to the Emby server and you have Emby setup to trust the proxy then Emby can't do this and needs to rely on the proxy server to determine spoofed addresses.

That is all the above says.

  • Like 1
Link to comment
Share on other sites

Right, you were talking about a "local proxy" and I was more thinking of just a router. With a proxy, you'll get the user-space forwarding I mentioned, and don't see the original IP.

However, I think the more common setup for people making their server available in the internet is with a router, not a proxy.

  • Like 1
Link to comment
Share on other sites

I'd agree with that and say in that situation Emby itself should be able to detect an external IP spoof of an inside IP address.

Link to comment
Share on other sites

pir8radio

So you spoof a local address, what is the most that gets you?  Just curious..   A list of users?   is that what the worry is?   Granted that's not all that good, if you are trying to hide that.  But its not like it auto logs you in.    Or am I missing something?       If that's the case then I would just ALWAYS hide the user list for devices that have never had a successful login to the server.     narrows your attack surface, to only existing server users that have successfully logged in recently from that exact device.       

Link to comment
Share on other sites

pir8radio
2 minutes ago, pir8radio said:

So you spoof a local address, what is the most that gets you?  Just curious..   A list of users?   is that what the worry is?   Granted that's not all that good, if you are trying to hide that.  But its not like it auto logs you in.    Or am I missing something?       If that's the case then I would just ALWAYS hide the user list for devices that have never had a successful login to the server.     narrows your attack surface, to only existing server users that have successfully logged in recently from that exact device.       

oh looks like that's already an emby feature?   default this to yes? 

  image.png.2c2b4707ea6f0058bbc86949662b284a.png

Edited by pir8radio
Link to comment
Share on other sites

4 minutes ago, pir8radio said:

oh looks like that's already an emby feature?   default this to yes? 

  image.png.2c2b4707ea6f0058bbc86949662b284a.png

That's a new option.

  • Thanks 2
Link to comment
Share on other sites

56 minutes ago, pir8radio said:

So you spoof a local address, what is the most that gets you?  Just curious..   A list of users?   is that what the worry is? 

Granted, it's not a "get full remote access for free" vulnerability, but it's definitively more than just a disclosure of users (which might be mitigated somewhat by that new option):

This vulnerability allows remote login of users who don't have the checkbox "allow remote login" checked (as always, not sure if that's the exact wording in the EN version). I do have a user without password for internal playback purposes. Also, any other feature that is enabled/disabled based on the "remoteness has this issue, e.g. rate limiting.

It's not that far fetched that a user does s.th. like this:

  1. install emby for local testing, add user, don't care for a password
  2. like emby, want to access it from outside
  3. add another, password-protected user for that purpose
  4. disallow "remote access" for internal use and feel safe

At least, that's what I did.

Link to comment
Share on other sites

  • 2 years later...
TeamB

yeah, this was always going to come around and bite them on the ass 🙂

unfortunately, this disclosure and warning were ignored, let’s hope they learn from this going forward.

perhaps we need a vulnerability bounty system, it could even be community funded. $100 for reporting a verifiable vulnerability.

Link to comment
Share on other sites

pwhodges

I'm aware that the staff are acutely conscious of the delay in recognising and fixing this, given the age of the initial report - I'm sure they are determined not to let that happen again!

Paul

Link to comment
Share on other sites

adrianwi

Not only was this not fixed in over 3 years, but it was open to anyone accessing the forum to see!  Lots of lessons to be learned from this, and I can only hope they are.

  • Agree 2
Link to comment
Share on other sites

crusher11

This was reported three years ago? Unbelievable. What level of incompetence is this? 

  • Like 2
Link to comment
Share on other sites

moviefan
7 hours ago, TeamB said:

yeah, this was always going to come around and bite them on the ass 🙂

unfortunately, this disclosure and warning were ignored, let’s hope they learn from this going forward.

perhaps we need a vulnerability bounty system, it could even be community funded. $100 for reporting a verifiable vulnerability.

Sounds like more than a bug bounty system, a bug fixing system is more appropriate.  $100 for fixing a freely reported RCE within less than 3 years!

Link to comment
Share on other sites

kikinjo
57 minutes ago, crusher11 said:

This was reported three years ago? Unbelievable. What level of incompetence is this? 

It was "more important" for example to introduce new season view that hardly anyone needs, and follow "industry standards".

Edited by kikinjo
Link to comment
Share on other sites

I would suggest that this is just a symptom of non standard practices such as using a forum for bug reporting rather than a proper ticketing system. I reaslise github still exists for Emby but it is not a prime resource.

It doesnt need to be Github that is used but a critical security issue was buried in a forum which is by in large non technical content and the signal to noise made it all but certain it would be missed for peer review. I know I did.

Also this there is no content at https://github.com/MediaBrowser/Emby.Releases/security and as posted elsewhere already still no security tag on the release.

There is a wealth of simple best practice that can be followed out there which would have either completely mitigated this in advance or at the very least reduced it. I paraphrase but this should have been reported privately and then after a sensible period escalated publicly via CVE. I realise most Emby users would still not be aware of this but there is a set of us who would and it would have been pushed.

 

Link to comment
Share on other sites

rbjtech
34 minutes ago, xe` said:

I paraphrase but this should have been reported privately and then after a sensible period escalated publicly via CVE. 

It was responsibily disclosed at the time, acknowledged and the advice to raise as a CVE after lack progress was also given.

  • Like 2
Link to comment
Share on other sites

thornbill
8 hours ago, moviefan said:

Sounds like more than a bug bounty system, a bug fixing system is more appropriate.  $100 for fixing a freely reported RCE within less than 3 years!

How do you submit a fix for a vulnerability in a closed source application though?

  • Like 1
  • Agree 1
Link to comment
Share on other sites

rbjtech

Has been said many times by many people on many topics - a forum sucks for things like 'Feature Requests, bug tracking, release/change management'.   Things like Git are clearly more suited to this, but the changeover would be a huge piece of work in it's own right.     Emby has long grown out of it's support toolset imo.. 

  • Like 1
  • Agree 1
Link to comment
Share on other sites

Thanks for the CVE. Nitpicking, stable version number is wrong (4.7.0.12 instead of 4.7.12.0) in the body.

Edited by pse
  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...