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=67353#comment-67353 ] 

Dominik Obermaier commented on MQTT-505:

If the Server is free to terminate the enhanced authentication at any point (e.g. after the client sent PUBLISH messages before the enhanced authentication is finished), this issue can be disregarded. A non-normative comment would be helpful, as it may not be obvious without further context that such a terminating behavior is valid in case the client sends too much data before the authentication is finished.

> 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

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