REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4541
REF: https://www.rfc-editor.org/rfc/rfc1948.txt
REF: https://www.rfc-editor.org/rfc/rfc6528.txt
REF: https://www.rfc-editor.org/rfc/rfc9293.txt
Bug Overview:
PixieFail Bug #8
CVE-2023-45236
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
Updates TCP ISN generation to use a cryptographic hash of the
connection's identifying parameters and a secret key.
This prevents an attacker from guessing the ISN used for some other
connection.
This is follows the guidance in RFC 1948, RFC 6528, and RFC 9293.
RFC: 9293 Section 3.4.1. Initial Sequence Number Selection
A TCP implementation MUST use the above type of "clock" for clock-
driven selection of initial sequence numbers (MUST-8), and SHOULD
generate its initial sequence numbers with the expression:
ISN = M + F(localip, localport, remoteip, remoteport, secretkey)
where M is the 4 microsecond timer, and F() is a pseudorandom
function (PRF) of the connection's identifying parameters ("localip,
localport, remoteip, remoteport") and a secret key ("secretkey")
(SHLD-1). F() MUST NOT be computable from the outside (MUST-9), or
an attacker could still guess at sequence numbers from the ISN used
for some other connection. The PRF could be implemented as a
cryptographic hash of the concatenation of the TCP connection
parameters and some secret data. For discussion of the selection of
a specific hash algorithm and management of the secret key data,
please see Section 3 of [42].
For each connection there is a send sequence number and a receive
sequence number. The initial send sequence number (ISS) is chosen by
the data sending TCP peer, and the initial receive sequence number
(IRS) is learned during the connection-establishing procedure.
For a connection to be established or initialized, the two TCP peers
must synchronize on each other's initial sequence numbers. This is
done in an exchange of connection-establishing segments carrying a
control bit called "SYN" (for synchronize) and the initial sequence
numbers. As a shorthand, segments carrying the SYN bit are also
called "SYNs". Hence, the solution requires a suitable mechanism for
picking an initial sequence number and a slightly involved handshake
to exchange the ISNs.
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
According to UEFI spec 2.10, the definition of RFC1323
has changed to RFC7323 on EFI_TCP6_OPTION. So align this
change on NetworkPkg.
REF: UEFI spec 2.10 section 28.2.5
Signed-off-by: Suqiang Ren <suqiangx.ren@intel.com>
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
Fixes CodeQL alerts for CWE-457:
https://cwe.mitre.org/data/definitions/457.html
Cc: Erich McMillan <emcmillan@microsoft.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Co-authored-by: Erich McMillan <emcmillan@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the NetworkPkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3739
Update all use of EFI_D_* defines in DEBUG() macros to DEBUG_* defines.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Fix various typos in documentation, comments and debug strings.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@intel.com>
Signed-off-by: Antoine Coeur <coeur@gmx.fr>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-49-philmd@redhat.com>
1. Do not use tab characters
2. No trailing white space in one line
3. All files must end with CRLF
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
TCP payload check is implemented by TcpVerifySegment(), but all the function
calls of TcpVerifySegment() are placed in ASSERT(), which is only valid for
debug version:
ASSERT (TcpVerifySegment (Nbuf) != 0);
This patch is to enable the check for release version.
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wang Fan <fan.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Moving Right window edge to the left on sender side without additional check
can lead to the TCP deadlock, when receiver ACKs proper segment, while sender
discards it for future ACK. To prevent this add check if usable window (or
shrink amount in this case) is bigger then receiver's window scale factor.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrey Tepin <atepin@kraftway.ru>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Tcp driver need to use EFI_D_NET to log DEBUG message,
So it becomes easy to separate/filter out debug messages
from network stack versus generic EFI_D_INFO debugs.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Cc: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Cc: Subramanian Sriram <sriram-s@hpe.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Reviewed-by: Sriram Subramanian <sriram-s@hpe.com>
Consider the situation as shown in below chart. The last ACK message has
acknowledged the Tcb->RcvWl2, and all the segments until Tcb->RcvNxt have
been received by TCP driver. The Tcb->RcvNxt is not acknowledged due to the
delayed ACK. In this case an incoming segment (Seg->Seq, Seg->End) should
not be accepted by TCP driver, and an immediate ACK is required.
Current TcpSeqAcceptable() thought it’s an acceptable segment incorrectly, it
continues the TcpInput() process instead of sending out an ACK and droping the
segment immediately.
Tcb->RcvWl2 Tcb->RcvNxt Tcb->RcvWl2 + Tcb->RcvWnd
Seg->Seq Seg->End | |
| | | | |
---+-----+---------------+-------------+--------------------------+-----------
<income segment> <----Acceptable Range--- -->
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-By: Eugene Cohen <eugene@hp.com>
Reviewed-By: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-By: Ye Ting <ting.ye@intel.com>
Arbitrary length of packet may be received from network, including the
packets with zero payload data or malformed protocol header. So the code
much check the actually received data size before using it. For example, in
current edk2 network stack, an zero payload UDP packet may cause the
platform ASSERT in NetbufFromExt() because of the zero fragment number.
This patch update the IpIoLib and UdpIoLib to check and discard the zero
payload data packet to avoid above assert. Some other network drivers are
also updated to check the packet size to guarantee the minimum length of
protocol header is received from upper layer driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Sriram Subramanian <sriram-s@hpe.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>