OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (MQTT-505) Denial of Service Attacks possible


    [ https://issues.oasis-open.org/browse/MQTT-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=67350#comment-67350 ] 

Ken Borgendale commented on MQTT-505:
-------------------------------------

Nothing in this spec stops the server from simply not reading from the TCP connection between receiving a CONNECT and sending a CONNACK except in the case of enhanced authentication.  

In the case of  enhanced authentication, this is started by the client sending an AuthenticationMethod property in the CONNECT.  If the client does not do this, it cannot later send an AUTH packet.  The Client is only allowed to send an AUTH packet in response to the Server sending an AUTH packet until after it has received a CONNACK   The Server is free to terminate the enhanced authentication at any point, and the assumption is that it would in the case that it gets some other packet when expecting an AUTH packet.  If we believe this is not clear we can clarify it with a non-normative comment.  

In the case of reauthentication we specifically allow the AUTH to be interspersed with other packets, but there we assume that the connection is already authorized.

> Denial of Service Attacks possible 
> -----------------------------------
>
>                 Key: MQTT-505
>                 URL: https://issues.oasis-open.org/browse/MQTT-505
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>    Affects Versions: 5, CSD01
>            Reporter: Dominik Obermaier
>
> The current state of the MQTT 5 specification states in Line 1007:
> {quote}
> Clients are allowed to send further MQTT Control Packets immediately after sending a CONNECT packet; Clients need not wait (sic!) for a CONNACK packet to arrive from the Server. If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets.
> {quote}
> This behavior may be used for Denial of Service attacks. Consider the following scenario:
> 1. A malicious client connects to the Broker and sends an invalid CONNECT packet
> 2. The server has a complex authentication mechanism and it may take up to several seconds (or even longer!) until the validity of the CONNECT can be determined
> 3. The malicious client bombards the server with PUBLISH packets
> 4. The broker must queue all these messages until the CONNECT returns. The broker implementation *can't* stop to read from the socket (and thus apply TCP backpressure to the client) since an AUTH packet could be sent by the client.
> MQTT 3.1.1 also allowed unauthenticated clients to send data, the broker implementation could stop to read from the socket until the CONNACK packet is produced.
> To solve the issue, a proposal could be: 
> {quote}
> The Server MAY discard any packets sent by the Client prior to a successful authentication.
> {quote}
> A non-normative comment could be added, that a broker may decide to use a bounded queue for "holding back" the data. If the queue is full, the PUBLISH messages (or other packets) could be dropped and an error code "0x97 - Quota exceeded" could be included in the ACK (e.g. PUBACK, ...). 
> A slightly better approach to fix this problem would be to disallow the sending of any packets before all AUTH packets are exchanged.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]