There is well known problem arp poisoning problem in FreeBSD. If arp reply is received without request FreeBSD logs error into syslog, but changes arp table entry. It makes possibility for local atacker to change arp cache entry. In network this behaviour can only occure when adapter changes it's MAC address. This like a linux kernel patch (2.4.18 and .19 tested) to resisting ARP spoofing - http://groups.google.com/groups?selm=001901c28c23%2414c08320%240101fea9%40r66.ru&oe=UTF-8&output=gplain Fix: Attached is patch to check old MAC address before changing arp entry by sending unicast arp request to this MAC. If old MAC replies, no changes to arp table is made and attack is logged. [PATCH] How-To-Repeat: n/a
Responsible Changed From-To: freebsd-bugs->bms I'll try to look at this
Here's a cleaned up version of your patch which works against FreeBSD-CURRENT. I have mixed feelings about committing this; it raises the bar somewhat but it does not completely close the hole. Let's say Alice and Bob are talking to each other with IPv4 over Ethernet. Making the arp cache entry permanent is probably a bad idea for Alice. She should be allowed to expire out the entry at some point, which admittedly provides a window for the cache poisoning attack, but the potential for abuse is increased if the attacker is able to race Bob in creating the original entry in Alice's cache. I've attempted to mitigate this by using a simple linearly computed threshold, but this still doesn't really solve the problem. Might suggest we review the following papers on the subject: http://www.cs.utexas.edu/users/chuang/comnet0103.pdf http://www.acsac.org/1999/papers/fri-b-0830-dutta.pdf http://alor.antifork.org/projects/s-arp/article.pdf And code: http://alor.antifork.org/projects/s-arp/sarpd-0.0.9-devel.tar.gz The daemon above could probably be adapted for *BSD use by setting IFF_NOARP on an Ethernet network interface, removing the subnet route and re-adding it with RTF_XRESOLVE|RTX_CLONING, and adding bpf/rtsock support to the userland code. Also, please clarify your license regarding this code, I am assuming that it was submitted under the BSD license. Regards, BMS
State Changed From-To: open->analyzed Full analysis to follow
Hello, freebsd-gnats-submit. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60293 Also, please clarify your license regarding this code, I am assuming that it was submitted under the BSD license. -- WBR, Bert
Unfortunately I have replaced a place of work. Old email brj@vzletka.net - was removed by my employer. Please use current email to follow up the PR. -- Roman Y. Bogdanov /"\ ASCII RIBBON Campaign http://brj.pp.ru/ \ / NO HTML/PDF/RTF in e-mail + 7 3912 541843 [work, office] X NO MSWord docs in e-mail + 7 3912 505653 [personal, mobile] / \ NO attachments in e-mail
State Changed From-To: analyzed->suspended Not ready for prime time, IMHO.
Responsible Changed From-To: bms->freebsd-net Disowning it due to lack of cycles/focus.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Fixed long time ago with introduction of "ifconfig staticarp" option.