EternalBlue Series Part 4: SMB

2. Analysis of SMB: Transactions and FEAs

2.1 Transactions

The first element to analyze in order to understand the vulnerability in the code we decompiled before is how the operations client-server happen in SMB. In essence, the client sends the server a series of “transactions” with the purpose of performing some operation in the server side. However, it usually happens that the data needed for that communication is too large, so instead of the transactions representing one operation each, a single operation will be divided between a number of transactions.

A typical operation will therefore have one single transaction of type 1 (primary transaction) which is sent the first and initiates the connection with the server, and then a series of transactions of type 2 (secondary transaction) which are follow-ups to the original transaction. On the arrival of a secondary transaction, the server identifies that a primary transaction was received before and thus can later interpret the data altogether. When the final secondary transaction arrives, only then the server performs the operation and sends a response back to the client.

---

2.2 FEAs

Full Extended Attributes (FEAs) are data pairs (key + value) which are included in the files which the SMB protocol manages and describes metadata of them. Within the transactions, a list of FEAs is sent, and they are later interpreted by the server. The problem, however, is that, starting from Windows NT, the format in which the list of FEAs is stored in the server is different from just storing what we receive from the client. Let’s see this in more detail because it is critical to understand the vulnerability:

CLIENT SIDE	SERVER SIDE

In the table above we can see the difference between the storage of the list of FEAs for a file and the storage of the list of FEAs inside the server. In the first one, we have a separate entity “FEALIST”, which contains a list of all of the FEAs. In the server, however, there is no array of FEAs, but rather the FEAs are contiguous in memory, and if we want to get the full list we will just start from the first FEA and move our pointer NextEntryOffset units to get the next one.

There are some other key things to understand from the above. The first is that, on arrival of the FEA list, the server will have to allocate some memory in the heap for that list. Since the client indicates in the field cbList the size of that list, it seems everything should be perfectly straight forward for the server. There is a catch, however, since the server will first make sure that the FEA list size provided in cbList corresponds to the actual size of the list. If for any reason the values do not match, then the server will overwrite the value of cbList with the one measured as the sum of the FEA sizes, instead of just dropping the full transaction. This is just the way the developers decided it to be.

Although the above could seem insignificant, it actually is the heart of the vulnerability, and it will be clear why in the following section. See you on the next part, in which we will finally connect the pieces we gathered until this point, explaining how these SMB concepts are connected with the cast mismatch we found on part3 of this eternalblue series.

This work is licensed under a Creative Commons Attribution 4.0 International License.