I think it's fair to say there's an implicit assumption that a user, given the right knowledge and intent, could circumvent this protection at which point they're on their own.
Yup, you're already on the wrong side of the water-tight door at that point.
It's not like you can't sudo rm -rf / on unix. Once you pull out your He-Man sword and shout, "I have the power!!!" you need to know what you're doing.
So, they didn't install and attempt to run any ransomware. I suspect they could have, but if the claim is that it "won't run," it seems you need to actually go ahead and try to run it.
Not really. Most Proof of Concepts for Windows exploits merely launch something like calculator.exe as a placeholder, just to prove that malicious code could have run here. I think it's sufficient that if they could prove they achieved privileged code execution, it is safe to assume that ransomware could have run at that point unabated.
Running calculator.exe isn't sufficient enough for the claims that are made in this article, since it's already in the 'trusted' domain of the OS.
If they could get 'myPersonallyDevelopedExecutable.exe' to run, then the article would have a point, but the researcher stopped short of trying, so this article ends up being shitty journalism.
> Hickey created a malicious, macro-based Word document on his own computer that when opened would allow him to carry out a reflective DLL injection attack, allowing him to bypass the app store restrictions by injecting code into an existing, authorized process.
That's enough to show that you could have run ransomware. Unsigned code execution under Word privileges (which presumably has write permissions to user documents) is enough to encrypt user documents.
I think the point is that it's dishonest/irresponsible for Microsoft to advertise 10 S in this way. Even though technically they're not saying you can't get hacked by ransomware--anyone without technical knowledge can reasonably assume that's the case. The article showed that MS didn't really put too much work into adding extra security/mitigation. Just shutting down side loading isn't work proportional to what they advertise.
Why? They are already running their own unsigned DLL injected code that can do anything they want. Even if the OS wouldn't allow it to launch an unsigned .exe, any malware can just be shipped in that DLL as easily.
This is an argument against running word as an admin and then explicitly allowing macros to execute, it has little to do with breaking the app-containment, which is the claim made in the article.
"Word was opened with administrative privileges through Windows' Task Manager"
So the whole point of Windows 10 S is that it's so locked down it will only run applications from Microsoft's App Store. (That alone make it useless beyond elementary school level.) Yet it will run Microsoft Word with administrative privileges? Why would you ever want to run Microsoft Word with administrative privileges?
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.
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.)
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.
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.
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.
(1) Microsoft would actually
document clearly how its
security works.
(2) Solve these security problems.
E.g., decades ago we had time
sharing systems where rarely
or never did the work of one
user cause security problems
for another user.
One partial approach is to run
a program in a particular
file system directory and
arrange that the program
the program has very limited
access to anything outside
that directory and possibly
limited access to what is
in that directory.
Then ransom ware? Okay,
such a program might make
a mess but only within some
one directory. In that case,
junk the program and delete
the directory.
Or a program gets its own
access control list
with its own capabilities
for whatever resources
are or might be on the
computer.
A clear goal is for Windows
to be able to run any software,
including malicious software,
safely. Why not?
What you describe is roughly how the AppContainer used by modern apps on Windows works. Windows RT could only install apps based on this system.
The problem is that Windows RT was perceived to have failed for lack of compability. So they introduced Centennial which brings back compatibility with some legacy Windows apps, but also brings back most of the same problems that drove them to want to move away from legacy Windows apps in the first place
Yes, when heard about containers, with no details, and I still have yet to read any details, on either containers or how Windows security really works, then just from the word containers I guessed something like what I wrote and you confirmed.
Sure, I have some legacy Windows apps. I'd be glad to log in with Administrator capabilities and, then, put those safe as a stuffed Teddy bear apps on a list of permitted apps.
I'm sure there are a lot of details.
One solution is just to be running a time sharing system with lots of users, each with rigidly delineated capabilities. Then do all Web browsing as just such a user. If the Web browsing lets in ransom ware, fine with me: The damage will be only for that user, and fine with me: I just delete that user.
And there are virtual machine solutions.
IMHO Microsoft should have gotten a good solution long ago.
Well, they wrote and ran a lot of
software with outrageous bugs,
especially writing out of array bounds.
But likely a biggie difference is
that the attack surface was smaller.
Also it may be that some of what Microsoft is still struggling with is
being able still to have Windows run
old software that thinks it's just fine to
read files from nearly anywhere, write lots of files it should have no business writing, run other programs, etc.
E.g., on Windows, I can download and install software, e.g., a new version of Firefox. That writes to my boot drive. What the heck security door did that software pass through?
I'd like to know the details of Windows security, but so far I've never seen any good descriptions or documentation.
I'm interested in Windows security because Windows is the source of
the computing for my startup.
Otherwise, and in general, I hope
that Microsoft gets the security
problems fixed.
imo this isn't so much an Office problem as a general Centennial problem. As long as Centennial apps run with full user privileges, some of them are going to have some mechanism allowing someone to run untrusted code, and I doubt it's feasible to fix this if you also have a goal of allowing a large portion of the legacy apps people want to run, without requiring onerous modifications
33 comments
[ 2.0 ms ] story [ 71.1 ms ] threadIt's not like you can't sudo rm -rf / on unix. Once you pull out your He-Man sword and shout, "I have the power!!!" you need to know what you're doing.
If they could get 'myPersonallyDevelopedExecutable.exe' to run, then the article would have a point, but the researcher stopped short of trying, so this article ends up being shitty journalism.
[disclaimer, MS employee].
That's enough to show that you could have run ransomware. Unsigned code execution under Word privileges (which presumably has write permissions to user documents) is enough to encrypt user documents.
I think the point is that it's dishonest/irresponsible for Microsoft to advertise 10 S in this way. Even though technically they're not saying you can't get hacked by ransomware--anyone without technical knowledge can reasonably assume that's the case. The article showed that MS didn't really put too much work into adding extra security/mitigation. Just shutting down side loading isn't work proportional to what they advertise.
So the whole point of Windows 10 S is that it's so locked down it will only run applications from Microsoft's App Store. (That alone make it useless beyond elementary school level.) Yet it will run Microsoft Word with administrative privileges? Why would you ever want to run Microsoft Word with administrative privileges?
you have to launch from Task Manager to run Word with administrative privileges. (which researcher claims can also be automated)
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.)
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
DLL "injection"? What API is that?
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-Inje... [2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
> (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.
(1) Microsoft would actually document clearly how its security works.
(2) Solve these security problems.
E.g., decades ago we had time sharing systems where rarely or never did the work of one user cause security problems for another user.
One partial approach is to run a program in a particular file system directory and arrange that the program the program has very limited access to anything outside that directory and possibly limited access to what is in that directory.
Then ransom ware? Okay, such a program might make a mess but only within some one directory. In that case, junk the program and delete the directory.
Or a program gets its own access control list with its own capabilities for whatever resources are or might be on the computer.
A clear goal is for Windows to be able to run any software, including malicious software, safely. Why not?
The problem is that Windows RT was perceived to have failed for lack of compability. So they introduced Centennial which brings back compatibility with some legacy Windows apps, but also brings back most of the same problems that drove them to want to move away from legacy Windows apps in the first place
Sure, I have some legacy Windows apps. I'd be glad to log in with Administrator capabilities and, then, put those safe as a stuffed Teddy bear apps on a list of permitted apps.
I'm sure there are a lot of details.
One solution is just to be running a time sharing system with lots of users, each with rigidly delineated capabilities. Then do all Web browsing as just such a user. If the Web browsing lets in ransom ware, fine with me: The damage will be only for that user, and fine with me: I just delete that user.
And there are virtual machine solutions.
IMHO Microsoft should have gotten a good solution long ago.
How much of that was due to people not trying to cause those problems, though?
But likely a biggie difference is that the attack surface was smaller.
Also it may be that some of what Microsoft is still struggling with is being able still to have Windows run old software that thinks it's just fine to read files from nearly anywhere, write lots of files it should have no business writing, run other programs, etc.
E.g., on Windows, I can download and install software, e.g., a new version of Firefox. That writes to my boot drive. What the heck security door did that software pass through?
I'd like to know the details of Windows security, but so far I've never seen any good descriptions or documentation.
I'm interested in Windows security because Windows is the source of the computing for my startup.
Otherwise, and in general, I hope that Microsoft gets the security problems fixed.
https://arstechnica.com/information-technology/2017/06/micro...
So basically this is nothing but a control ploy by M$? Even Apple doesn't restrict things like that (on macOS)