PureBasic Forums - English

Hi,

Is ReceiveNetworkData() secure? Is the used buffer a PB-own buffer or is it only a wrapper for winsock-api-functions with the windows-own buffers?

I'm a little bit unsure if I get a buffer-overflow-problem if I use ReceiveNetworkData() of PB. Can someone give me some information about the security of the PB-network-functions?

Kukulkan

in case of overflow you may use the return value of the function

Dri

Hi Dri,

in case of overflow you may use the return value of the function

You did not understand me. I know about the return value of ReceiveNetworkData(). I want to know if the function ReceiveNetworkData() itself is secure! This is a PB-thing behind my influence.

Kukulkan

you as the programmer provide ReceiveNetworkData() with a receive buffer, so what's keeping you from hardening it yourself? That way you know exactly what's going on, which I prefer over relying on a function not written by you.
Even if ReceiveNetworkData() itself is hardened against some data sequence from the outside thrashing it, I still would do my own buffer checks.

For more information, you might want to start reading this: http://msdn.microsoft.com/security/secu ... fault.aspx

you are right i don't understand your problem. you provide your buffer and its size to the function. if you provide valid values (a real buffer adress and its real size) you might not have any problem and in case of overflow the return value equals the size you gived to the function so you only have to reallocate a bigger buffer and call the function again...

i don't know what's unsecure if you don't send bad values to the function

Dri

To be sure I use Recv_() Windows API which is nearly the same syntax as ReceiveNetworkData().

And what he mean is: There is a socket buffer allocated by Windows for each socket connection and the buffer on your App. (on OSI Layer 7)

Therefore I dont think that it is possible to get a buffer overflow with the PB Command couse it should block the next datagram and gives a socket_error on the sender-side.

Mike