interfaces ippp(4) and pppoe(4). Insufficient checking of options presented
by the peer may cause writing of copies of the malicious input beyond the
end of a buffer allocated for that purpose.
Issue found by pavel@
Fix from martin@
This is SA2006-019 (CVE-2006-4304)
- struct timeval time is gone
time.tv_sec -> time_second
- struct timeval mono_time is gone
mono_time.tv_sec -> time_uptime
- access to time via
{get,}{micro,nano,bin}time()
get* versions are fast but less precise
- support NTP nanokernel implementation (NTP API 4)
- further reading:
Timecounter Paper: http://phk.freebsd.dk/pubs/timecounter.pdf
NTP Nanokernel: http://www.eecis.udel.edu/~mills/ntp/html/kern.html
/sys/net/if_spppvar.h says:
"Lower layer drivers that are always ready to communicate
(like hardware HDLC) can shortcut pp_up from pp_tls,
and pp_down from pp_tlf."
When I follow those instructions, I get a kernel stack
overflow as soon as I open the HDLC device.
Here is the loop:
sppp_ioctl calls sppp_lcp_open
sppp_lcp_open calls sppp_open_event
sppp_open_event calls sppp_lcp_tls
sppp_lcp_tls calls pp_tls
pp_tls is the SHORTCUT to sppp_lcp_up
sppp_lcp_up calls spp_lcp_open
...and around we go until the stack overflows.
The fix is to reverse the order of the action (tls)
and the state change (from INITIAL to STARTING) in
sppp_open_event.
There is a similar loop during closing:
sppp_ioctl calls sppp_lcp_close
sppp_lcp_close calls sppp_close_event
spp_close_event calls sppp_lcp_tlf
sppp_lcp_tlf calls pp_tlf
pp_tlf is the SHORTCUT to sppp_lcp_down
sppp_lcp_down calls sppp_lcp_close
...and around we go until the stack overflows.
The fix is to reverse the order of the action (tlf)
and the state change (from STARTING to INITIAL) in
sppp_close_event.
Separately, while I was discovering this, I noticed
that pp_tlf was being called unconditionally rather
than first checking to see if it is NULL. pp_tlf
is a callout from sppp to the hdlc device driver.
Elsewhere in sppp, this is always checked for NULL
before calling it, and the comments in if_spppvar.h
imply that filling it in is optional.
From spppvar.h:
"These functions need to be filled in by the lower layer
(hardware) drivers if they request notification from the
PPP layer whether the link is actually required."
This clearly says that pp_tlf and pp_tls are optional
and so sppp must check before calling them.
- most of the kernel code will not care about the actual encoding of
scope zone IDs and won't touch "s6_addr16[1]" directly.
- similarly, most of the kernel code will not care about link-local
scoped addresses as a special case.
- scope boundary check will be stricter. For example, the current
*BSD code allows a packet with src=::1 and dst=(some global IPv6
address) to be sent outside of the node, if the application do:
s = socket(AF_INET6);
bind(s, "::1");
sendto(s, some_global_IPv6_addr);
This is clearly wrong, since ::1 is only meaningful within a single
node, but the current implementation of the *BSD kernel cannot
reject this attempt.
- and, while there, don't try to remove the ff02::/32 interface route
entry in in6_ifdetach() as it's already gone.
This also includes some level of support for the standard source
address selection algorithm defined in RFC3484, which will be
completed on in the future.
From the KAME project via JINMEI Tatuya.
Approved by core@.
the non point-to-point interfaces that has one queue, and one used by
the point to point interfaces that has two queues. No functional changes.
XXX: The ALTQ stuff makes the code ugly.
XXX: More cleanup to come
As long as we receive data from the peer, don't worry. When we have not
received anything within the "max_noreceive" period, we start sending LCP
echo requests and count them, until we receive an answer (or some data)
or the "maxalive" count of not answered echo requests is reached.
All this is checked at a global 10 seconds interval for all interfaces.
The "max_noreceive" period and the "maxalive" count are configurable per
interface.
Hopefully this will fix ALTQ for ISDN and PPPoE interfaces.
While there remove an unsued function which contained dubious code
(accessing interface queue internals w/o the proper macros).
- length was one off in names and secrets.
- add win 98 kludge but we keep it disabled for now.
- setup the authorization bit early so that we don't end up doing ppp
negotiations without authorization.
