Re: Spoofing multicast addresses

From: Don Lewis (Don.Lewis@tsc.tdk.com)
Date: 01/10/01


From: Don Lewis <Don.Lewis@tsc.tdk.com>
Date: Tue, 9 Jan 2001 23:45:19 -0800
To: Mike Silbersack <silby@silby.com>, Wes Peters <wes@softweyr.com>

On Jan 10, 1:13am, Mike Silbersack wrote:
} Subject: Re: Spoofing multicast addresses
}
} On Wed, 10 Jan 2001, Wes Peters wrote:
}
} > Don Lewis wrote:
} > > A good reason for putting these checks in their present location is
} > > that it gets them out of the main code path. Under normal circumstances,
} > > the vast majority of the incoming packets will be for established
} > > connections and it wasteful to do unnecessary checking on these packets.
} >
} > But that is exactly NOT the case when being attacked with a SYN flood
} > or something like that. Perhaps it would be advantageous to trip a flag
} > if we hit the bandwidth limiting rate and do the checks much earlier only
} > if we're under attack?
}
} I'm not sure that really matters. Since (nearly) any packet will undergo
} the pcb lookup, reducing the overhead of multicast packets wouldn't make
} much difference - attackers can just use non-multicast packets.

Yup, if we're DoSed in one of these attacks because of the expense of
doing the PCB lookup before the source address check, then the attacker
just has to craft the packets so that they pass the filters.

I don't think an adaptive algorithm would be the way to go either. It's
just more code that the CPU would have to run and an attacker might be
able to keep things in the non-optimal state by varying the packet stream.

} Does anyone have an idea on what the performance impact of the multicast
} checks really is? Just having a single check at the top of the code would
} be nice from a readability standpoint.

The current checks are reasonably cheap, though I would really like to
add a check of the source address against the broadcast addresses of
each interface on the box. That could be quite a bit more expensive.

} Speaking of stream, I wonder if proper multicast checks are done for icmp
} responses. Hrm.

I'm pretty sure that UDP is handled OK, but it can't hurt to take another
look.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message



Relevant Pages

  • [UNIX] Security Flaws Found in Tinc
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... This section describes how Tinc secures forwarded packets. ... The aim of encryption is to make the data unreadable for anybody who does ... It does not prevent an attacker from modifying the data. ...
    (Securiteam)
  • Re: IPS Testing
    ... What if an attacker spoofs SQL Injection/XSS/CSRF ... payload within the packets that Nessus is sending. ... spoof every packets destined to their address ... buy it or download a solution FREE today! ...
    (Pen-Test)
  • Re: just an idea for packet protocol using ECB
    ... >> packets may be lost. ... the system would never shutdown if attackers kept ... The damage an attacker ... So each file transmission gets a session number. ...
    (sci.crypt)
  • Packet reordering and blocking problem at gigabit with 2.4 kernel
    ... I am developing application level multicast router with Xeon processor. ... The system lost lots of packets and reordered the packets, ... Every channel sends 6Mbps with 2048 bytes packet. ... I heard that SMP machines has inherant reordering issues, ...
    (Linux-Kernel)
  • Re: UDP multicast packets not seen on listening interface in BETA5
    ... > I'm having a bit of trouble with a program I wrote to listen for ... > the multicast packets, ... > Also I verified the program is indeed listening with sockstat: ...
    (freebsd-current)