[Standards] XEP-0045 1.25rc7

Peter Saint-Andre stpeter at stpeter.im
Tue Nov 8 00:17:01 UTC 2011


On 10/6/11 4:36 AM, Alexander Holler wrote:
> Am 05.10.2011 21:56, schrieb Mike Wacker:
>> On 10/4/2011 11:15 AM, Alexander Holler wrote:
>>>> If the server never times out a room that is created but not configured
>>>> and unlocked, then an easy DOS vector is to flood the server with room
>>>> creation requests but never configure any of the rooms. Since these
>>>> unconfigured rooms never time out, these creation requests will
>>>> eventually starve the server of resources. Throttling won't work here,
>>>> as it will slow but not stop the eventual starvation.
>>>>
>>>> Two mitigations would be to either time-out unconfigured rooms or put a
>>>> cap on the number of unconfigured rooms a single user can create. You
>>>> could also have a max cap of total rooms for all users, but that also
>>>> has DOS implications because even if malicious users can't DOS the
>>>> server, they can DOS other users trying to create rooms if they can hit
>>>> the server cap.
>>>
>>> Whats the difference between unconfigured and configured rooms?
>>>
>>> It's as easy to DOS a server with configured rooms as with
>>> unconfigured rooms and it will cost a malicious client almost nothing
>>> to configure a room along with the creation.
>>>
>>> Regards,
>>>
>>> Alexander
>> Good call, Alexander, my initial line of inquiry began with the question
>> of what if a malicious client intentionally did not configure the room,
>> but configuring the room does not make the problem go away.
>>
>> In fact, configured rooms present additional complications. If a user
>> sends an occasional message to each room after its unlocked, this would
>> also with little cost to the hacker would prevent the server from timing
>> out and destroying the room due to inactivity.

That's not an attack we've seen in the wild, as far as I know.

> The solution is simple, a (service global) limit for ownerships in rooms.

XEP-0045 doesn't cover service-global features. We've always said we
might write a spec about that, though.

Peter

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





More information about the Standards mailing list