5 ms·

I think it means if you launch Word normally it is not running with administrative privileges. you have to launch from Task Manager to run Word with administra

I think it means if you launch Word normally it is not running with administrative privileges. you have to launch from Task Manager to run Word with administrative privileges. (which researcher claims can also be automated)

SAI_Peregrinus 9y ago
Yes, but for a locked down OS version it should be possible to have administrator privileges denied to an application. So the Store could have a flag of which apps might need admin, and only those apps can be run as admin. This would prevent Word from being run as admin, since it certainly shouldn't have that flag.
- derefr 9y ago
  The point of Task Manager here was that Word was being launched "directly"—the process was being spawned, outside of the framework that cares about concepts like "apps" or their security manifests. No matter how sandboxed you make your high-level abstraction layer, you can always just remove the sandbox by removing the abstraction layer. Docker (for example) won't protect you if you cd inside your Docker image and run a binary from it directly on the host. The only way to really "leak-proof" the abstraction here would be to build "apps" as a concept into the OS kernel itself, such that the exec/spawn syscall itself is responsible for doing the sandboxing and the OS's executable-binary format itself is responsible for containing the privilege manifest. So far, I haven't seen any OS interested in taking steps in that direction, though (which is odd, given that a similar conceit—code-signature verification—was embedded into said syscall in every OS quite recently.)
Animats 9y ago
Why should Task Manager, on such a locked-down machine, allow you to run arbitrary applications?
- darklajid 9y ago
  As far as I understand the setup: Task manager runs elevated (Admin) DLL injection allows the attacker to launch a child process (Word) inheriting the task manager privileges. Now you have word running as admin
  - Animats 9y ago
    Maybe the DLL injection API (one of Windows' stranger features) should be disabled for anything running at admin level. Yes, this inhibits debugging. If you want to debug, install a developer build that allows it.
    - hypervis0r 9y ago
      > DLL injection API DLL "injection"? What API is that?
      - Animats 9y ago
        There are ways in Windows to start a new thread in another process.[1] Most of these involve the OpenProcess function.[2] This gives one process access to the state of another process. Once a handle to another process has been obtained, it can be used for starting a new thread in that process, which can load code into the process's address space. There are security checks, but they suffer from the usual problem of assuming that the security entity is the user, not the application. This is mostly a debug facility, but it has other misuses. [1] https://www.codeproject.com/Articles/4610/Three-Ways-to-Inject-Your-Code-into-Another-Proces https://www.codeproject.com/Articles/4610/Three-Ways-to-Inje... [2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms684320(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
        hypervis0r 9y ago
        I know what DLL injection is. I was challenging the "DLL injection API" expression, because there's no such thing as an API that allows you to arbitrarily inject a DLL into a target process. Put it this way: InjectDllIntoProcessEx() does not exist. > (one of Windows' stranger features) It is not a feature by any means. It's hackery and, by the time you've got a handle to the process with PROCESS_CREATE_THREAD (you don't even need PROCESS_VM_WRITE), it's game over. Use ACLs to disallow getting a handle with the necessary permissions if you want to avoid code injection. This post, however, makes no sense. Running an infected Word document with admin permissions is, like somebody else said on this thread, running 'rm -rf /' as root.

SAI_Peregrinus 9y ago

Yes, but for a locked down OS version it should be possible to have administrator privileges denied to an application. So the Store could have a flag of which apps might need admin, and only those apps can be run as admin. This would prevent Word from being run as admin, since it certainly shouldn't have that flag.

derefr 9y ago
The point of Task Manager here was that Word was being launched "directly"—the process was being spawned, outside of the framework that cares about concepts like "apps" or their security manifests. No matter how sandboxed you make your high-level abstraction layer, you can always just remove the sandbox by removing the abstraction layer. Docker (for example) won't protect you if you cd inside your Docker image and run a binary from it directly on the host. The only way to really "leak-proof" the abstraction here would be to build "apps" as a concept into the OS kernel itself, such that the exec/spawn syscall itself is responsible for doing the sandboxing and the OS's executable-binary format itself is responsible for containing the privilege manifest. So far, I haven't seen any OS interested in taking steps in that direction, though (which is odd, given that a similar conceit—code-signature verification—was embedded into said syscall in every OS quite recently.)

Animats 9y ago

Why should Task Manager, on such a locked-down machine, allow you to run arbitrary applications?

darklajid 9y ago
As far as I understand the setup: Task manager runs elevated (Admin) DLL injection allows the attacker to launch a child process (Word) inheriting the task manager privileges. Now you have word running as admin
- Animats 9y ago
  Maybe the DLL injection API (one of Windows' stranger features) should be disabled for anything running at admin level. Yes, this inhibits debugging. If you want to debug, install a developer build that allows it.
  - hypervis0r 9y ago
    > DLL injection API DLL "injection"? What API is that?
    - Animats 9y ago
      There are ways in Windows to start a new thread in another process.[1] Most of these involve the OpenProcess function.[2] This gives one process access to the state of another process. Once a handle to another process has been obtained, it can be used for starting a new thread in that process, which can load code into the process's address space. There are security checks, but they suffer from the usual problem of assuming that the security entity is the user, not the application. This is mostly a debug facility, but it has other misuses. [1] https://www.codeproject.com/Articles/4610/Three-Ways-to-Inject-Your-Code-into-Another-Proces https://www.codeproject.com/Articles/4610/Three-Ways-to-Inje... [2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms684320(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
      - hypervis0r 9y ago
        I know what DLL injection is. I was challenging the "DLL injection API" expression, because there's no such thing as an API that allows you to arbitrarily inject a DLL into a target process. Put it this way: InjectDllIntoProcessEx() does not exist. > (one of Windows' stranger features) It is not a feature by any means. It's hackery and, by the time you've got a handle to the process with PROCESS_CREATE_THREAD (you don't even need PROCESS_VM_WRITE), it's game over. Use ACLs to disallow getting a handle with the necessary permissions if you want to avoid code injection. This post, however, makes no sense. Running an infected Word document with admin permissions is, like somebody else said on this thread, running 'rm -rf /' as root.