Sockets on Windows (and DuplicateHandle, CloseHandle)
- From: Ryan Lortie <desrt desrt ca>
- To: gtk-devel-list gnome org
- Subject: Sockets on Windows (and DuplicateHandle, CloseHandle)
- Date: Tue, 03 Feb 2015 06:07:36 -0500
It seems that socket handles on Windows, at least under some conditions,
may not exactly be handles.
You are not supposed to (for example) call CloseHandle or
DuplicateHandle on them, although other windows handle APIs (ReadFile,
etc.) will work.
The stated reason for this is LSPs (or "Layered Service Providers")
which seem to have been designed (and are most actively used) as a
malware delivery vector. Sockets are not really sockets, but rather
bits of code that get loaded into your address space to intercept all
your socket calls. They have been severely deprecated in newer versions
of Windows (so much so that you won't quality for the Windows logo
program if your system uses them).
What I want to know:
- are LSPs the only reason that I can't use CloseHandle and
DuplicateHandle on
socket handles (ie: if there are no LSPs around, will everything be
OK)?
- how common are LSPs in practice?
Another question: does anyone know of a scheme for detecting if a
particular HANDLE is a socekt, in a non-destructive way? Doing various
WSAIoctl operations on a non-socket will return an "operation not
supported" error, but this same error is also returned if the particular
socket type (or state) does not support the operation.
Final question: it seems that calling closesocket() on non-sockets works
correctly. For example, calling CreateEvent() and then closesocket()
results in a successful return value from closesocket() and the expected
behaviour of the same HANDLE number being reused for the next
CreateEvent(). Does anyone have a good reason for why we shouldn't do
that?
Any input on this topic is highly welcome.
Thanks in advance.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]