Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Sandboxing seem to be a way to restrict what an application can do. Today, I don't have much control of what my applications do with my computer. It feels more secure to use JavaScript based web applications than run native applications on my Windows system.

What are the reasons to why applications aren't sandboxed by default on Windows?

See also How can I restrict what an application can do with my computer?

I don't know much about Windows API programming, but a few functions seem to be scary, if allowed by an arbitrary program, such as:

share|improve this question
    
VirtualProtectEx and WriteProcessMemory are only an issue if the potentially bad app can take SeDebugPrivilege. By default they can only do that if you run that app as an administrator. –  Billy ONeal Nov 9 '11 at 18:16
add comment

3 Answers

up vote 5 down vote accepted

Why aren't applications sandboxed by default on Windows? I don't know, but I'm guessing it is a mixture of the following reasons:

  1. Sandboxing breaks many applications, in complex and subtle ways. Users will be unhappy if Windows turns on a new feature by default that breaks even one of their applications. It is very, very difficult to design an on-by-default sandboxing scheme that is both useful for security and yet does not break any legacy applications.

  2. Historical inertia. Windows has never done this, and it would be a significant change.

  3. Understandability: sandboxing can cause confusing and hard-to-debug failures. It increases the complexity and cognitive load on system administrators and may create more crashes or failures that system administrators find difficult to fix, making sysadmins unhappy.

For practical experience with this, I suggest you look into Apple's move to require that all applications sold via the Mac App Store be sandboxed. Apple is running into some difficulty and as a result is delaying its deadline, and there are reports that some applications will suffer a significant loss of functionality. This is the best case where developers are cooperating and prepared to modify their application to comply with the sandboxing mandate. Now imagine how it would look if Microsoft deployed this on Windows, by default, to all unmodified legacy applications -- the situation would be far worse.

share|improve this answer
    
It should be said that many of the things developers are worried about with sandboxing requirement of Mac App Store applications are turned on by default within Vista/Windows 7. For instance by default you are not allowed to write to protected folder, unless the user elevates your ability to do so, which requires a UAC prompt. –  Ramhound Nov 7 '11 at 19:21
add comment

Oh, but they are, good sir! Sandboxing is not a new concept and has been around since the 1980s; however, as you have probably gathered, the limits of those types of sandboxing have been pushed to the point from a security point of view they look inadequate.

About sandboxing and the permissions model

Let me explain. When your computer boots, it starts up in 16-bit real mode for compatibility reasons (i.e. so you can still run DOS). To cut to the chase, you basically switch to 32-bit protected mode or 64-bit long mode, which are slightly different, but also reasonably similar. At this point your x86-based CPU is in supervisor mode and must set up and handle things like page faults and sysenter or software interrupts so you can do system calls. Skip a few million lines of code to launch all your hardware devices and tada, your first process runs.

Your process, as you may know, is created knowing nothing about the underlying system memory - it sees virtual memory. It is also created running in normal mode (called ring 3) which means it can't do things like set interrupt handlers or alter page flags. In short, it can't see other processes' existence (it "believes" it has full run of the computer) except by asking the operating system.

So, your average every day process is sandboxed, after a fashion. Now, all processes* must ask the operating system to do things, including Administrator ones. What decides whether they can is... the operating system.

Currently, this is mostly done via user permissions. Processes inherit the context of the user they are running as; so a process run as an Administrator user can do anything because the Windows kernel will check its permissions, find out it is an administrator and say "yes, ok" (with exceptions; user mode processes can't technically do certain things but they can load kernel mode processes (e.g. drivers) that can). Likewise, on Linux, root is assumed to be able to do anything.

So the current model (and now I finally get to your question) says that processes inherit and can do exactly what your user can do.

Now this might be a reasonable assumption, except that you might want to have a sensitive word document on your disk and run a web browser. As a result of the fact that your web browser can do anything you the user can do, the fact that you can read the document using word means the web browser could, if it wanted to, as well and there exists no provisions to prevent this.

There are designs for more invasive, more sandboxed permissions systems for operating systems, such as MAC. These systems all propose variants of the idea that each process is additionally constrained in what it can do; so your web browser is allowed only to access the network, temporary storage and the downloads folder. I asked for reasons for their lack of uptake here and the general consensus appears to be complexity is a major factor. People understand the current model well, even if that understanding is simply "I run as Administrator to prevent all the annoying dialogs". MAC systems are inherently complicated; you need knowledge of what a process should be able to do to constrain it.

The much maligned much hated security-failure Windows Vista actually introduced, amongst a slew of other excellent security features and a rebuild of certain OS components, Mandatory Integrity Controls. These go some way to building MAC-type components into Windows.

So, tl;dr for the general question: MAC is hard to understand and complicated to implement.

About those API calls

Now, onto scary API calls:

  • VirtualProtectEx: Changes the protection on a region of committed pages in the virtual address space of a specified process

  • WriteProcessMemory: Writes data to an area of memory in a specified process. The entire area to be written to must be accessible or the operation fails.

Take a note of the notes on the bottom of the latter one:

Any process that has a handle with PROCESS_VM_WRITE and PROCESS_VM_OPERATION access to the process to be written to can call the function. Typically but not always, the process with address space that is being written to is being debugged.

These all-caps values are constants which represent Windows permissions - you can only call that function if you have or can obtain those permissions on a process. On the former function, note:

The handle must have the PROCESS_VM_OPERATION access right. For more information, see Process Security and Access Rights.

The full set of process rights is discussed here. Now, most crucial of all to note is that you need SeDebugPrivilege. The details of this are best explained on the Old New Thing:

By default, users can debug only processes that they own. In order to debug processes owned by other users, you have to possess the SeDebugPrivilege privilege. But don't grant this privilege casually, because once you do, you gave away farm.

So yes, it is possible for you as a user to call these functions and debug processes, but only ones you already own. As the permissions model allows any process you have to do anything your user (including processes you have running) can do, this is expected. Debugging your own processes is a reasonable activity, although yes, it could be used for ill - this ability is the crux of the issue with the current model.

Now, onto GetKeyboardState:

An application can call this function to retrieve the current status of all the virtual keys. The status changes as a thread removes keyboard messages from its message queue.

All windows processes running GUIs have a message queue of events that have happened to them. What this says is that you can retrieve the keyboard state of your process after you have read an event. However, note that:

The status does not change as keyboard messages are posted to the thread's message queue, nor does it change as keyboard messages are posted to or retrieved from message queues of other threads. (Exception: Threads that are connected through AttachThreadInput share the same keyboard state.)

So, yes, you can use AttachThreadInput to hook other processes inputs. There is a workaround for this - see How does Windows Secure Desktop Mode Work?. Essentially, Windows supports multiple desktops and by using these you make it impossible to AttachThreadInput onto them.

tl;dr these functions combined with the current security model do represent a risk and a limitation of the current model, especially to the data and processes of the current user; however, there are levels of security protection in place for your system as a whole provided you are not running as an Administrator user!

share|improve this answer
    
+1 Impressive answer –  Jonas Nov 5 '11 at 13:25
    
Wow. Two tl;dr's... Great answer. –  SteveS Nov 5 '11 at 16:08
    
This answer is long but has some accuracy problems. For example, it is not accurate to state that Windows processes are currently sandboxed by default. –  D.W. Nov 6 '11 at 2:07
4  
@Ninefingers, process isolation + memory protection != sandboxing. It is clear that where the original question refers to "sandboxing", he/she is not referring to process isolation. Windows applications are not sandboxed in the sense that every Windows application you run can do anything you can do. So, Windows applications are not sandboxed, not in the sense that the original question-asker clearly intended. –  D.W. Nov 6 '11 at 20:59
4  
I don't think we're going to agree on what the OP meant - for what it's worth, I covered process isolation/memory protection precisely because in those contexts, those API calls (especially WriteProcessMemory) are restricted to the current user. You can't, in spite of their appearance, write all over the place as you can in real mode; you can't, without being an Admin or holding SeDebugPrivilege, do much to other users' processes at all. As @Rory says, different levels of sandboxing. But, we've both covered the issue from two different points of view, so that can only be a good thing. –  user2213 Nov 6 '11 at 21:36
show 6 more comments

There are various criticisms of sandboxing:

  • it lures users into a false and complacent sense of security while it doesn't stop malware distribution (using exploits or social engineering)
  • it makes life more difficult for benign users while not stopping qualified hackers and errors of developers
  • an owner of data is not free in treating them at his will;
  • it stifles innovation
  • it is senseless for realization in a separate platform
  • it diverts attention of the problem in the wrong direction (from being, in essence, criminal and social to a technical one)

Update
Related article:

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.