[Security] upcoming DEFCON talk

Jonathan Dickinson jonathan.dickinson at k2.com
Wed Jun 24 03:01:12 CDT 2009


> -----Original Message-----
> From: security-bounces at xmpp.org [mailto:security-bounces at xmpp.org] On
> Behalf Of Peter Saint-Andre
> Sent: 24 June 2009 12:24 AM
> To: XMPP Security
> Subject: [Security] upcoming DEFCON talk
> 
> I take a look at how those issues
> play out in IM clients and open source servers.

Do we have any recommendations on how to avoid things like this? A few things that come to mind (given that stanzas SHOULD NOT be more than 64kb IIRC).

All of these should be configurable and removable (XML/DB configuration). They only deal with the XMPP side of things (e.g. excluding Jingle RTP servers etc.)

Memory consumption:
- QNames should not exceed e.g. 64 chars
- Attribute values should not exceed e.g. 1024 chars
- Element text (and CDATA if supported by the parser) should not exceed e.g. 30720 chars
- PI (if supported) should not exceed 1024 chars
- DOCTYPE (if supported) should not exceed 1024 chars
- Node nesting depth should not exceed e.g. 100 nodes

'Strobing' the server with excessive stanzas:
- Up/down speed may only exceed e.g. 10kbps for e.g. 10 seconds.
  - Client may request a grace period, and can only continue with high bandwidth usage when the server sends the 'go ahead' stanza.

Undefined behaviour:
- Server should immediately disconnect client if the document root element is not recognised.

General DOS:
- Client has e.g. 10 seconds grace between individual stream features.
- A single account may not have more than e.g. 10 active connections.
- No more than e.g. 3 S2S connections can be made from one source (do not ban server, rather just immediately close any further connections).

Any other ideas?

> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/

Jonathan
http://jonathan.dickinsons.co.za/blog


More information about the Security mailing list