- 精华
- 0
- 帖子
- 3322
- 威望
- 0 点
- 积分
- 3375 点
- 种子
- 589 点
- 注册时间
- 2013-2-21
- 最后登录
- 2025-1-11
|
发表于 2023-8-11 14:31 · 上海
|
显示全部楼层
I. Background
IPv6 packets may be fragmented in order to accommodate the maximum
transmission unit (MTU) of the network path between the source and
destination hosts. The FreeBSD kernel keeps track of received packet
fragments and will reassemble the original packet once all fragments
have been received, at which point the packet is processed normally.
II. Problem Description
Each fragment of an IPv6 packet contains a fragment header which
specifies the offset of the fragment relative to the original packet,
and each fragment specifies its length in the IPv6 header. When
reassembling the packet, the kernel calculates the complete IPv6 payload
length. The payload length must fit into a 16-bit field in the IPv6
header.
Due to a bug in the kernel, a set of carefully crafted packets can
trigger an integer overflow in the calculation of the reassembled
packet's payload length field.
III. Impact
Once an IPv6 packet has been reassembled, the kernel continues
processing its contents. It does so assuming that the fragmentation
layer has validated all fields of the constructed IPv6 header. This bug
violates such assumptions and can be exploited to trigger a remote
kernel panic, resulting in a denial of service.
IV. Workaround
Users with IPv6 disabled on untrusted network interfaces are not
affected. Such interfaces will have the IFDISABLED nd6 flag set in
ifconfig(8).
The kernel may be configured to drop all IPv6 fragments by setting the
net.inet6.ip6.maxfrags sysctl to 0. Doing so will prevent the bug from
being triggered, with the caveat that legitimate IPv6 fragments will
be dropped.
If the pf(4) firewall is enabled, and scrubbing and fragment reassembly
is enabled on untrusted interfaces, the bug cannot be triggered. This
is the default if pf(4) is enabled.
这就是具体更新内容，不过一般不会写给用户看的 |
|
川公网安备 51019002005286号
楼主
