Author Topic: [Bug] COM/DCOM and logged-in users  (Read 1770 times)

fixer

  • Administrator
  • Hero Member
  • *****
  • Posts: 1525
[Bug] COM/DCOM and logged-in users
« on: August 05, 2017, 06:40:10 pm »
And one more logged-in users bug to the already pretty big list of bugs. This time it's COM/DCOM-objects, e.g. ISpellCheckerFactory interface and hence spellchecking in isolated (and I don't mean ReHIPS isolated here, actually any program running from a user other than logged-in user) programs. When these COM/DCOM-objects are initialized, ALPC request is sent to the DCOM/RPCSS hadling service, that checks access executing LaunchOrActivationAllowed function. This function checks access token against default permissions (RuntimeBroker for ISpellCheckerFactory) DACL D:(A;;CCDCSW;;;AC)(A;;CCDCSW;;;PS)(XA;;CCDCSW;;;IU;(!(WIN://ISMULTISESSIONSKU))) PS is substituted with SID of logged-in user that is taken from internal list. So if we try to start process from another user (using API, using runas), we'll get access denied error. OK, some of you may say: "then just change these default permissions in the registry". I'm not actually fond of loosening default permissions, I expect Windows developers to know better than me how to make their OS secure. But anyway, let's pretend it's OK and we won't compromise anything. Indeed, it's possible to change them in the registry and then reboot to reload permissions cache. But even after this some COM/DCOM-objects will remain broken. Why? The problem is their host process is running from logged-in real user. If they need to do some actions upon client request, they impersonate. And they'll get only Identify impersonation level (compare to Impersonation impersonation level when they receive request from a program started from logged-in real user). Because of this weak impersonation level some functions return error causing the whole client request to fail. And there unfortunately is nothing that can be done about this.

This issue was found several months ago, it wasn't fixed then. I haven't checked it since, but I suspect it to remain broken for many years to come.