Preventing cross-process SendMessage Calls

2
votes

Say I have a Windows GUI applications with a buttons on it. I am able to simulate a click on that button by using sendMessage winapi calls with BM_CLICK as the parameter to the call.

Now, from a security perspective, I do not want this to happen. i.e. my target process should ignore sendMessage calls from another process. Is there a provision to do this at all ? A way to authenticate the sendMessage calls ?

EDIT: In other words, how can I prevent applications such as Enabler, TurnitOn http://www.raymond.cc/blog/how-to-enable-and-access-disabled-grayed-out-buttons-windows-and-checkboxes/ from accessing functionality that is not meant to be accessed by the user ?

1
windowswinapisendmessage
This is why there's UIPI to prevent lower-privileged applications from sending messages to higher-privileged ones. (msdn.microsoft.com/en-us/library/bb625963.aspx) But no, you generally can't tell where a message came from. Some messages come from the system, after all. - jamesdlin
Thanks for that ! UIPI was something I was not familiar with. But according to the document, UIPI will not come into action for applications that are in the same privilege level. Doesn't that reduce the use of UIPI ? - asudhak
Speaking as a system administrator, you shouldn't be doing this. If I send window messages to your application, I expect it to process them properly, not decide that I'm not "authenticated". Windows security is user-based, not application-based, so it doesn't really make sense to even try to do this; after all, the user can modify the code in your process, so by definition they can bypass any measures you might take. - Harry Johnston
@asudhak In that case, check whether it's still applicable (or enabled) when you process the event. - Deanna
How did the button get disabled in the first place? Presumably you have a function or some internal state that answers the question "should the button be enabled right now?" Call that same function, etc. when processing BM_CLICK and ignore the message if the button is not supposed to be enabled at that time. - cbranch

1 Answers

2
votes

If the application is running in the user's own context, then it can only do what the user can do. The corollary of this, often overlooked, is that anything that the application can do, the user can do.

So there's not really any point in worrying too much about whether a button on such an application is "really" disabled or not. The user can always find another way to do whatever the button was going to do anyway. (This might be by using a registry editor, obtaining another application with the same functionality, or, if nothing else is convenient, they can run the application inside a debugger and force it to re-enable the button.)

The appropriate solution depends on the context:

  • In many cases, the most appropriate solution is to stop worrying about it. You should be able to trust your users, and if you can't, that's an HR problem, not a technical problem.

  • If the application is providing an interface to something running in a higher context, such as, for example, the front end for anti-virus software, then the security decisions (is the user allowed to do this?) should be happening at the back end. That is, the security decisions need to be taken by code that isn't in the user's control.

  • If you're a system administrator trying to lock down a kiosk machine - a machine that is going to be used by untrusted users, typically using a single guest account of some sort - then you use AppLocker or Software Restriction Policy to define which applications the user is allowed to run. Since Enabler and TurnItOn won't be on your list, the user won't be able to run them to bypass your security policy.