> Having only done minimal socket programming, I'm in a bit of a steep > learning curve right now. Other then understanding what a blocking and > non-blocking operation is, I don't fully understand the ramifications of > switching to non-blocking I/O. Compounding this issue is the third party > code, which was clearly written with blocking I/O :(
You cannot write a program that serves multiple clients with a single thread and blocking socket operations. Blocking socket operations can block, and when you are blocked you cannot assist another client. If it does this with 'accept', for example, it will break. A TCP connection might be closed after you get a 'select' hit and before you enter 'accept'. In that case, the 'accept' will block until a new connection happens to come in. This can be remotely exploited. You have the same problem with 'write'. Suppose you get a 'select' hit that a socket is writable, but then you write more bytes that the system is willing to accept at that moment. Boom, you block, and you can't handle other clients. This is also remotely-exploitable -- just request a lot of stuff and don't call 'read'. Unfortunately, you will need to fix the broken code. On the bright side, OpenSSL has pointed out to you that the code is broken and now, with luck, you will not ship/deploy code that likely had numerous remotely exploitable denial-of-service vulnerabilities. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
