[openbeosnetteam] Re: DHCP Stay Alive Question
- From: "David Enderson" <DEnderson@xxxxxxxxxxxxxx>
- To: <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Mon, 25 Oct 2004 15:49:06 -0500
Waldemar,
> A crash in the kernel is very critical. If we move code from
> kernel to userland we lower the risk of a full system crash.
> I do not know very much about DHCP and how big it is, so
> maybe it does not harm putting it into the kernel (if it
> really is small) as bugs are rather unlikely. ZeroConf can
> use the kernel module as if it were part of the stack, I do
> not see any problem with DHCP not being integrated enough.
>
I understand your concerns about "sandboxing" as much as possible to
limit security and stability vulnerability. I can't take sides in this
argument because you guys are the ones to know about how your networking
and the kernel works.
I can, however, share some knowledge regarding DHCP. Regarding size...I
can't say whether it will be "big" or "small" since I don't know what it
would be compared with. All DHCP communication is with UDP packets that
are a minimum of 236 bytes each. They can be longer since the last
field "options" has an undefined length, but the "options" field is
optional in most or all of the packets. (I'm currently confused as to
whether one type of packet should be sending a key piece of information
in that field.) In the case of most of the packets I can take only the
first 236 bytes and be just fine. So it seems to me that buffer
overflows are less of an issue in this case because if we guard against
oversized packets and just reject packets less than 236 bytes in length,
we will be just fine.
The client sends a 236 byte UDP packet configured to certain specs,
waits for a response, then evaluates the response based on bytes placed
in various offsets in the 236 byte response packet. It would be hard to
cause problems because the incoming bytes I check for values either
contain IP
addresses or something like a 1 or a 2. So as long as I end if
statements with an else that fails, I don't see a big chance for
crashing the system or exploitation.
With that said, obviously any code needs to be hardened and polished,
but I think the level of complexity that can cause loopholes or complex
crashing issues is low. That's why I took on this project. :-) It is
more busy work with branching the logic for various packet responses,
than super techie stuff. That's why--if it is big by the project's
standards--it won't be complex and big. It would only be big because of
a number of different possible outcomes.
Does that information help this discussion any? :-)
--David
Other related posts:
