MLD to Be Reconsidered?

This is guest post from Antonios Atlasis.

Following my September post about the connection between MLD and Neighbor Discovery, as well as Enno’s introduction about our upcoming talk at DeepSec, I would like to try to enlighten you about this with some technical details. First, we have some facts:

1. MLD is pre-enabled in most modern Operating Systems.
2. MLD traffic is sent out-of the-box during the stack initialization, as well as periodically.
3. They also interact with/respond to MLD Queries without any further configuration.

To run the tests, first we wrote down all potential security issues that may arise by (ab)using MLD, starting from the simple ones, like:

1. Which MLD version is used by default?
2. Are various nodes (routers/hosts) cross-compatible?
3. Can an attacker force nodes to use MLDv1 instead of MLDv2?

Then, some tests regarding the protocol inherent security restrictions:

1. What if the hop-limit is not set equal to 1?
2. What if there is no Hop-by-Hop with a Router Alert Option?
3. What if the source address is not a link-local address? By the way, just to mention that we found out that a very popular OS, under very specific circumstances, sends MLD Reports using its global unicast address as source address :).

Furthermore some flooding/fuzzing tests. For instance: Can we overload a router? (Yes, we can. including a Cisco ASR 1002…).

But the most important: can we, as attackers, use the protocol in the foreseen way and still be able to disrupt multicast communications, like video streaming? (Again, yes we can).

What about some vendor-specific technologies, like MLD Snooping? Remember, at the local link, if MLD Snooping is not enabled, multicasting traffic is actually broadcasted.

The results are quite interesting. The most important of them can be summarised as follows:

• Not all OSs implement MLDv1/v2 in a fully RFC compliant way.
• Flooding attacks, resource consumption attacks, etc. are possible, both against hosts, routers or the network itself!
• MLD allows you to break its proper operation by using its own design (this is true for both MLDv1 and MLDv2). This, in my opinion, implies revision of the standards of the protocol.

In our talk, we will not only provide much more details about the above, but, moreover, we will give some live demos regarding the most significant security issues.

So, must MLD be reconsidered? Let’s discuss it at DeepSec!

Are you interested in a broader-range IPv6 Security Training? Join our workshop on IPv6 security.

See you in Vienna!

Antonios