[natethomas]

acidgen, no offense intended, but from my perspective that report is incomplete. Specifically, "Potentially any device running XBMC with the webserver might be vulnerable." Would it not be more accurate to say, "Potentially any device running XBMC with the webserver exposed to the internet might be vulnerable"?

And then in solutions, instead of what is there...

"There is a patch as of 2012-11-05. Most users will not be affected, as they likely have not exposed their webserver to the internet. However, users who have opened a port on their server to expose webserver to the internet are advised to disable, or password protect their XBMC Web application with a strong password and username."

To be fair, I assume you wrote the report prior to Montellese's patch, so I'm not too concerned about that bit. But from my understanding, this report MIGHT affect about 1% of extremely advanced XBMC users who have decided they want to control XBMC at their parents' house from their own house, while it is currently worded to suggest that essentially all XBMC users are at risk.

Perhaps I misunderstand the situation, but if I've got it right, presenting the threat as more than it is seems somewhat unprofessional.

[amet]

besides, anyone who wants a root password for my xbmc setup(s) is welcome to ask for it, i will publicly post them here. hell, I'll even give you external IP address for my router

[acidgen]

acidgen, no offense intended, but from my perspective that report is incomplete. Specifically, "Potentially any device running XBMC with the webserver might be vulnerable." Would it not be more accurate to say, "Potentially any device running XBMC with the webserver exposed to the internet might be vulnerable"?

And then in solutions, instead of what is there...

"There is a patch as of 2012-11-05. Most users will not be affected, as they likely have not exposed their webserver to the internet. However, users who have opened a port on their server to expose webserver to the internet are advised to disable, or password protect their XBMC Web application with a strong password and username."

To be fair, I assume you wrote the report prior to Montellese's patch, so I'm not too concerned about that bit. But from my understanding, this report MIGHT affect about 1% of extremely advanced XBMC users who have decided they want to control XBMC at their parents' house from their own house, while it is currently worded to suggest that essentially all XBMC users are at risk.

Perhaps I misunderstand the situation, but if I've got it right, presenting the threat as more than it is seems somewhat unprofessional.

Hi,

So if an attacker has access to an internal network (e.g physicaly as a guest or any other means) and finds the company entertainment system, in this case XBMC with the web-server for easy access. They are still vulnerable, even if they run the software exposed on the internet or not.

This was released before Montelle's patch (which I haven't had time to verify) since some developers at XBMC wanted me to post everything here, which i did upon request.
If you would like to, please appoint someone that I could contact directly if the other bugs are deemed exploitable. Most firms have a contact person, which can be consulted about the vulnerability and, have the ability to coordinate a patch / disclosure at the same time.

I found 9891 hosts running XBMC with the web-application active without any authentication, according to Shodan, 4-5 weeks ago. Hopefully it's dropping as we speak.

This should be considered a risk and a vulnerability (information disclosure) which allows an attacker to read unencrypted password files. For some users the risk is higher than for others. I think that it's strange that you find it "unprofessional". Since previous posts suggest that you have known about this vulnerability several versions back, and done nothing about it?

Your Opinion, that you; Are willing to give the root password, and IP addresses to your router / XBMC setup, is your opinion. Other users of XBMC might not share the same openness as you do, and are keen about the privacy.

Question for you guys: How do you want this handled in the future then?

Best regards
Lucas

[acidgen]

acidgen, no offense intended, but from my perspective that report is incomplete. Specifically, "Potentially any device running XBMC with the webserver might be vulnerable." Would it not be more accurate to say, "Potentially any device running XBMC with the webserver exposed to the internet might be vulnerable"?

And then in solutions, instead of what is there...

"There is a patch as of 2012-11-05. Most users will not be affected, as they likely have not exposed their webserver to the internet. However, users who have opened a port on their server to expose webserver to the internet are advised to disable, or password protect their XBMC Web application with a strong password and username."

To be fair, I assume you wrote the report prior to Montellese's patch, so I'm not too concerned about that bit. But from my understanding, this report MIGHT affect about 1% of extremely advanced XBMC users who have decided they want to control XBMC at their parents' house from their own house, while it is currently worded to suggest that essentially all XBMC users are at risk.

Perhaps I misunderstand the situation, but if I've got it right, presenting the threat as more than it is seems somewhat unprofessional.

Hi,

So if an attacker has access to an internal network (e.g physicaly as a guest or any other means) and finds the company entertainment system, in this case XBMC with the web-server for easy access. They are still vulnerable, even if they run the software exposed on the internet or not.

This was released before Montelle's patch (which I haven't had time to verify) since some developers at XBMC wanted me to post everything here, which i did upon request.
If you would like to, please appoint someone that I could contact directly if the other bugs are deemed exploitable. Most firms have a contact person, which can be consulted about the vulnerability and, have the ability to coordinate a patch / disclosure at the same time.

I found 9891 hosts running XBMC with the web-application active without any authentication, according to Shodan, 4-5 weeks ago. Hopefully it's dropping as we speak.

This should be considered a risk and a vulnerability (information disclosure) which allows an attacker to read unencrypted password files. For some users the risk is higher than for others. I think that it's strange that you find it "unprofessional". Since previous posts suggest that you have known about this vulnerability several versions back, and done nothing about it?

Your Opinion, that you; Are willing to give the root password, and IP addresses to your router / XBMC setup, is your opinion. Other users of XBMC might not share the same openness as you do, and are keen about the privacy.

Question for you guys: How do you want this handled in the future then?

Best regards
Lucas

Guys,
If you feel that the report still is unclear. I'm open to discussion, thou this should have happened way before the release.

Best regards
Lucas

[amet]

it is perfectly safe even if I give you my password is my point ... no need to attack it to get it.

my money is that 90% of users use xbmc/xbmc combination of user/pass anyway... no need to try and exploit any vulnerabilities

direct any further "issues" to this thread I think, or contact us using contact mail from xbmc.org

[Montellese]

I think what natethomas labeled as "unprofessional" is that your report paints a very bad picture stating that every XBMC installation causes a security risk but the user first has to enable the webserver and make the computer running XBMC available to the internet (or intranet). That's two distinct actions a user has to make for this vulnerability to become a threat. And he assumes that most users never enable the webserver because they don't have the need to remote control their XBMC installation over the webserver (and just use a normal IR remote). Therefore while the security risk is there it's not like every xbmc installation out there is automatically threatened by it. Personally I don't really care how many people are/were exposed to this vulnerabilty, it was a more or less easy fix so I took the time to look into it and do what was necessary. I'd have done it if only one in 10'000 xbmc users would have been affected. No use in picking on wording/phrasing, the vulnerability was there, it has been fixed, end of discussion (on that vulnerability).

The information that this vulnerability was known is not 100% accurate. The same vulnerability existed when using the vfs handler of xbmc's webserver (i.e. http://ip:port/vfs/some/arbitrary/path) but just removing it wasn't that easy because a lot of third party applications available to control XBMC relied on that very feature by accessing playlists etc created within XBMC etc. Therefore we first had to find a way to get rid of the vulnerability while allowing third party applications to still access files managed by XBMC. I wrote that patch a month or so ago but I didn't realize that doing the same thing without the "vfs/" in the path exposed the same vulnerability.

What you have to keep in mind is that we are not a company selling a product. We are a group of developers who like to work on XBMC in our free time and for free. We don't have any legal obligation to fix a specifc bug or security issue because the software is provided as-is and we don't sell it nor do we offer any kind of payed support etc. So that's also why there's no contact person responsible for handling these things. XBMC is open-source, anyone can read the source code and anyone can hack or modify it if he/she so chooses. If someone finds a problem (no matter the nature of it) he either lives with it or he comes to the forum or our bug tracker and reports it. If a developer sees it and has the time to look into it, he looks into it. If nobody cares or the developers who introduced that bug don't have the time to look into it, nothing happens.

So IMO the best way to go about this is to just post your findings here and explain them in as much detail as possible (which you did well enough for me to easily figure out what the problem was with the webserver).

[fiar]

Hey Amet, so what's your password ?

[amet]

iloveubuntu

[acidgen]

it is perfectly safe even if I give you my password is my point ... no need to attack it to get it.

my money is that 90% of users use xbmc/xbmc combination of user/pass anyway... no need to try and exploit any vulnerabilities

direct any further "issues" to this thread I think, or contact us using contact mail from xbmc.org

I think what natethomas labeled as "unprofessional" is that your report paints a very bad picture stating that every XBMC installation causes a security risk but the user first has to enable the webserver and make the computer running XBMC available to the internet (or intranet). That's two distinct actions a user has to make for this vulnerability to become a threat. And he assumes that most users never enable the webserver because they don't have the need to remote control their XBMC installation over the webserver (and just use a normal IR remote). Therefore while the security risk is there it's not like every xbmc installation out there is automatically threatened by it. Personally I don't really care how many people are/were exposed to this vulnerabilty, it was a more or less easy fix so I took the time to look into it and do what was necessary. I'd have done it if only one in 10'000 xbmc users would have been affected. No use in picking on wording/phrasing, the vulnerability was there, it has been fixed, end of discussion (on that vulnerability).

The information that this vulnerability was known is not 100% accurate. The same vulnerability existed when using the vfs handler of xbmc's webserver (i.e. http://ip:port/vfs/some/arbitrary/path) but just removing it wasn't that easy because a lot of third party applications available to control XBMC relied on that very feature by accessing playlists etc created within XBMC etc. Therefore we first had to find a way to get rid of the vulnerability while allowing third party applications to still access files managed by XBMC. I wrote that patch a month or so ago but I didn't realize that doing the same thing without the "vfs/" in the path exposed the same vulnerability.

What you have to keep in mind is that we are not a company selling a product. We are a group of developers who like to work on XBMC in our free time and for free. We don't have any legal obligation to fix a specifc bug or security issue because the software is provided as-is and we don't sell it nor do we offer any kind of payed support etc. So that's also why there's no contact person responsible for handling these things. XBMC is open-source, anyone can read the source code and anyone can hack or modify it if he/she so chooses. If someone finds a problem (no matter the nature of it) he either lives with it or he comes to the forum or our bug tracker and reports it. If a developer sees it and has the time to look into it, he looks into it. If nobody cares or the developers who introduced that bug don't have the time to look into it, nothing happens.

So IMO the best way to go about this is to just post your findings here and explain them in as much detail as possible (which you did well enough for me to easily figure out what the problem was with the webserver).

Hi,

Not in any means am I trying to offend anyone. The alternative i proposed is meant as an example on how it could be done easier, and without misunderstanding or anyone else interfering in a forum post. I know that people here could be short on time, that's one of the main reason for a disclosure. To warn the public about the vulnerability. So they can close down the affected part/application while waiting for a patch. And if you fix it or not, that's up to you At least people know about it.

I'll post any findings here as well. Thou I sincerely hope that this does not end up as some kind of a flame war post, where people have to ventilate themselves.
And if you would like any minor changes in the disclosure, please send me a private message and we'll work it out.

Thanks

Best regards
Lucas

[natethomas]

Lucas,

To be clear, I definitely do appreciate the work you did finding and pointing out the flaw. It is invariably better to know about a flaw so that it can be fixed than to not know and get screwed later.

I merely wanted the wording to be slightly more specific, so that people who are perhaps not coding geniuses and security experts don't freak out. If I understand you correctly, you were able to find about 10,000 people who were affected by this flaw. Let's presume that you weren't able to find everyone and the number is closer to 30,000. There are roughly 2 million XBMC users who are online in a given month. 10k affected users is less than 1%. 30k affected users is less than 2%. That's a pretty limited portion of our user base, but the people who are blowing up my twitter feed likely have no idea that they are not part of the 1-3% affected.

Curiously, I don't really mind if you publish all the flaws you find. We dev in the open, and we are usually pretty happy to let our users be as informed as they want to be. The only problem with publishing as openly as we do is that you have to be aware that your new audience isn't as informed as most of your friends and certainly isn't as informed as the companies you habitually work with. As such, you essentially have to teach these users exactly who, why, and how on matters of security.

Sorry about the unprofessional comment. Sometimes I forget that not everyone is used to working in this kind of open environment.

[crash123]

Hey Amet, so what's your password ?

iloveubuntu

I like that fiar created an account just to ask that. Elite haxx0r.

[amet]

Hey Amet, so what's your password ?

iloveubuntu

I like that fiar created an account just to ask that. Elite haxx0r.

yeah, him and Kevin must be BFFs

[mandreko]

Disclaimer: I worked with Lucas (acidgen) on some of the validation of the results, specifically iOS, ATV2, and RaspBMC.

I think it should be important to note, that with the popularity of the Raspberry Pi device, that their custom RaspBMC distribution (read: not official from xbmc.org) of linux, has the webserver for XBMC enabled by default, with the creds, xbmc:xbmc. Now, I'm not going to try to falsely say that the RaspBMC crowd makes up any tangible percentage of the users, but it does make up at least some portion, and some is greater than none.

No other platform that I tested with had it enabled by default, but so far every platform was vulnerable to this directory traversal vulnerability.

[un1versal]

I dont want to cause a war here by making an observation.

Dismissing any security issues claiming only a small % of users will suffer doesn't seem to be logical even though it probably is practical from a support stand point and that is how business is done anyway.

If there are any issues that are unlikely to be addressed because the % of users is too little to justify the work of fixing or supporting a bug or security in general at least the users should be told and informed of such potential issues (in security case) more so, than in case of bugs.

In case of the passwords/user name being too obvious, its a case of very much exchanging convenience for insecurity (apparently its a trend worldwide), and one can only blame this on lazy or ignorant users that prefer to have everything handed to them in a out-of-the-box fashion and cant be bothered (so one cant blame developers that cant be bothered when users definitely cant and wont)

I still think There should be a warning somewhere in software to remind users what they a combo. And dxbmc can do this easily! Not that I can fix it or I would.

Recently XBMC added a display screen on first run https://github.com/xbmc/xbmc/pull/1617 to tell users that there's a hidden menu. (a great usability idea) fantastic!
This would be great to use this idea to at least warn users they are using default or weak username and passwords on webserver and that its a security issue, if users still choose to ignore it, then at least no one can say team xbmc is not being responsible.

Any 3rd party distros should equally demonstrate that warning users in similar fashion and should not wait for xbmc to do it anyway.

Again its not a criticism, just observation and suggestion.

I believe team xbmc developers do a fantastic job and xbmc is testament to their hard-work, commitment and ingenuity.

uNi

[natethomas]

Dismissing any security issues claiming only a small % of users will suffer doesn't seem to be logical even though it probably is practical from a support stand point and that is how business is done anyway.

Hopefully this wasn't directed at me. I pointed out the small percentage, not as a reason to dismiss, but rather as a reason to more fully explain to people whether and why they might be affected. That's pretty much been my entire goal for this whole conversation.