wojciech.kapcia@tigase.net opened 3 years ago
|
|
Initial JMH benchmark to test original performance of the code responsible for parsing data.
|
|
Result after applying changes:
|
|
@kobit after discussing the issue with Andrzej and indeed there was and issue and we arrived at the conclusion that the best solution will be to modify our parser and, in case of encountering quote within attribute value escape it (directly within parser to avoid available unescape code due to performance penalty - and as seen below, the change affects performance in minimal way). Now to the handling of the topic - currently it's based on master branch, should be backport it to older branches and if so, how "deep"? (recently released 8.2 stable comes to mind, should we include it in 8.1? others)? How about announcement? Do we want to announce it (and if so - where?) or just include it in the release notes (I'd say it would be prudent to at least inform our clients, though they mostly use non-public deployments)? |
|
Ok, before deciding I would like to make sure I understand the impact. Please confirm or clarify below:
Looking at our stats, the most used versions are:
Therefore, it seems to me, if we can, we should prepare bug-fix builds for ver5.1.x, ver7.1.x, ver8.1.x, ver8.2.x. At the same time we should remove access to 8.2.0 build once the bugfix is released. For older versions, the bugfix version can be just as simple as repackaging the oldest minor version and replacing xmltools library. Just make sure it is compiled with a correct java version. We also need a list of affected customers and we need to prepare instructions on how to apply the fix for each version. Once we have the bugfix ready and instructions, I will contact our customers to let them know about the problem and how to apply the fix. Artur |
|
A few comments:
It could be possible, if data would be sent from malicious XMPP server over S2S. Then it could theoretically be possible to "embed" a stanza within element attribute value. However, to do so, you would need to use Due to that, I would say that impact on the users would be medium or low.
For Tigase XMPP Server, that would be enough. For XMPP clients based on tigase-xmltools, we would need to make a few changes - XMPP client may need to process received attribute value (unescape it). |
|
Therefore we should:
Regarding customer list, I assume this includes both those with ACS licence, support licence and also past clients (Alcatel, Epic for example?) |
|
(I manually changed visibility of the comments in this issue to "CoreTeam" in case we would make it public to avoid making the discussion public as well.) |
|
I would suggest to actually release 8.2.1 as while you can replace binaries, there will be issues, as users will not know that they are using patched version (or not). Also, docker/k8s caches images, so it will not fetch a new images with the same tag if it already has one. |
|
I wasn't suggesting replacing them inline, just removing it from 8.2.0 (while making 8.2.1) to avoid distributing (recently released) version with vulnerability. Same goes for docker images as per Artur's comment: "At the same time we should remove access to 8.2.0 build once the bugfix is released." - we would leave release page but remove binaries, hence "remove access". |
|
OK, understand. Thank you for explanation and clarification. So, maybe we should prepare following public releases at minimum:
That would cover most of known existing installations. I do not know what exact version of Tigase is used by our customers. They might have some custom builds. So, we should probably contact all of them and let them know about the issue and offer our help with updating their version. But that would be a custom build/work on base-by-case basis. |
|
I have prepared the following notice to our customers. Please take a look and let me know if all is correct and if you have suggestions to add/remove something:
|
|
The mail looks correct. In addition to preparing 8.2.1 and 7.1.7 release we can also prepare dedicated build of xml-tools (for drop-in replacement if some customers would prefer that). I'm pondering how we should handle preparation and distribution of the packages. Should we commit the fix with an inconspicuous description and prepare all the packages without making the fuss, notify the customers and let everyone update the installations? |
|
Yes, I think this is the right way to do it. And then, once we have contacted all our customers, and they updated their systems we can release a public announcement. |
|
Please let me know when the big fix versions are available and then I will send a message to our customers. |
|
Main releases:
Individual releases
@kobit those are draft releases for now, I wasn't sure what to put in the "Changes" section (or whether to include it at all (we could amend them after the public anouncement later on)? Either I can publish them or you can do it just before sending the notification to the customers. I'll prepare docker images once those are publish due to dependencies. |
|
Please put something general like "security bugfix in xmltools". This provides some basic information and suggestion for the public to update due to security issue without any specifics on the possible exploit. |
|
Releases made, tigase-xmltools:
tigase-server: |
|
7.1.7 rebuild 8.2.1 docker images published: https://hub.docker.com/r/tigase/tigase-xmpp-server/tags?page=1&name=8.2.1 |
|
Thank you. Notifications were sent out to all companies I could find that use(d) Tigase. Artur |
Type |
Bug
|
Priority |
Normal
|
Assignee | |
Version |
tigase-server-8.3.0
|
-
helpdesk/helpdesk-priv#825 You are not authorized to access this issue
-
helpdesk/helpdesk-priv#809 You are not authorized to access this issue
-
Customers/catapush-s-r-l#29 You are not authorized to access this issue
Tigase XMPP server suffers from a security vulnerability due to not escaping double quote characters when serializing parsed XML. This can be used to smuggle (or, if you prefer, inject) arbitrary attacker-controlled stanza in the XMPP server's output stream. A malicious client can abuse this vulnerability to send arbitrary XMPP stanzas to another client (including the control stanzas that are only meant to be sent by the server).
Consider for example the following XML tag
which contains a single attribute enclosed in single quotes.
When Tigase parses and then serializes the element, it will convert single quotes to double quotes, however it will not escape the double quote. Thus the output becomes
Which is invalid XML. The corresponding code for serializing attributes can be seen in https://github.com/tigase/tigase-xmltools/blob/b0c64df99f62b88bec7c152d52027369b6415ada/src/main/java/tigase/xml/Element.java#L845
To see how this issue can be used to smuggle arbitrary stanzas through the server, consider for example the following incoming stanza
When this stanza gets parsed by the server, the corresponding tree is
However, when such a stanza gets serialized and forwarded to the recipient client (or another XMPP server) it becomes
(single quoted attributes became double quoted) When the receiving client parses it, the corresponding tree is seen as
This works because, after the quote, we used '/>' instead of '>' and vice-versa to change the semantics of the closing tags.
As can be seen in the tree above, the receiving client will consider the iq tag (that was originally a part of the message body tree) as a new stanza at the same "depth" in the XML tree as the message stanza.
As mentioned above, this can be used to "smuggle" arbitrary stanzas through the XMPP server to the victim client. This can be used for message spoofing (making it appear a message was sent by a different sender), but also, depending on the XMPP extensions the client implements and what data is sent over XMPP, it can have impact beyond that (e.g. potentially redirecting the connection through a malicious XMPP server, code execution).