I know we discussed this shortly on the groupchat, but I thought I’'d bring it up here for ideas/suggestions.
Currently, if Smack receives XML it can’'t parse (not well formed, etc), you get disconnected. Is there any way around this? Anyone that knows that this is true can disconnect you at any time using their XML console from almost any client.
Thanks,
Adam
Hmm, yes, I can see that can be a problem. I can’‘t think of a particularly nice solution to do this using Smack, but one thing you can do is to modify the source so that if the XML parser fails, it can return null (and then ignore null values from the XML parser). Just an idea. I’'m sure someone has a better one.
That seems to be serious issue.
Any application written with this API will be vulnerable to attacks. I am just beginning to learn the API.
Can we plug-in a different xml parser in API or something? (Just a thought)
It shouldn’‘t be an exploitable problem, because a good Jabber server won’'t pass along malformed XML.
This is not to say that “should” and “unexploitable” cover all the bases.
There’‘s only one case that I can think of that would be a problem, which is that Smack isn’'t likely doing namespace checking when looking for closing elements. If it was, than a server should make sure that everything else is well-formed.
-Matt
Well, the following packet kills smack - just as an example:
/code
Message was edited by:
synic
When you say “kill,” do mean drops the connection or causes the jvm to dump core?
My eyes must be getting blurry, but it doesn’'t look like the packet is ill formed.
Noah
It drops the connection. The part that causes the problem is the ****[/code] inside
Message was edited by:
synic
Message was edited by:
synic
its not exactly ill-formed, as in all of the openings and closings aren’‘t there but there shouldn’'t be any html inside of a body, it should be inside of an xhtml extension
Yes, it sure should, but it still causes smack to disconnect. Anyone that knows about this can cause any smack client to go offline.
If this message is in a muc history, it will also cause any smack client to disconnect if they attempt to join that muc.
Do think that’'s what caused the google wednesday chat server crash?
Noah
Yea, i realize this, I should of clarified, I was just trying to point out what was wrong with the packet you posted. I’‘m 1000% with you on this. Didn’'t even think about the muc history case too.
Is there any update on this problem? It seems to be known enough that I’'ve heard of a few instances of people using this to be… quite annoying.
Seeing a whole group chat being crashed cause of this flaw would seem to me of some great importance.
Just wondering if this is being looked into at all. Nothing on these boards show a whole lot of effort being put into this.
Sorry if I sound like I am complaining… You guys do a great job with this library and I wish to be able to contribute in some way soon.
BIG Thanks in advance,
Aaron
I was only asking if there was a correlation…be mindful that you don’'t make the assumption that one necessarily caused the other.
Noah
I did not aim this towards the google chat on wensday. This seems to be the case with any client created with the smack api.
Be it a simple one to one message or a Group Chat. The malformed xml packet still closes anyones client who receives it.
If anything… I am just curious that something is being done on the smack side of this.
noahcampbell: I wasn’‘t commenting on your particular correlation about last weeks chat. I didn’'t even make it in time for the meeting, so I did not witness it go down.
rgrds,
Aaron
A possible solution to this would be to write a PacketErrorHandler interface that receives the stack trace and packet when a packet parsing error occurs. There will then be a default one that perhaps logs it in the debugger and client developers can write ones of their own that drop’'s the connection or chucks the packet, whatever they would like.