Date: Thu, 23 Dec 1999 15:43:28 +0100 (MET) From: Mikko T <mikko@mikko.dynas.se> To: wpaul@skynet.ctr.columbia.edu Cc: freebsd-current@freebsd.org Subject: Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents) Message-ID: <199912231443.PAA12108@mikko.dynas.se> References: <199912230641.WAA16876@apollo.backplane.com> from "Matthew Dillon" at Dec 22, 99 10:41:13 pm <199912230700.CAA10582@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Just a quick note, not entirely on-topic:
Bill Paul wrote:
[...]
>Yes, I know there's a minimum frame length of 60 bytes. And the rl_encap()
>routine has the following code:
> /* Pad frames to at least 60 bytes. */
> if (m_head->m_pkthdr.len < RL_MIN_FRAMELEN) {
> m_head->m_pkthdr.len +=
> (RL_MIN_FRAMELEN - m_head->m_pkthdr.len);
> m_head->m_len = m_head->m_pkthdr.len;
> }
[...]
>60 bytes, I just adjust bump up m_pkthdr.len and m_len. This adjuster
>length gets used later in rl_start() when transmission is triggered.
I haven't read through the code yet, so I don't know where the extra
memory in that buffer originated from, or rather if it has been zeroed
before reaching this point. Otherwise you are leaking data from the
kernel out to the network.
Other OSes have done this before. It can be used for "data fishing"
by just pinging the machine. Eventually it turns up all sorts of
interesting information ([partial] passwords, for example).
How many other NICs are unable to auto-pad, and how many of the
drivers just add "random" data that happened to be laying around
inside the kernel...?
Just curious,
/Mikko
(Off to make sure that if_ed in my home firewall isn't doing
anything like this...)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912231443.PAA12108>