Remote code execution vulnerability with XHTML-IM enabled #498
Comments
|
It would have been more appropriate to disclose this privately before posting it publicly. I'll look into solutions when I can. In the meantime we're now in a slightly awkward position. If anyone else has a ready fix, PRs would be greatly appreciated. |
|
Sounds interesting. I will do some research I may do a PR on this issue it
looks awesome! Great find.
…On Sun, Jan 1, 2017 at 12:26 PM Ben Langfeld ***@***.***> wrote:
It would have been more appropriate to disclose this privately before
posting it publicly.
I'll look into solutions when I can. In the meantime we're now in a
slightly awkward position. If anyone else has a ready fix, PRs would be
greatly appreciated.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#498 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMphBu9g0yvgx94AXY8dgrgT7RGZqf_Iks5rN-HDgaJpZM4LYqXt>
.
|
|
I would have sent it to your security list if there was one. I believe the correct patch would be informing users that XHTML-IM should be disabled and removing support for it entirely in the next release. It is simply too difficult to sanitize XHTML-IM correctly, and several modern clients (such as Conversations) has come to this same conclusion. Consider if you spend the time to write a clean-tree sanitizer; walk through the incoming message node by node, and when valid nodes are found pass the supported attributes to a function which re-creates that node in your clean tree. All someone would need to do to attack this is send an img src="javascript:" or something similar, and each time this is discovered you'd have to go back to make your sanitizer check for something extra. There's no winning this game. There's also a privacy issue img elements; if I want to discover the IP address of another user all I would need to do is send an image to them privately through a MUC service and check the HTTP server logs for which IP was used to access it. Their IP address reveals their geographic region, with the help of 3rd party lookup services it can show some of their Internet history, or it could be used to launch a ddos attack. |
|
I'm not a project maintainer just a active developer. Thanks for the input.
You outta create a pull request.
Simply - Add a security notice in the ReadMe- with the info you provided
here. I'm sure they'd appreciate it. DDOS attacks are mainly on your
server. Not necessarily in the code. If you maintain a good security on
your server shouldn't have a issue.
Additionally some configuring is required with this to make it work. So if
you wanna use it you should know that you need to make sure it's secure-
Like said before PR are welcome I'll look into. Could be something cool for
me to do.
|
|
DDoS attacks are primarily executed against servers because individual users rarely have their IP addresses exposed like this, but they used to happen on IRC against individual users all the time (and are much easier to accomplish given the limited bandwidth many users have). What changed to stop this is most IRC servers started masking user hostnames/IPs. |
|
Ah I see- that's cool. Thanks for the info!
|
|
If I worked on a PR and somehow get Something Like this integrated would this help? I am trying to figure out a easy way to add a hotfix. As it seems like its a easy fix. I also suggest adding your own PR with the Security message. Write so no one is alarmed but proceed with caution. and it is reccomended you have xhtml-im disabled. |
|
This ticket is full of win! Candy Dev, where do you explicitly say where security issues should be reported? (security isn't mentioned in GitHub readme, or your .io page). Bug reporter, XSS is not RCE, at all, in any way (although, bonus points for the Super Troopers image in your XSS PoC). In the mean time, please continue with this disclosure... =) |
|
@attritionorg We don't have an explicit security disclosure process, that's our failure and I will fix it. In the absence of something explicit, emailing the maintainer directly would be a reasonable assumption to make. Instead I now have this public disclosure to scramble after like a headless chicken without any advance warning. |
|
This issue was discovered publicly by one of our Google Code-in students, who was writing a plugin for Candy, but used an onclick="" from the sender side. This led to a discussion as to why this wasn't a good solution, and moreso, the security implications of javascript even being allowed. If you'd like help addressing this we have 2-3 students who are extremely familiar with Candy who would love to clean this up. It would be great to get you back into the XSF, applications for Q1 2017 are now open. |
|
If your team has time to prepare a solution, that would be much appreciated! The time I have available to work on Candy is unfortunately very limited since I don't actively use it any more. |
|
Arc you are welcome to have anyone contribute. Just create a PR.
…On Mon, Jan 2, 2017 at 1:40 PM Ben Langfeld ***@***.***> wrote:
If your team has time to prepare a solution, that would be much
appreciated! The time I have available to work on Candy is unfortunately
very limited since I don't actively use it any more.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#498 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMphBgJQLZQpbkVs07Y0i569GLwkFx6sks5rOUSQgaJpZM4LYqXt>
.
|
|
Was this ever fixed? There a link to the commit etc? |
|
No-one has yet proposed a fix. |
|
The fix is to disable support for HTML in messages. Candy isn't the only
client with this kind of vulnerability, and once you start to look at the
problem nothing short of writing a xhtml-im rendering engine will safely
stop these kinds of attacks.
…On Jul 14, 2017 5:37 AM, "Ben Langfeld" ***@***.***> wrote:
No-one has yet proposed a fix.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#498 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB1A8U5CMZupotd9aXGe0IE-qRESuWQnks5sN2EOgaJpZM4LYqXt>
.
|
|
Do you have a pull request? |
|
Do you have a bug bounty for this?
…On Fri, Jul 14, 2017 at 10:43 AM, Ben Langfeld ***@***.***> wrote:
Do you have a pull request?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#498 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB1A8Wg78Y-rgbW_V_Ijf7Oqnwie1o3Oks5sN6jdgaJpZM4LYqXt>
.
|
|
No. |
Candy lacks a proper HTML sanitizer allowing remote javascript code execution which can be used to send spam from other user's accounts, steal account credentials, or exploit browser vulnerabilities.
This hack was done with a simple img onload="" to send a message via Candy's own API. It could just have easily made everyone's clients send their login credentials to the room.
The text was updated successfully, but these errors were encountered: