zeen

Peter asked me to post a summary of the pre-image attacks I found and the discussion which followed, so here it is.

== Introduction ==

On reading XEP-0115: Entity Capabilities, I discovered that it is trivially easy to do a preimage attack. That is, given a service discovery response, it is trivially easy to create a different service discovery response which has the same verification string. This can obviously be used to poison caps caches, effectively eliminating any security advantage of using hashes.

=== Attack 1 ===

<identity category='client' type='pc' name='SomeClient'/> <feature var='http://jabber.org/protocol/muc'/>

zeen

<iq from="conference.jabber.org" to="waqas@example.com/resource" id="x" type="result">
  <query xmlns="jabber:iq:register">
    <registered />
    <instructions>You need an x:data capable client to register nickname</instructions>
    <x xmlns="jabber:x:data">
      <title>Nickname Registration at conference.jabber.org</title>
      <instructions>Enter nickname you want to register</instructions>
      <field type="text-single" label="Nickname" var="nick">
        <value>waqas</value>
      </field>

zeen

meta = {
	display = "Name visible in UIs";
	name = "name_in_code";
	type = "object";
	properties = {
		{
			display = "Call my function";
			name = "myFunc";
			type = "function";
			parameters = {

zeen

-- this module is global
module.host = "*";

-- list of hosts on which to add the component
local hosts = {
	["example.com"] = true;
	["myhost.com"] = true;
};

-- the jid of the component

zeen

-- mod_discoitems.lua
--
-- In the config, you can add:
--
--   disco_items = {
--     {"conference.jabber.org", "The Jabber.org MUC"};
--     {"muc.example.com", "An example MUC"};
--   };
--

zeen

Concerns about IO Data

I unfortunately missed the community conversation about the XEP up until now.

I have been working with web services (XML-RPC, SOAP, etc), and have concerns about the custom protocol in the IO Data XEP.

I'll be comparing IO Data with SOAP, and highlighting the various shortcomings. I'm not comparing it with the existing SOAP over XMPP XEP mind. I'm inclined more towards using Ad-Hoc Commands, but with SOAP payloads instead of IO Data.

The IO Data rationale for not using SOAP

zeen

This is a regular paragraph.

Foo

This is another regular paragraph.

zeen

<presence from="user@gafyd.host/BlackBerry01ECA931" to="me@my.host/resource" xmlns:ns3="urn:ietf:params:xml:ns:xmpp-stanzas" xmlns:ns4="urn:ietf:params:xml:ns:xmpp-streams" xmlns:ns5="jabber:iq:auth" xmlns:ns6="jabber:iq:roster" xmlns:ns7="google:roster" xmlns:ns8="jabber:iq:privacy" xmlns:ns9="urn:ietf:params:xml:ns:xmpp-tls" xmlns:ns10="urn:ietf:params:xml:ns:xmpp-sasl" xmlns:ns11="urn:ietf:params:xml:ns:xmpp-bind" xmlns:ns12="vcard-temp" xmlns:ns13="vcard-temp:x:update" xmlns:ns14="jabber:x:event" xmlns:ns15="http://jabber.org/protocol/caps" xmlns:ns16="http://jabber.org/protocol/muc#user" xmlns:ns17="http://jabber.org/protocol/commands" xmlns:ns18="google:nosave" xmlns:ns19="google:subscribe" xmlns:ns20="http://jabber.org/protocol/disco#info" xmlns:ns21="http://jabber.org/protocol/disco#items" xmlns:ns22="google:shared-status" xmlns:ns23="google:jingleinfo" xmlns:ns24="jabber:x:delay" xmlns:ns25="google:domain" xmlns:ns26="http://www.google.com/session" xmlns:ns27="http://www.google.com/session/share" xml

zeen

waqas Today   7:07 PM 
Hello again.

Neustradamus Today   7:07 PM 
:)
Today   7:07 PM 
So I spoke with mwild

Today   7:07 PM 
but you are windows developper

zeen

diff -r 93a94ec05ebe util/stanza.lua
--- a/util/stanza.lua   Sun Oct 04 22:12:12 2009 +0500
+++ b/util/stanza.lua   Sun Oct 04 23:07:05 2009 +0500
@@ -122,7 +122,7 @@
        local escape_table = { ["'"] = "&apos;", ["\""] = "&quot;", ["<"] = "&lt;", [">"] = "&gt;", ["&"] = "&amp;" };
        return function(str) return (s_gsub(str, "['&<>\"]", escape_table)); end
 end)();
-local function _dostring(t, buf, self, xml_escape)
+local function _dostring(t, buf, self, xml_escape, parentns)
        local nsid = 0;