Subject: [BEHAVE] LENGTH field and possible Denial Of Service even with MESSAGE-INTEGRITY

From: "Mayank Dev Sondhi" <[email-masked]>
Date: Sun, 25 Mar 2007 23:12:24 +0530

I was thinking about this for a little while, and this thought crossed my
mind. In say a normal attack scenario, in some cases fiddling with the
length value for a STUN message can very easily lead to a denial of Service
to the client. This is especially true for a TCP/STREAM protocol oriented
approach.

For example,
Let us say the server uses the Length field in a STUN packet to find out
where the MESSAGE-INTEGRITY field is, in most cases there is no other way
that the server can do this apart from using the LENGTH field.

A malicious user can always extend the field length(the MI would be wrong of
course) to an arbitrarily large value. What would happen is that if the
server uses a buffer length of say X for receiving from its socket, on
receipt of a length value >> X it will assume that more data needs to be
buffered, it will thus wait for the client to send more, but from the
client's perspective it is waiting for a server response(since it had sent a
valid request). Ultimately the server or the client would abort the
connection and most probably retry again. It would take some trials for a
malicious/rogue attacker, to figure out a large enough len value but it is
possible.

So my question is this, would it be possible to "protect" against this
situation? The framing approach describe in draft version 2 and 3 also would
not help as it is trivial to increase the length in the frame AND the STUN
message. One possible way of protection is having the MI BEFORE the Length
attribute in the STUN packet.

Does this analysis seem feasible? Am I potentially barking up a wrong tree??
:-) What other measures can be taken to protect against this? Are there some
rough BEHAVE guidelines that can nullify this threat?

Thanks
Mayank
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Mar 2007 22:13:57 -0400

Mayank Dev Sondhi wrote:

> I was thinking about this for a little while, and this thought crossed 
> my mind. In say a normal attack scenario, in some cases fiddling with 
> the length value for a STUN message can very easily lead to a denial of 
> Service to the client. This is especially true for a 
> TCP/STREAM protocol oriented approach.

I think your attack is specific to TCP.

> where the MESSAGE-INTEGRITY field is, in most cases there is no other 
> way that the server can do this apart from using the LENGTH field.
>  
> A malicious user can always extend the field length(the MI would be 
> wrong of course) to an arbitrarily large value. What would happen is 
> that if the server uses a buffer length of say X for receiving from its 
> socket, on receipt of a length value >> X it will assume that more data 
> needs to be buffered, it will thus wait for the client to send more, but 
> from the client's perspective it is waiting for a server response(since 
> it had sent a valid request). Ultimately the server or the client would 
> abort the connection and most probably retry again. It would take some 
> trials for a malicious/rogue attacker, to figure out a large enough len 
> value but it is possible.

I'm missing something here. If the client is malicious, it will only end 
  up messing up the framing between itself and the server, so what is 
the point of that. If you are talking a MITM, you would mitigate this 
with TLS and so the STUN would be protected by TLS.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Mayank Dev Sondhi" <[email-masked]>
Date: Tue, 27 Mar 2007 22:13:41 +0530

> I think your attack is specific to TCP.

Yes it is.

> with TLS and so the STUN would be protected by TLS.

Yes this is relative to MITM, TLS for ALLOCATEs is too heavy I presume? Or
would TLS be used for ALLOCATIONs also? What about SEND requests? Wouldn't
SENDs and data streaming be overtly burdensome for a server over TLS?

-Jonathan R.

Thanks
Mayank

---

From: Philip Matthews <[email-masked]>
Date: Wed, 28 Mar 2007 18:53:19 -0400

I see two possible attacks here.

In the first attack, a client executes the following code against a  
given STUN server
	loop
		Allocate a local port
		Open a TCP connection to the server
		Send a Binding Request
	end loop
If a number of clients execute this attack simultaneously, this will  
quickly consume TCP Control Blocks and perhaps other resources on a  
STUN server.

The WRONG way to protect against this attack is for the server to  
close the connection after sending the Binding Response. This is  
wrong because a normal client doing ICE, for example, will need to  
hold the connection open as a way of preserving the NAT binding while  
it does an ICE exchange with some other node.

One way to protect against this attack might be to limit the number  
of TCP connections that a server will accept from the same address.  
It is not clear to me right now what that limit should be, however.

The second attack is a variation on the first.
Each client executes the following code:
	loop
		Allocate a local port
		Open a TCP connection to the server
		Send most (but not all) of a large Binding Request message
	end loop
There are a number of ways a large Binding Request message could be  
constructed: using very long user-names; including unknown  
attributes, etc.
This attack will often chew up even more resources on a server,  
because it must hold data about the partly received Binding Request  
before it can send the response.

- Philip