I think that there are multiple issues with various ccnl_<packetformat>_prependBlob functions. I've picked the ccnl_ndntlv_prependBlob as an example.
The len parameter refers to the size of the blob and offset to the position where the data in blob should be written to buf. The function returns -1 if the offset is lower than the size of the blob which is prepended to the buffer (basically if somebody tries to write before the buffer (buffer underwrite)).
After a brief discussion we agreed that this not vulnerability but a bug. As far as I can see throughout the code base ccnl_ndntlv_prependBlob is used with safe parameter settings, but we should fix the function for future developers/users.
After additional discussion, we have to add a vulnerability tag again.
This is a remote vulnerability. By adding incorrect TLV information, it is possible that the length of a component inside prefix does not correspond to the allocated data.
Therefore, name->complen[cnt] can be < 0, since the length field of a NDNTLV can have up to 64bit, while name->complen[cnt] is only a 32bit integer.
Hi,
I think that there are multiple issues with various
ccnl_<packetformat>_prependBlobfunctions. I've picked theccnl_ndntlv_prependBlobas an example.The
lenparameter refers to the size of theblobandoffsetto the position where the data inblobshould be written tobuf. The function returns -1 if the offset is lower than the size of the blob which is prepended to the buffer (basically if somebody tries to write before the buffer (buffer underwrite)).I've made a short illustration depicting valid input parameters and the result after the
memcpyoperation.Do you agree? Also, the function lacks the
sizeof the buffer which would allow a better error handling/invalid parameters.TIA
Michael
The text was updated successfully, but these errors were encountered: