Copied from https://bugzilla.tianocore.org/show_bug.cgi?id=4206
Summary
A malicious iSCSI target can cause a remote BIOS to reveal its memory contents with a specially crafted R2T message.
Details
The following function is used to process iSCSI "Ready To Transfer" (R2T) PDUs that were received from the iSCSI target. An offset and length value are extracted from the R2T header, which are both 32-bit unsigned integers.
Below, the highlighted line may be subject to an integer overflow if either Offset or DesiredLength are excessively large. This would bypass the input validation, and would result in the Data being advanced beyond the end of the packet's output data buffer.
EFI_STATUS
IScsiOnR2TRcvd (
IN NET_BUF *Pdu,
IN ISCSI_TCB *Tcb,
IN UINT64 Lun,
IN OUT EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET *Packet
)
{
...
R2THdr = (ISCSI_READY_TO_TRANSFER *) NetbufGetByte (Pdu, 0, NULL);
...
R2THdr->BufferOffset = NTOHL (R2THdr->BufferOffset);
R2THdr->DesiredDataTransferLength = NTOHL (R2THdr->DesiredDataTransferLength);
...
XferContext->Offset = R2THdr->BufferOffset;
XferContext->DesiredLength = R2THdr->DesiredDataTransferLength;
// NCC: integer overflow on following line
if (((XferContext->Offset + XferContext->DesiredLength) > Packet->OutTransferLength) ||
(XferContext->DesiredLength > Tcb->Conn->Session->MaxBurstLength))
{
return EFI_PROTOCOL_ERROR;
}
// NCC: Data point may be advanced too far if Offset is large
Data = (UINT8 *) Packet->OutDataBuffer + XferContext->Offset;
Status = IScsiSendDataOutPduSequence (Data, Lun, Tcb);
...
EDK2/NetworkPkg/IScsiDxe/IScsiProto.c
The tainted Data pointer is then passed to the following function, which builds and sends the response message. The response message may consist of multiple PDUs, which are generated from Data by the IScsiGenerateDataOutPduSequence() function and transmitted by the TcpIoTransmit() function.
Additionally, note that the Offset and DesiredLength fields in the Tcb->XferContext structure are tainted and are attacker-controlled.
EFI_STATUS
IScsiSendDataOutPduSequence (
IN UINT8 *Data,
IN UINT64 Lun,
IN ISCSI_TCB *Tcb
)
{
...
// Generate the Data Out PDU sequence.
DataOutPduList = IScsiGenerateDataOutPduSequence (Data, Tcb, Lun);
...
// Send the Data Out PDU's one by one.
NET_LIST_FOR_EACH (Entry, DataOutPduList) {
Pdu = NET_LIST_USER_STRUCT (Entry, NET_BUF, List);
Status = TcpIoTransmit (&Tcb->Conn->TcpIo, Pdu);
...
}
...
Inside IScsiGenerateDataOutPduSequence(), we see a fairly straight forward while-loop that walks Data up to its maximum length of XferContext->DesiredLength (an attacker-controlled value), breaking it down into PDUs that are each no larger than Conn->MaxRecvDataSegmentLength.
LIST_ENTRY *
IScsiGenerateDataOutPduSequence (
IN UINT8 *Data,
IN ISCSI_TCB *Tcb,
IN UINT64 Lun
)
{
LIST_ENTRY *PduList;
UINT32 DataSN;
UINT32 DataLen;
NET_BUF *DataOutPdu;
ISCSI_CONNECTION *Conn;
ISCSI_XFER_CONTEXT *XferContext;
UINT8 *DataOutPacket;
PduList = AllocatePool (sizeof (LIST_ENTRY));
...
InitializeListHead (PduList);
...
Conn = Tcb->Conn;
...
XferContext = &Tcb->XferContext;
while (XferContext->DesiredLength > 0) {
// Determine the length of data this Data Out PDU can carry.
DataLen = MIN (XferContext->DesiredLength, Conn->MaxRecvDataSegmentLength);
// Create a Data Out PDU.
DataOutPdu = IScsiNewDataOutPdu (Data, DataLen, DataSN, Tcb, Lun);
...
InsertTailList (PduList, &DataOutPdu->List);
// Update the context and DataSN.
Data += DataLen;
XferContext->Offset += DataLen;
XferContext->DesiredLength -= DataLen;
DataSN++;
}
...
Based on this, it appears that the Data pointer can be read out of bounds, and the OOB memory will be copied into the response PDU and transmitted to the iSCSI target. This constitutes a remote memory exfiltration vulnerability.
PoC
n/a
Impact
What kind of vulnerability is it? Who is impacted?
Copied from https://bugzilla.tianocore.org/show_bug.cgi?id=4206
Summary
A malicious iSCSI target can cause a remote BIOS to reveal its memory contents with a specially crafted R2T message.
Details
The following function is used to process iSCSI "Ready To Transfer" (R2T) PDUs that were received from the iSCSI target. An offset and length value are extracted from the R2T header, which are both 32-bit unsigned integers.
Below, the highlighted line may be subject to an integer overflow if either
OffsetorDesiredLengthare excessively large. This would bypass the input validation, and would result in theDatabeing advanced beyond the end of the packet's output data buffer.EDK2/NetworkPkg/IScsiDxe/IScsiProto.c
The tainted
Datapointer is then passed to the following function, which builds and sends the response message. The response message may consist of multiple PDUs, which are generated fromDataby theIScsiGenerateDataOutPduSequence()function and transmitted by theTcpIoTransmit()function.Additionally, note that the
OffsetandDesiredLengthfields in theTcb->XferContextstructure are tainted and are attacker-controlled.Inside
IScsiGenerateDataOutPduSequence(), we see a fairly straight forward while-loop that walksDataup to its maximum length ofXferContext->DesiredLength(an attacker-controlled value), breaking it down into PDUs that are each no larger thanConn->MaxRecvDataSegmentLength.Based on this, it appears that the
Datapointer can be read out of bounds, and the OOB memory will be copied into the response PDU and transmitted to the iSCSI target. This constitutes a remote memory exfiltration vulnerability.PoC
n/a
Impact
What kind of vulnerability is it? Who is impacted?