4 ms·

ActiveX can be sandboxed pretty strongly, but plugins can opt out of it. NaCl seems to leave no way to get out of the sandbox. I think Microsoft could easily ad

ActiveX can be sandboxed pretty strongly, but plugins can opt out of it. NaCl seems to leave no way to get out of the sandbox. I think Microsoft could easily add something very similar to NaCl to ActiveX, and then create a distinction in the UI between these sandboxed plugins and the current kind. Edit: To clarify, ActiveX plugins cannot really "opt out" of IE's sandbox. There are some things they can do to reduce some of the default restrictions, but the most important ones always remain in place.

stuntmouse 16y ago
How does ActiveX sandboxing work? As far as I know, it mainly relies on signatures. What happens when you trust a control that has a bug which overwrites your hard disk? And that's leaving out malicious code...
- briansmith 16y ago
  AFAIK, there is no "ActiveX sandboxing" per se. It is the same as the sandboxing techniques that are available to all Windows executables. But, also Internet Explorer runs in "Protected Mode" by default, so many of these sandboxing techniques get applied--by default--to plugins. See http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx.
  - stuntmouse 16y ago
    Very informative link. Thank you.
  - stuntmouse 16y ago
    This looks impressive for systems that are supported (Vista and up). I'm not entirely convinced that all attack vectors have been considered though. They appear to have considered the obvious things: write and execute access to files and other resources from restricted processes, preventing harmful windows message behavior. But would a process with low integrity have read access to every other resource with low integrity? Or is that further constrained by some other access control mechanism? Also, I don't think it's a feature for an unprivileged process to have registry access, though I understand there may be reasons for it. It could also be argued that there is a larger attack surface for protected mode processes, because they can call any OS function, but are just denied when they don't have the access level to commit the action. I must admit I am behind the times with regards to Windows system programming.
    - briansmith 16y ago
      Yes, one advantage of Chrome's system is that it can be more restrictive than the operating system. And, the pre-scanning is an extra line of defense. I won't attempt to explain the integrity system in Windows because I am not that familiar with it. But, Wikipedia says that read access can be blocked based on integrity level too. See http://en.wikipedia.org/wiki/Mandatory_Integrity_Control http://en.wikipedia.org/wiki/Mandatory_Integrity_Control
      - stuntmouse 16y ago
        As a final note, there's no reason why the two couldn't be used in tandem. In fact, they should be.
        briansmith 16y ago
        I think that Chrome and IE differ in how they split functionality between processes (and thus integrity levels), but both Chrome and IE make extensive use of the various sandboxing tools that Windows offers.
pavs 16y ago
I am trying to understand this, if this is similar to activex, do we have to deal with annoying popup like "Do you want to install this activex plugin" for every webapps for chrome based on this?
- stuntmouse 16y ago
  Well, as wmf said, sandboxing is key. All NativeClient apps are compiled specially and scanned before they are run to ensure that apps can't use just any system call - they must interact only through NaCl's posix like library and the plugin api. Their homepage has a paper and video describing this in detail: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ [edit] Just realized I didn't respond to the meat of your post. Theoretically, there is no reason why any warning would be necessary for running a NaCl plugin because the sandboxing would be secure.
  - briansmith 16y ago
    The main difference between Chrome's model and IE's model is that Chrome enforces restrictions itself, whereas the operating system enforces the restrictions for IE. I think IE's model works pretty well for Vista and later Windows systems. Chrome's model works for Windows XP and it also might be better for other operating systems.
    - enneff 16y ago
      That is misleading. An ActiveX control has the same permissions as the IE process hosting it. A malicious ActiveX control can hijack your browser, and do any number of other things. A NaCl app can only interact with the system through a restricted syscall interface. That's it.
      - briansmith 16y ago
        The hosting IE process is running with low integrity. Accordingly, it's ability to do bad stuff is severely limited. I do see that restricting access to syscalls potentially improves security. But, which syscalls can a low integrity process use to actually do something bad? That's something I'm interested in finding out.
tptacek 16y ago
ActiveX's controls are nothing at all like NACL's. NACL restricts the actual ABI. It enforces constraints that make disassembly to basic blocks deterministic (regular x86 isn't). It then uses the X86 MMU to prevent control flow blocks that could escape the sandbox. Say whatever you want about ActiveX security (ActiveX is, for what it's worth, not secure --- though at some point all of IE might be), but they aren't doing basic block analysis, an MMU-enforced sandbox, or requiring special compilers for everything linked into the controls.
- briansmith 16y ago
  It's been a long time since I read the NaCL publications so I might be forgetting some things. But, let's say IE9 were to move plugins to their own low-integrity processes (instead of being in the tabs' low-integrity processes like now). Given a perfectly-functioning mandatory integrity control system, how much of the additional NaCL infrastructure really provides extra security? How much of it "just" provides an extra layer of defense against kernel bugs and/or security for pre-Vista/non-Windows systems? In other words, is this extra infrastructure something that Microsoft would really find useful to implement in IE9? Or, is it just needed for operating systems that IE9 won't support anyway?
  - tptacek 16y ago
    Because WinAPI, no matter what MAC system it implements, isn't enforced at the basic-block level, and NaCL is. NaCL has a smaller auditable attack surface. No matter what WinAPI does, the entire memory map of an x86-64 process is exposed to IE, and the same system call gates are exposed, and the same set of inherited process attributes are there. I'm not saying one is more secure than the other (NaCL's model is more elegant but theoretically riskier, WinAPI's is better tested and more conservative).

stuntmouse 16y ago

How does ActiveX sandboxing work? As far as I know, it mainly relies on signatures. What happens when you trust a control that has a bug which overwrites your hard disk? And that's leaving out malicious code...

briansmith 16y ago
AFAIK, there is no "ActiveX sandboxing" per se. It is the same as the sandboxing techniques that are available to all Windows executables. But, also Internet Explorer runs in "Protected Mode" by default, so many of these sandboxing techniques get applied--by default--to plugins. See http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx.
- stuntmouse 16y ago
  Very informative link. Thank you.
- stuntmouse 16y ago
  This looks impressive for systems that are supported (Vista and up). I'm not entirely convinced that all attack vectors have been considered though. They appear to have considered the obvious things: write and execute access to files and other resources from restricted processes, preventing harmful windows message behavior. But would a process with low integrity have read access to every other resource with low integrity? Or is that further constrained by some other access control mechanism? Also, I don't think it's a feature for an unprivileged process to have registry access, though I understand there may be reasons for it. It could also be argued that there is a larger attack surface for protected mode processes, because they can call any OS function, but are just denied when they don't have the access level to commit the action. I must admit I am behind the times with regards to Windows system programming.
  - briansmith 16y ago
    Yes, one advantage of Chrome's system is that it can be more restrictive than the operating system. And, the pre-scanning is an extra line of defense. I won't attempt to explain the integrity system in Windows because I am not that familiar with it. But, Wikipedia says that read access can be blocked based on integrity level too. See http://en.wikipedia.org/wiki/Mandatory_Integrity_Control http://en.wikipedia.org/wiki/Mandatory_Integrity_Control
    - stuntmouse 16y ago
      As a final note, there's no reason why the two couldn't be used in tandem. In fact, they should be.
      - briansmith 16y ago
        I think that Chrome and IE differ in how they split functionality between processes (and thus integrity levels), but both Chrome and IE make extensive use of the various sandboxing tools that Windows offers.

pavs 16y ago

I am trying to understand this, if this is similar to activex, do we have to deal with annoying popup like "Do you want to install this activex plugin" for every webapps for chrome based on this?

stuntmouse 16y ago
Well, as wmf said, sandboxing is key. All NativeClient apps are compiled specially and scanned before they are run to ensure that apps can't use just any system call - they must interact only through NaCl's posix like library and the plugin api. Their homepage has a paper and video describing this in detail: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ [edit] Just realized I didn't respond to the meat of your post. Theoretically, there is no reason why any warning would be necessary for running a NaCl plugin because the sandboxing would be secure.
- briansmith 16y ago
  The main difference between Chrome's model and IE's model is that Chrome enforces restrictions itself, whereas the operating system enforces the restrictions for IE. I think IE's model works pretty well for Vista and later Windows systems. Chrome's model works for Windows XP and it also might be better for other operating systems.
  - enneff 16y ago
    That is misleading. An ActiveX control has the same permissions as the IE process hosting it. A malicious ActiveX control can hijack your browser, and do any number of other things. A NaCl app can only interact with the system through a restricted syscall interface. That's it.
    - briansmith 16y ago
      The hosting IE process is running with low integrity. Accordingly, it's ability to do bad stuff is severely limited. I do see that restricting access to syscalls potentially improves security. But, which syscalls can a low integrity process use to actually do something bad? That's something I'm interested in finding out.

tptacek 16y ago

ActiveX's controls are nothing at all like NACL's. NACL restricts the actual ABI. It enforces constraints that make disassembly to basic blocks deterministic (regular x86 isn't). It then uses the X86 MMU to prevent control flow blocks that could escape the sandbox. Say whatever you want about ActiveX security (ActiveX is, for what it's worth, not secure --- though at some point all of IE might be), but they aren't doing basic block analysis, an MMU-enforced sandbox, or requiring special compilers for everything linked into the controls.

briansmith 16y ago
It's been a long time since I read the NaCL publications so I might be forgetting some things. But, let's say IE9 were to move plugins to their own low-integrity processes (instead of being in the tabs' low-integrity processes like now). Given a perfectly-functioning mandatory integrity control system, how much of the additional NaCL infrastructure really provides extra security? How much of it "just" provides an extra layer of defense against kernel bugs and/or security for pre-Vista/non-Windows systems? In other words, is this extra infrastructure something that Microsoft would really find useful to implement in IE9? Or, is it just needed for operating systems that IE9 won't support anyway?
- tptacek 16y ago
  Because WinAPI, no matter what MAC system it implements, isn't enforced at the basic-block level, and NaCL is. NaCL has a smaller auditable attack surface. No matter what WinAPI does, the entire memory map of an x86-64 process is exposed to IE, and the same system call gates are exposed, and the same set of inherited process attributes are there. I'm not saying one is more secure than the other (NaCL's model is more elegant but theoretically riskier, WinAPI's is better tested and more conservative).