Submitted by: @AlexPeshkoff
Block progress on CORE6524
Attachments:
fbclient_failures.tgz
We always (for obvious reasons) used to pay big attention to network attacks on server. And never checked how does client behave in a case when server sends to it inappropriate data. That appeared good compromise - first, our server should not send invalid data to client, and second - single client failure is not too big trouble.
But looks like that approach should be reviewed. Our client (dynamic library) may be a component of server software, just to mention use of it in our own server to server (execute statement on external) communication, and AV in client anyway kills all server. And it's hard to hope on a fact that our good server on another side will not send such bad things - we can't be sure what is actually running on port 3050, that may be up to network cat sending bad responses as an attack.
Here were fixed a lot of bugs, testcase for which I've received from Pavel Cisar. They all are based on sending from "server" something inappropriate, that may be for example wrong network operation (type of packet), too long response (i.e. bigger than client requested) or some other incompatible combination of data in the packet. All tests initially cause segfault in fbclient.
Commits: 0917a07 c102012 967fb28
Submitted by: @AlexPeshkoff
Block progress on CORE6524
Attachments:
fbclient_failures.tgz
We always (for obvious reasons) used to pay big attention to network attacks on server. And never checked how does client behave in a case when server sends to it inappropriate data. That appeared good compromise - first, our server should not send invalid data to client, and second - single client failure is not too big trouble.
But looks like that approach should be reviewed. Our client (dynamic library) may be a component of server software, just to mention use of it in our own server to server (execute statement on external) communication, and AV in client anyway kills all server. And it's hard to hope on a fact that our good server on another side will not send such bad things - we can't be sure what is actually running on port 3050, that may be up to network cat sending bad responses as an attack.
Here were fixed a lot of bugs, testcase for which I've received from Pavel Cisar. They all are based on sending from "server" something inappropriate, that may be for example wrong network operation (type of packet), too long response (i.e. bigger than client requested) or some other incompatible combination of data in the packet. All tests initially cause segfault in fbclient.
Commits: 0917a07 c102012 967fb28