4 ms·

This sounds like a "Other side of this airtight hatchway" security non-flaw. If you can convince a user to run arbitrary code, then it doesn't matter whether it

This sounds like a "Other side of this airtight hatchway" security non-flaw. If you can convince a user to run arbitrary code, then it doesn't matter whether it's an iTunes plugin or something else. You're owned either way.

judk 13y ago
So.. If a user runs arbitrary HTML or JS in their browser, they are owned?
- mitchty 13y ago
  Bit different than something that inherently has full access to the parent processes memory space like an iTunes plugin no?
  - rdtsc 13y ago
    At the technical level that is the mechanism that makes it possible. That does little to advance the point though. It is like saying "well exploits happened because in C you can write over the array boundary". Yes that is how some of them happen. But explaining the mechanism doesn't justify or solve the problem and it takes too low of a view. I guess one can ask whether : 1) Should plugins be allowed? 2) Should plugins run in the same memory space as parent process? There are other ways. Like how come a Google Chrome tab doesn't usually succeed in corrupting or blocking another chrome tab? hmm interesting. Maybe, setup a socketpair or sharedmemory or a message and mailbox system. 3) Should signing, verifying and vetting of these plugins be done differently?
    - teacup50 13y ago
      1) Yes, 2) Yes, 3) No. This is what makes a desktop computer useful. If you don't trust code, don't run untrusted code. I also recommend not aiming loaded weapons at your own foot.
      - mitchty 13y ago
        I mostly agree, my only digression would be that iTunes should be split from the player component with plugins, and the store component. Then plugins like you had even back in the winamp days like milkdrop can stay in the player, where they belong, and keep the store stuff separate. But even this approach is less than perfect so I don't know really what a great solution would be.
- swinglock 13y ago
  Can you install iTunes plugin via a browser with no user interaction?
  - voltagex_ 13y ago
    Depends on the 0day.
- pfraze 13y ago
  The browser is unique for using the JS virtual machine to sandbox its executed code. It's very different from running a downloaded executable.
  - rdtsc 13y ago
    The browser is not unique. There are other virtual machines out there. There are slew of IPC mechanisms. OS facilities. Containers, virtualization, chroot environments. Maybe they are not practical for this particular problem but somehow saying browser is magic because it is using a scripting a language VM isn't true in general. Thinking about, heck, a browser can even execute downloadable executable as well -- that is the PNaCl framework.
    - derefr 13y ago
      I think what the parent meant, was that the browser is unique in actually having an attack surface (the JS VM sandbox) that has been hardened by millions of people hitting it with arbitrary foreign code all day. Just because something else on your system happens to be a virtual machine, does not mean its security has been ascertained to nearly this extent. I wouldn't expect, say, VMWare, or the OpenType rendering engine, to hold up if millions of people were throwing arbitrary foreign code at them each day. But people don't--the code these VMs see is mostly trusted code they either created themselves, or got from a reputable source, and it's heavily the same 1000-2000 blobs.
  - judk 13y ago
    MacOS uses a sandbox security model for all major apps now--but automatically silently loads 3rd party iTunes plugins into iTunes app security context.
AlexanderDhoore 13y ago
It's strange that people have so much trouble understanding this.
lstamour 13y ago
Right, because I often expect visualizer plugins to not be sandboxed and have full control over my iTunes Store transactions... not. :)
mapgrep 13y ago
It's tempting to be this reductive but it ignores context and specifically the implications of the word "plugin." The context of downloading and executing a full fledged app fits with your implication that the user should know she'll be "owned" by a mistake. (Despite this, Apple offers mitigations in terms of warnings and code signing, but I take your point.) The implication of downloading and installing something that uses what Apple itself calls a "plugin" API is different. There is an implication of sandboxing, and while you can debate the limits, most reasonable people would NOT expect an iTunes app plugin gets access to naked Apple account credentials. It's easy to now say "you should trust no sandbox." But practically speaking most of us need to do this all the time. Do we verify all the security of all the Javascript sandboxes we run, to ensure the millionth Chrome update didn't introduce a sandbox hole? No we do not. We trust if the sandbox has a hole someone will blow the whistle. Which is happily what is happening here.
- nknighthb 13y ago
  There is no implication of sandboxing. Even sandboxing browser plugins is new. You should never assume a plugin in any application is sandboxed, because that has never been true about any application at all until the past few years, and is still not true about virtually everything except browsers. Sandboxing of plugins is the exception, not the rule.

judk 13y ago

So.. If a user runs arbitrary HTML or JS in their browser, they are owned?

mitchty 13y ago
Bit different than something that inherently has full access to the parent processes memory space like an iTunes plugin no?
- rdtsc 13y ago
  At the technical level that is the mechanism that makes it possible. That does little to advance the point though. It is like saying "well exploits happened because in C you can write over the array boundary". Yes that is how some of them happen. But explaining the mechanism doesn't justify or solve the problem and it takes too low of a view. I guess one can ask whether : 1) Should plugins be allowed? 2) Should plugins run in the same memory space as parent process? There are other ways. Like how come a Google Chrome tab doesn't usually succeed in corrupting or blocking another chrome tab? hmm interesting. Maybe, setup a socketpair or sharedmemory or a message and mailbox system. 3) Should signing, verifying and vetting of these plugins be done differently?
  - teacup50 13y ago
    1) Yes, 2) Yes, 3) No. This is what makes a desktop computer useful. If you don't trust code, don't run untrusted code. I also recommend not aiming loaded weapons at your own foot.
    - mitchty 13y ago
      I mostly agree, my only digression would be that iTunes should be split from the player component with plugins, and the store component. Then plugins like you had even back in the winamp days like milkdrop can stay in the player, where they belong, and keep the store stuff separate. But even this approach is less than perfect so I don't know really what a great solution would be.
swinglock 13y ago
Can you install iTunes plugin via a browser with no user interaction?
- voltagex_ 13y ago
  Depends on the 0day.
pfraze 13y ago
The browser is unique for using the JS virtual machine to sandbox its executed code. It's very different from running a downloaded executable.
- rdtsc 13y ago
  The browser is not unique. There are other virtual machines out there. There are slew of IPC mechanisms. OS facilities. Containers, virtualization, chroot environments. Maybe they are not practical for this particular problem but somehow saying browser is magic because it is using a scripting a language VM isn't true in general. Thinking about, heck, a browser can even execute downloadable executable as well -- that is the PNaCl framework.
  - derefr 13y ago
    I think what the parent meant, was that the browser is unique in actually having an attack surface (the JS VM sandbox) that has been hardened by millions of people hitting it with arbitrary foreign code all day. Just because something else on your system happens to be a virtual machine, does not mean its security has been ascertained to nearly this extent. I wouldn't expect, say, VMWare, or the OpenType rendering engine, to hold up if millions of people were throwing arbitrary foreign code at them each day. But people don't--the code these VMs see is mostly trusted code they either created themselves, or got from a reputable source, and it's heavily the same 1000-2000 blobs.
- judk 13y ago
  MacOS uses a sandbox security model for all major apps now--but automatically silently loads 3rd party iTunes plugins into iTunes app security context.

AlexanderDhoore 13y ago

It's strange that people have so much trouble understanding this.

lstamour 13y ago

Right, because I often expect visualizer plugins to not be sandboxed and have full control over my iTunes Store transactions... not. :)

mapgrep 13y ago

It's tempting to be this reductive but it ignores context and specifically the implications of the word "plugin." The context of downloading and executing a full fledged app fits with your implication that the user should know she'll be "owned" by a mistake. (Despite this, Apple offers mitigations in terms of warnings and code signing, but I take your point.) The implication of downloading and installing something that uses what Apple itself calls a "plugin" API is different. There is an implication of sandboxing, and while you can debate the limits, most reasonable people would NOT expect an iTunes app plugin gets access to naked Apple account credentials. It's easy to now say "you should trust no sandbox." But practically speaking most of us need to do this all the time. Do we verify all the security of all the Javascript sandboxes we run, to ensure the millionth Chrome update didn't introduce a sandbox hole? No we do not. We trust if the sandbox has a hole someone will blow the whistle. Which is happily what is happening here.

nknighthb 13y ago
There is no implication of sandboxing. Even sandboxing browser plugins is new. You should never assume a plugin in any application is sandboxed, because that has never been true about any application at all until the past few years, and is still not true about virtually everything except browsers. Sandboxing of plugins is the exception, not the rule.