('binary' encoding is not supported, stored as-is) In-Reply-To: <katvkuk81lk8srfaf2knq46of6k6jses1k4ax.com>

> 3) Microsoft cannot fix these vulnerabilities. These are inherent
> flaws in the design and operation of the Win32 API. This is not a
> bug that can be fixed with a patch.

I would like to rebut this statement. The vulternability seems to
depend on the usage of the WM_TIMER message to execute arbitrary
data that has been put in the target process' address space.

The following four patches would seem to remove this capability:

(a) The memory page where the edit box store the message should not
be marked as executable but only as read/write. Even if the application
copies this memory, it should still be to a page marked as not
executable.

(b) WM_TIMER messages are posted to the message queue and can be
filtered by the application, as stated in the documentation for
this message. The application can have a list over timers and check
this for validity. (Moral of the story: Don't trust window message
parameters any more than user input).

(c) lParam may only be a value that has previously been registered
by SetTimer. GetMessage/PeekMessage or SendMessage/PostMessage can
be modified to verify this. (There has to be a list of timers for
the application somewhere)

(d) SendMessage/PostMessage could be modified to not dispatch or
GetMessage/PeekMessage could be modified to drop WM_TIMER messages
(or any messages that takes addresses, like EM_GETLINE) to windows
belonging to processes other than itself.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]