Jump to content

Password Protected User Can Log In Without Password (Docker)


a1pilot

Recommended Posts

a1pilot

Morning,

 

I have three users setup on my Emby server (Debian). Two are humans who need to log in or they cannot gain access. The third is a ghost account to allow DLNA access on my LAN.

 

My problem is that although I've setup the DLNA user with a password, if I use a mobile connection to my server web interface to simulate WAN access, I can enter only the username and login without a password. This is potentially a major security hole.

 

I've checked the settings against the human users and they are identical, plus I've restarted the server just in case something didn't take.

 

To troubleshoot, I created a fourth user identical to one of the humans, but without a password. As expected, a remote connection can login with just the username. I then set a password and you can still login without a password. It's as if the password is ignored.

 

Any ideas?

 

Thanks

Link to comment
Share on other sites

a1pilot

Experimenting:

 

Trying to use a mobile connection to log in to the server. Not on the local network, WiFi disabled, via cell phone.

 

If I select the option to require a password on the local network, it forces me to use the password.

 

If I select the option not to require a password on the local network, it lets me in without the password.

 

I think the hole is here. Please can someone check as this is a potentially significant vulnerability.

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

a1pilot

To be clear: selecting the option to not require a password on the local network, isn't restricted to just local network.

 

Possible Docker issue:

 

If this is run in docker behind a proxy, there is a known issue with Docker not taking the remote IP and only seeing localhost.

 

With my Bitwarden instance, it has an email notification that should tell you of a new login and give the IP. However, it always reports the localhost address due to this bug.

 

It says for Mac, but it applies to all systems. I've been watching this for quite some time: https://github.com/docker/for-mac/issues/180

 

When I check the Emby user interface, it reports a failed login from 127.0.0.1 when I use the wrong password deliberately via the mobile app on a cell network. So it looks like this could be the cause.

 

- - - -

 

I'm also seeing this issue: https://emby.media/community/index.php?/topic/86247-user-with-allow-remote-connections-unticked-can-still-log-in-remotely/ which ties in with the potential Docker problem.

Edited by a1pilot
Link to comment
Share on other sites

You've solved your own problem here, correct?

 

In order for our logic between on the local network and not to work, you have to be sure the server can tell the difference between the two.

Link to comment
Share on other sites

a1pilot

You've solved your own problem here, correct?

 

In order for our logic between on the local network and not to work, you have to be sure the server can tell the difference between the two.

Solved in the sense we likely know the cause, yes.

 

Solved in the sense countless users could have exposed instances on the web because of the docker error (still unfixed), very much no.

 

The glitch might come from Docket and be beyond Emby's control, but it does mean it needs to be flagged or even restricted to stop users inadvertenly applying "useless" security measures (i.e. preventing remote connections) or believing their relaxing of security (i.e no password on LAN) is limited to their LAN.

 

This is a genuine security hole in Emby that would potentially allow someone to access my server and download my content, despite all of the configuration within Emby appearing to say it should be secure.

Link to comment
Share on other sites

moviefan

This is a genuine security hole in Emby that would potentially allow someone to access my server and download my content, despite all of the configuration within Emby appearing to say it should be secure.

 

This isn't a security hole in Emby.

 

Emby is detecting local LAN versus remote connections based upon the originating source IP..  This is perfectly reasonable behavior and what most people want.

 

Your docker configuration is proxying the connections to Emby and making those requests appear local.  Stop doing that and Emby works fine.

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

Spaceboy

Solved in the sense we likely know the cause, yes.

 

Solved in the sense countless users could have exposed instances on the web because of the docker error (still unfixed), very much no.

 

The glitch might come from Docket and be beyond Emby's control, but it does mean it needs to be flagged or even restricted to stop users inadvertenly applying "useless" security measures (i.e. preventing remote connections) or believing their relaxing of security (i.e no password on LAN) is limited to their LAN.

 

This is a genuine security hole in Emby that would potentially allow someone to access my server and download my content, despite all of the configuration within Emby appearing to say it should be secure.

if you don’t understand how to secure your install correctly you shouldn’t be making it publicly available
  • Like 1
Link to comment
Share on other sites

a1pilot

if you don’t understand how to secure your install correctly you shouldn’t be making it publicly available

It's a known docker flaw, not caused by me. This docker flaw, combined with the available emby options, results in an insecure setup.

 

The docker flaw doesn't result in the security hole, nor does my proxy, nor does my Emby setup, when taken on their own. It is the combination, which is not some special setup, that is the route to failure.

 

Emby might be operating as expected, but if there is a route that allows for such a blatant security hole, it's a problem.

 

I fail to believe I'm the only one who sees a problem here.

 

Of course, I welcome all advice that explains how to secure this particular issue while retaining the required functionality. I mean, spacebiy, you must know if you can proclaim it's my fault not being able to secure it and not in fact an issue between Docker and Emby.

Link to comment
Share on other sites

Spaceboy

It's a known docker flaw, not caused by me. This docker flaw, combined with the available emby options, results in an insecure setup.

 

The docker flaw doesn't result in the security hole, nor does my proxy, nor does my Emby setup, when taken on their own. It is the combination, which is not some special setup, that is the route to failure.

 

Emby might be operating as expected, but if there is a route that allows for such a blatant security hole, it's a problem.

 

I fail to believe I'm the only one who sees a problem here.

 

Of course, I welcome all advice that explains how to secure this particular issue while retaining the required functionality. I mean, spacebiy, you must know if you can proclaim it's my fault not being able to secure it and not in fact an issue between Docker and Emby.

it was a general comment, not aimed at you
Link to comment
Share on other sites

a1pilot

it was a general comment, not aimed at you

Fair enough, but the response stands. In this case, you can do everything correct and still end up with a security hole. So it's not a case of the user not knowing.

Link to comment
Share on other sites

BAlGaInTl

I run Emby in docker behind a proxy that is also in docker.

 

I don't see this behavior. 

 

What's wrong with the easy fix of requiring passwords for local users?  I can see pros and cons to this, but it depends on your use case.

Link to comment
Share on other sites

Spaceboy

Fair enough, but the response stands. In this case, you can do everything correct and still end up with a security hole. So it's not a case of the user not knowing.

but that’s the point, if the user doesn’t know then they probably shouldn’t be exposing their server publicly. This has been discussed here before, the only real secure option for novices is to have some sort of central control like plex and very few people here want that
Link to comment
Share on other sites

a1pilot

I run Emby in docker behind a proxy that is also in docker.

 

I don't see this behavior. 

 

What's wrong with the easy fix of requiring passwords for local users?  I can see pros and cons to this, but it depends on your use case.

This is interesting. If you do a failed login, do you see the remote IP? If you do, this would also be of interest in the Docker thread.

 

There's nothing wrong requiring a password for local users, I use the no password option for certain devices that's all. The point isn't whether you should, it's that you can and as a result it exposes your setup.

 

I don't get the issue - it's a potential route that opens a security flaw, even if the user setup is correct, so surely it is a good idea to at least warn users on that page?

Link to comment
Share on other sites

a1pilot

but that’s the point, if the user doesn’t know then they probably shouldn’t be exposing their server publicly. This has been discussed here before, the only real secure option for novices is to have some sort of central control like plex and very few people here want that

If you're talking about a user not knowing what they're doing, then yes absolutely. But in the context of this issue, it reads as though you shouldn't expose your server unless you know every bug in the software. This would stop evey development project going live, and is impossible.

 

You talk as if it's a user issue, but it's not. It's a perfectly valid configuration that results in an exposed server. The user could know everything about setting this correctly and still get this issue because it is unexpected behaviour that is in oppositon to the selected settings.

Link to comment
Share on other sites

BAlGaInTl

Fair enough, but the response stands. In this case, you can do everything correct and still end up with a security hole. So it's not a case of the user not knowing.

 

I think that maybe the point is that everything isn't correct.

 

There is something off with your setup.  Not sure what that is.  As I stated... I do basically the same thing, and my user IP address are correctly reported.  

 

user -> Cloudflare -> Local Reverse Proxy -> Emby Server

 

The last two are both docker containers.

 

Maybe if you gave some more details about your exact setup, we could help.

Link to comment
Share on other sites

Spaceboy

If you're talking about a user not knowing what they're doing, then yes absolutely. But in the context of this issue, it reads as though you shouldn't expose your server unless you know every bug in the software. This would stop evey development project going live, and is impossible.

 

You talk as if it's a user issue, but it's not. It's a perfectly valid configuration that results in an exposed server. The user could know everything about setting this correctly and still get this issue because it is unexpected behaviour that is in oppositon to the selected settings.

that is to be determined. Just because you say it’s a bug does not make it a bug
Link to comment
Share on other sites

a1pilot

I think that maybe the point is that everything isn't correct.

 

There is something off with your setup.  Not sure what that is.  As I stated... I do basically the same thing, and my user IP address are correctly reported.  

 

user -> Cloudflare -> Local Reverse Proxy -> Emby Server

 

The last two are both docker containers.

 

Maybe if you gave some more details about your exact setup, we could help.

Hmm, I don't use cloudflare. I have:

 

user > Debian server > apache reverse proxy > emby docker

 

As per the linked Docker thread, it's a known issue with Debian / Windows / Mac server instances of Apache and Nginx proxy passing across to Docker. It's been around for 4+ years. Docker sees the proxy localhost address and it hits lots of dockerised packages, including Bitwarden.

Link to comment
Share on other sites

BAlGaInTl

If you're talking about a user not knowing what they're doing, then yes absolutely. But in the context of this issue, it reads as though you shouldn't expose your server unless you know every bug in the software. This would stop evey development project going live, and is impossible.

 

You talk as if it's a user issue, but it's not. It's a perfectly valid configuration that results in an exposed server. The user could know everything about setting this correctly and still get this issue because it is unexpected behaviour that is in oppositon to the selected settings.

 

 

Hmm, I don't use cloudflare. I have:

 

user > Debian server > apache reverse proxy > emby docker

 

As per the linked Docker thread, it's a known issue with Debian / Windows / Mac server instances of Apache and Nginx proxy passing across to Docker. It's been around for 4+ years. Docker sees the proxy localhost address and it hits lots of dockerised packages, including Bitwarden.

 

I think we are more than happy to try and help, but it seems that you are misdirecting the blame to Emby when it appears to be a configuration/Docker issue.

 

What you are doing is not a standard setup by any means, but you can do it securely.  There are multiple moving parts, and each of those must be configured correctly.

 

The good news is that you self-identified the issue.

 

I'm not an expert on Docker by any means either... but it may be more helpful to give details on how you have your containers setup.

Link to comment
Share on other sites

a1pilot

I think we are more than happy to try and help, but it seems that you are misdirecting the blame to Emby when it appears to be a configuration/Docker issue.

 

What you are doing is not a standard setup by any means, but you can do it securely.  There are multiple moving parts, and each of those must be configured correctly.

 

The good news is that you self-identified the issue.

 

I'm not an expert on Docker by any means either... but it may be more helpful to give details on how you have your containers setup.

I'm not blaming emby. I fully acknowledge this is docker - you wouldn't believe how much time I've spent trying to solve it for Bitwarden, where getting such detail as the IP addess of a login attempt is actually important.

 

I would have thought reverse proxy to docker is pretty standard. Certianly the push towards such these docker type setups generally, but I stand corrected if not.

 

The problem as I see it, is that there is this known bug in Docker and at the moment it isn't fixed or likely to be fixed, and Emby is then offering a feature set (that I like) which ultimately results in a combination that has this issue. Emby doesn't have to fix it, but it wouldn't hurt to warn against it. Even something in the setup instructions that highlights an incorrect setup could expose your whole libraries (i.e. fail dangerous in my line of work).

 

If it's decided it's not a bug, that's cool for me who now knows and worked around it.

Link to comment
Share on other sites

BAlGaInTl

I'm not blaming emby. I fully acknowledge this is docker - you wouldn't believe how much time I've spent trying to solve it for Bitwarden, where getting such detail as the IP addess of a login attempt is actually important.

 

I would have thought reverse proxy to docker is pretty standard. Certianly the push towards such these docker type setups generally, but I stand corrected if not.

 

The problem as I see it, is that there is this known bug in Docker and at the moment it isn't fixed or likely to be fixed, and Emby is then offering a feature set (that I like) which ultimately results in a combination that has this issue. Emby doesn't have to fix it, but it wouldn't hurt to warn against it. Even something in the setup instructions that highlights an incorrect setup could expose your whole libraries (i.e. fail dangerous in my line of work).

 

If it's decided it's not a bug, that's cool for me who now knows and worked around it.

 

Using a reverse proxy is pretty standard.  There are lots of users here that have one set up.  This is the first time I've seen this issue reported here.

 

What do your docker configs look like?

 

Have you posed the same questions at the Bitwarden forums?

 

It seems that there is some discussion about the network parameter on the original link you posted.  Have you looked in to that?  I'm running mine (both proxy and Emby) in bridge, and it works fine, but it's worth a shot.

Link to comment
Share on other sites

pwhodges

Is this "docker issue" actually no more than that the proxy in the docker is by default not configured to send a "forwarded for" header?  In which case presumably the fix is simply to add generation of that header to the proxy configuration so that Emby can see that the originator is not local.

 

Or have I missed the point somewhere?

 

Paul

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

BAlGaInTl

Is this "docker issue" actually no more than that the proxy in the docker is by default not configured to send a "forwarded for" header?  In which case presumably the fix is simply to add generation of that header to the proxy configuration so that Emby can see that the originator is not local.

 

Or have I missed the point somewhere?

 

Paul

 

Trying to get to the point, but I think it's something like that.

 

Which would also explain why the Docker team hasn't fixed the issue in 4 years. Because it's just a configuration issue, and not a bug.

 

But I can't say 100%.  Like I said... I'm also not an expert, but was trying to get the OP to post some configuration files so that the experts could have look.

 

ETA: To be fair... my setup is actually done through Unraid (linux) which takes care of the dirty work of configuration for me.  I do everything through a web gui, but it seems to be working as intended.  I don't jump in with vi or Emacs to edit config files.  But at least I know what those are.  :D

Edited by BAlGaInTl
Link to comment
Share on other sites

BAlGaInTl

I'll play around with this on my beta server instance tonight to see if I can reproduce it.

Link to comment
Share on other sites

moviefan

I'm running mine (both proxy and Emby) in bridge, and it works fine, but it's worth a shot.

 

I actually read through that long bug report and it is confusing to follow.

 

But I am wondering if this is main issue.  

 

OP are you running your setup in bridge mode?

Link to comment
Share on other sites

BAlGaInTl

I actually read through that long bug report and it is confusing to follow.

 

But I am wondering if this is main issue.  

 

OP are you running your setup in bridge mode?

 

I'm running mine in bridge mode, and it works fine.

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