Hi,
We found a buffer overflow and a infomation leak in Enclave/Enclave.cpp.
There is a global variable "Arg arg_enclave;" in enclave and it is initialized in ecall "enclave_init_values". However it value is copyed from "arg" which is untrusted.
We found a member variable in structure "Arg" called "int max_buf_size;". Then we search the code to find where "max_buf_size" is used. We found two patterns:
First is like this "memset(cipher, 0, arg_enclave.max_buf_size);". For example it is used in "enclave_get", while the parametre "cipher" refers to the buf in "enclave_process", and its size is a constant(4125). So, arg_enclave.max_buf_size can be larger than the buffer size.
Second pattern is "message_return(cipher, arg_enclave.max_buf_size, client_sock);". Function "message_return" is an ocall which writes cipher to client_sock.
In function "enclave_message_pass" cipher is introduced from data which is original from "HotCall* hotEcall". While "hotEcall" is transferd from untrusted part.
So, attacker can set cipher points to arbitrary address in encalve and set client_sock to sdtout that will leak information in encalve.
Thanks,
yudhui
The text was updated successfully, but these errors were encountered:
Definitely yes, to implement a fully trusted key-value store, it requires elaborate handling for the configurations. Since ShieldStore is a prototype of trusted key-value store, we implemented it as simply passing the untrusted arguments.
buffer overflow due to the mismatch of buffer size
The mismatch of the buffer size can cause buffer overflow as you mentioned. I think our experimental code contains the constant size of buffer (BUF_SIZE), but there’s no use of BUF_SIZE in the main code.
A vulnerable point for an untrusted buffer
Since the “cipher” is the part of untrusted memory address, an attacker can freely manipulate the contents or address of the buffer. As you described, if the attack arbitrary points the “cipher” to an enclave address, the information leakage can be occurred. One of the simple solutions is to allocate a new buffer for the response in order to decouple the buffers.
Thank you for the consideration what we didn’t catch.
Hi,
We found a buffer overflow and a infomation leak in Enclave/Enclave.cpp.
There is a global variable "Arg arg_enclave;" in enclave and it is initialized in ecall "enclave_init_values". However it value is copyed from "arg" which is untrusted.
We found a member variable in structure "Arg" called "int max_buf_size;". Then we search the code to find where "max_buf_size" is used. We found two patterns:
First is like this "memset(cipher, 0, arg_enclave.max_buf_size);". For example it is used in "enclave_get", while the parametre "cipher" refers to the buf in "enclave_process", and its size is a constant(4125). So, arg_enclave.max_buf_size can be larger than the buffer size.
Second pattern is "message_return(cipher, arg_enclave.max_buf_size, client_sock);". Function "message_return" is an ocall which writes cipher to client_sock.
In function "enclave_message_pass" cipher is introduced from data which is original from "HotCall* hotEcall". While "hotEcall" is transferd from untrusted part.
So, attacker can set cipher points to arbitrary address in encalve and set client_sock to sdtout that will leak information in encalve.
Thanks,
yudhui
The text was updated successfully, but these errors were encountered: