I 100% agree with the analysis in the Security section (that's actually why I included the wikipedia link).
However the core threats between NPAPI/XPCOM and ActiveX are identical. The two mechanism have different mitigation schemes (FF redirects the user to a secure download location that presumably holds up-to-date versions of the plugins, IE requires that all plugins be digitally signed, checks a CRL and has a blacklist of known bad plugins (and a phoenix list to redirect to a known good plugin)).
Given that IE requires that all ActiveX controls be digitally signed, the only real risk associated with a sites ability to host an activex control required for the site is that a site might host a known vulnerable version of someone else's control. But in order for that to be effective, the control must not be on the blacklist or the phoenix list AND the user must acknowledge a prompt that warns them that loading the plugin could compromise their computer AND the user must acknowledge a UAC elevation prompt (most of the time).
The only thing that FF's security model brings to the table (and it's a HUGE difference in FF's favor) is that Mozilla can remove the known vulnerable versions of the plugins from their site (since they control the default location of plugins).
Ironically ActiveX controls are more vulnerable because they're *more* open than NPAPI plugins:). Anyone who can get a code signing certificate can write and deploy an ActiveX plugin. But the developer of an NPAPI plugin needs to convince Mozilla to host their plugin on their download site,
By many definitions, that makes ActiveX plugins more open than NPAPI plugins. Go figure that one out.
And of course it's always important to remember that if the seeing the dancing pigs requires that the user install a plugin, they will install the plugin. There's nothing that can stop them.
Actually *any* architecture that runs plugins with full trust is fundimentally broken. This means ActiveX, NPAPI/XPCOM, Mozilla's XUL extensions (JS running with full trust that can interact with the DOM == scary). At least IE runs plugins in its sandbox (as does Chrome for some plugins like Flash).
Ok, this gets on my nerves. ActiveX is a plugin framework. It is *exactly* the same as Mozilla's XPCOM. Both XPCOM and ActiveX carry the exact same set of vulnerabilities. There are only two differences between ActiveX controls and NPAPI plugins: 1) NPAPI plugins are typically only hosted on mozilla.com. ActiveX controls can be hosted on any site. 2) ActiveX controls are required to be digitally signed. NPAPI plugins aren't.
The Wikipedia page on NPAPI does a good job of describing the similarities.
So don't blame ActiveX - blame the plugins. This attack could have been mounted against Firefox (after all it used a *flash* vulnerability and last I heard, flash was available for firefox).
Do you have references to court cases where there's been a GPL infringement (by including GPL code in a closed source project) where the infringing product was simply forced to pay monetary damages and wasn't also required to also publish their source code? All of the GPL infringement cases I've heard about have ended up with the infringing party being forced to release their modifications to the code.
I know of several IP lawyers who believe that simply using GPL'ed headers in a project can cause the entire project to be covered by the GPL. The root issue lies in the language of section 2b of the GPL: "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." What constitutes a "derivative work"? How much code do you need to include for it to be derivative? Is it 500 lines of code? 50 lines of code? 1 line of code? I don't know and neither do you.
The next paragraph of the GPL attempts to clarify section 2b: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."
So what constitutes an independant and separate work? For instance if the application depends on functionality embodied in the headers and cannot be implemented on Android *without* the headers, it's possible that it could be considered to be a dependant work and thus not an independent and separate work. Neither your or I can tell the answer to that, that's up to the courts to decide.
In copyright infringement cases, the only thing that matters is actual case law, and there have been very few cases involving GPL infringement that have actually been ajudicated in a court of law.
And because there is very little case law involving the GPL (at least in the US, I know there's at least one German court), it's not clear what constitutes "infringement". And until that is adjudicated in a court of law, it's just a matter of what lawyers think. There's plenty of FUD on both sides.
I seriously doubt that Google's the target here. It's more likely that the developers of apps that use Bionic are the target.
If targetting android means that a developer might lose the rights to the source code to her million dollar game, I think that she would think twice before targetting android.
That might have been the case back 10 years or so ago, but not these days. That's a large part of the reason that the pwn2own folks stopped doing the "target the OS" contests - every major OS is sufficiently locked down that the number of vulns that involve remote code execution that doesn't involve any level of user interaction is essentially 0. This is true even for mobile OSs.
These days, a "click and you're 0wned", vuln is counted as being a remote exploit (because all that's needed is the ability to lure the user to a page).
Nowadays, when people talk of local exploits, they're usually talking about exploits where you go from interactively logged user to root.
The switch from 32bits to 64bits *is* going to break some set of applications. There's simply no way to avoid it.
If you use the LP model, you're going to break every application that assumes that sizeof(int) == sizeof(long). Call this set IntEqualsLong. If you use the LLP model, you're going to break every application that assumes that sizeof(int) == sizeof(void *). Call this set IntEqualsPointer.
The question is: Is the set of applications in IntEqualsLong greater than the set of applications in IntEqualsPointer?
If you believe that IntEqualsLong is larger than IntEqualsPointer, you want to chose LLP (because it breaks fewer applications). If you believe that IntEqualsPointer is greater than IntEqualsLong, you chose LP.
Apparently the Windows developers thought that IntEqualsLong was greater than IntEqualsPointer. The Linux developers chose differently.
Actually until the iPhone came out, touch was considered uninteresting in consumer devices. All the tablets I've ever seen were designed around stylus input, not touch.
When the iPhone came out it was a game changer in more ways than one - touch became the norm, capacitive screens instead of resistive ones, etc.
That's seriously funny. Since the 1980s, one of the core differences between Microsoft's marketing and Apples marketing has been that Microsoft sells to businesses and Apple sells to schools. Even today Apple is a significant force in the classroom (although it appears that their market share is slipping).
Apple's the manufacturer that goes after the young market, not Microsoft. That's a part of why Apple is percieved as being new and hip and Microsoft is percieved as being old and stodgy.
Apple's plan was that they put millions of Apple computers in the schools, then when the kid came home, they'd insist on having a Mac to do their homework since it was what they were used to.
This is a great strategy. The main problem with it was that the kids didn't get to decide which computer to buy - Mom and Dad actually paid for the computers. And Mom and Dad bought the computer *they* were familiar with - the one they used at work.
NT has always supported RISC architectures. Even today Itanium is supported on Windows Server 2008 R2.
In fact, NT was first developed on MIPS and i860 RISC chips, the X86 port came later (seriously). Back in the 1990s, there were active NT versions for MIPS, PPC and Alpha and Itanium. There were even rumours of a Sparc port.
The reason that most of those ports aren't alive today is that the hardware manufacturers told MSFT that they weren't interested in supporting NT for their platform any more.
Clearly you don't work for a business that depends on some ancient piece of software that was developed by a contractor 15 years ago who has since lost the sources.
There are *far* more of those businesses out there than you might believe. The ability to run applications written back in 1995 is crucial to Windows success.
Not quite. IE used to allow the installation of arbitrary *signed* binaries (in the internet zone).
Back when the ActiveX plugin model was created (1996), the internet was a very different place.
The signing requirement was thought to make a difference (since it blocked arbitrary binaries). What Microsoft didn't realize was that the bad guys just had to find a control with a security vulnerability in it (and there are thousands of controls with security vulnerabilities), host it on their site and ask the browser to load the vulnerable control - the signing requirement wasn't as useful as people though.
Because of this, Microsoft has steadily increased the restrictions on ActiveX controls, adding things like site lock (an ActiveX control can indicate that it only works on a particular site), running the ActiveX controls in a sandbox, adding a killbit list to block vulnerable controls, etc..
The IE team can't get rid of ActiveX controls because of the staggering number of sites that rely on them (apparently the South Korean banking industry is completely dependant on ActiveX controls not to mention the number of intranet sites that depend on them).
Ummm... Have you looked at the Apple patch record? This page seems to indicate that they release security fixes every couple of weeks or so (none since January but every two weeks or so before then). The last quicktime fix contained fixes for over a dozen different CVE issues.
You've hit on the key difference between ActiveX and NPAPI - for NPAPI, the user has to download and install the plugin outside the browser, which means that an attacker couldn't guarantee that a particular plugin was present. For ActiveX, a web page could cause the plugin to be installed automatically which meant that an attacker could be sure that a plugin was present. Of course the code that allowed for silent installs has been gone for the better part of a decade but as you said, old painful memories die hard.
If you read this article from the IE blog (from 2005), they claim that ActiveX plugins run in a sandbox. The MSDN documentation for low rights IE has similar contents.
On Windows XP, there are effectively no differences between ActiveX and NPAPI - plugins carry the same risks. For Windows Vista and Windows 7, ActiveX plugins run in the IE "sandbox" which runs with restricted access to the desktop (it's called "low rights IE"). Since Firefox doesn't support a restricted access sandbox (yet), NPAPI plugins are thus more dangerous since they can instantly do anything that the user can do (ActiveX controls need to break out of the sandbox first). Note that in some cases, the IE sandbox is disabled (for instance it's disabled in the local machine zone and for intranet sites).
The original Chrome sandbox only applied to its rendering and JS engine, plugins like flash ran with full access to the desktop. However I believe that Chrome's current extension model runs most extensions in its sandbox as well (I'm not 100% sure - the wikipedia page for chrome is ambiguous on this).
A sandbox acts as a defense-in-depth feature, like data execution protection and ASLR. In general, the more of these features which are enabled, the safer you are when browsing the web.
To be fair, NT4 service pack 1 had serious issues communicating with *nix systems over the internet. Of course that was in 1995 and the issues were fixed in NT4 SP2 (which was rushed to production to fix the issues).
But hey, just because an issue was fixed 15 years ago, it shouldn't stop an anti-windows rant, should it?
Actually the GP was right. DOS 1.0 didn't have directories, just drive #s. directories (and the "\" character) were added in DOS 2.0 (around 1983 or so).
And you know what? That's *exactly* how drive letters are implemented in Windows (NT). There's a symbolic link \Global??\D: which points to \Device\HardDisk0Partition1 (this is from memory, . When the Win32 subsystem parses a file path, it prepends "\Global??\" to the beginning of the file path (among other manipulations like removing "..") before passing it to the low level NT APIs.
You can see some of this with the SysInternals "winobj" tool.
Actually the decision to allow deleting a file which is in use is up to the application. If the application opens the file with FILE_SHARE_DELETE, the OS will allow the open file to be renamed or deleted.
Very few applications take advantage of this because they don't tend to like having their files deleted underneath them. But an application can be built which allows this.
Slashdot Mirror
I 100% agree with the analysis in the Security section (that's actually why I included the wikipedia link).
However the core threats between NPAPI/XPCOM and ActiveX are identical. The two mechanism have different mitigation schemes (FF redirects the user to a secure download location that presumably holds up-to-date versions of the plugins, IE requires that all plugins be digitally signed, checks a CRL and has a blacklist of known bad plugins (and a phoenix list to redirect to a known good plugin)).
Given that IE requires that all ActiveX controls be digitally signed, the only real risk associated with a sites ability to host an activex control required for the site is that a site might host a known vulnerable version of someone else's control. But in order for that to be effective, the control must not be on the blacklist or the phoenix list AND the user must acknowledge a prompt that warns them that loading the plugin could compromise their computer AND the user must acknowledge a UAC elevation prompt (most of the time).
The only thing that FF's security model brings to the table (and it's a HUGE difference in FF's favor) is that Mozilla can remove the known vulnerable versions of the plugins from their site (since they control the default location of plugins).
Ironically ActiveX controls are more vulnerable because they're *more* open than NPAPI plugins :). Anyone who can get a code signing certificate can write and deploy an ActiveX plugin. But the developer of an NPAPI plugin needs to convince Mozilla to host their plugin on their download site,
By many definitions, that makes ActiveX plugins more open than NPAPI plugins. Go figure that one out.
And of course it's always important to remember that if the seeing the dancing pigs requires that the user install a plugin, they will install the plugin. There's nothing that can stop them.
Funny - most of the sites I visit require an NPAPI plugin to work.
That's because most of the sites I use require flash. And guess what: Flash is an NPAPI plugin.
That's fair 'nuf and makes a lot of sense.
Actually *any* architecture that runs plugins with full trust is fundimentally broken. This means ActiveX, NPAPI/XPCOM, Mozilla's XUL extensions (JS running with full trust that can interact with the DOM == scary). At least IE runs plugins in its sandbox (as does Chrome for some plugins like Flash).
Ok, this gets on my nerves. ActiveX is a plugin framework. It is *exactly* the same as Mozilla's XPCOM. Both XPCOM and ActiveX carry the exact same set of vulnerabilities. There are only two differences between ActiveX controls and NPAPI plugins:
1) NPAPI plugins are typically only hosted on mozilla.com. ActiveX controls can be hosted on any site.
2) ActiveX controls are required to be digitally signed. NPAPI plugins aren't.
The Wikipedia page on NPAPI does a good job of describing the similarities.
So don't blame ActiveX - blame the plugins. This attack could have been mounted against Firefox (after all it used a *flash* vulnerability and last I heard, flash was available for firefox).
So why do we never hear of monetary damages for GPL infringements? Why do we only hear of people who release their modifications to the source code?
The GPL text I quoted says that if your work derives from GPL'ed text, it needs to be licenced under the GPL.
Licensing a work under the GPL means that you need to distribute the source code.
Or are you arguing that the whole "copyleft" thing in the GPL is irrelevant? I think the FSF might feel differently.
Remember - the comment came from AMD. Games which tie themselves to a particular GPU is a *great* business model for AMD.
Not so good for anyone else but...
Do you have references to court cases where there's been a GPL infringement (by including GPL code in a closed source project) where the infringing product was simply forced to pay monetary damages and wasn't also required to also publish their source code? All of the GPL infringement cases I've heard about have ended up with the infringing party being forced to release their modifications to the code.
I know of several IP lawyers who believe that simply using GPL'ed headers in a project can cause the entire project to be covered by the GPL. The root issue lies in the language of section 2b of the GPL: "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." What constitutes a "derivative work"? How much code do you need to include for it to be derivative? Is it 500 lines of code? 50 lines of code? 1 line of code? I don't know and neither do you.
The next paragraph of the GPL attempts to clarify section 2b: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."
So what constitutes an independant and separate work? For instance if the application depends on functionality embodied in the headers and cannot be implemented on Android *without* the headers, it's possible that it could be considered to be a dependant work and thus not an independent and separate work. Neither your or I can tell the answer to that, that's up to the courts to decide.
In copyright infringement cases, the only thing that matters is actual case law, and there have been very few cases involving GPL infringement that have actually been ajudicated in a court of law.
And because there is very little case law involving the GPL (at least in the US, I know there's at least one German court), it's not clear what constitutes "infringement". And until that is adjudicated in a court of law, it's just a matter of what lawyers think. There's plenty of FUD on both sides.
I seriously doubt that Google's the target here. It's more likely that the developers of apps that use Bionic are the target.
If targetting android means that a developer might lose the rights to the source code to her million dollar game, I think that she would think twice before targetting android.
This is on Vista or Windows 7? Most of those issues should be fixed in Vista.
If you're still running XP, you should check out the MakeMeAdmin script. It makes this *way* easier.
That might have been the case back 10 years or so ago, but not these days. That's a large part of the reason that the pwn2own folks stopped doing the "target the OS" contests - every major OS is sufficiently locked down that the number of vulns that involve remote code execution that doesn't involve any level of user interaction is essentially 0. This is true even for mobile OSs.
These days, a "click and you're 0wned", vuln is counted as being a remote exploit (because all that's needed is the ability to lure the user to a page).
Nowadays, when people talk of local exploits, they're usually talking about exploits where you go from interactively logged user to root.
The switch from 32bits to 64bits *is* going to break some set of applications. There's simply no way to avoid it.
If you use the LP model, you're going to break every application that assumes that sizeof(int) == sizeof(long). Call this set IntEqualsLong.
If you use the LLP model, you're going to break every application that assumes that sizeof(int) == sizeof(void *). Call this set IntEqualsPointer.
The question is: Is the set of applications in IntEqualsLong greater than the set of applications in IntEqualsPointer?
If you believe that IntEqualsLong is larger than IntEqualsPointer, you want to chose LLP (because it breaks fewer applications). If you believe that IntEqualsPointer is greater than IntEqualsLong, you chose LP.
Apparently the Windows developers thought that IntEqualsLong was greater than IntEqualsPointer. The Linux developers chose differently.
Actually until the iPhone came out, touch was considered uninteresting in consumer devices. All the tablets I've ever seen were designed around stylus input, not touch.
When the iPhone came out it was a game changer in more ways than one - touch became the norm, capacitive screens instead of resistive ones, etc.
That's seriously funny. Since the 1980s, one of the core differences between Microsoft's marketing and Apples marketing has been that Microsoft sells to businesses and Apple sells to schools. Even today Apple is a significant force in the classroom (although it appears that their market share is slipping).
Apple's the manufacturer that goes after the young market, not Microsoft. That's a part of why Apple is percieved as being new and hip and Microsoft is percieved as being old and stodgy.
Apple's plan was that they put millions of Apple computers in the schools, then when the kid came home, they'd insist on having a Mac to do their homework since it was what they were used to.
This is a great strategy. The main problem with it was that the kids didn't get to decide which computer to buy - Mom and Dad actually paid for the computers. And Mom and Dad bought the computer *they* were familiar with - the one they used at work.
NT has always supported RISC architectures. Even today Itanium is supported on Windows Server 2008 R2.
In fact, NT was first developed on MIPS and i860 RISC chips, the X86 port came later (seriously). Back in the 1990s, there were active NT versions for MIPS, PPC and Alpha and Itanium. There were even rumours of a Sparc port.
The reason that most of those ports aren't alive today is that the hardware manufacturers told MSFT that they weren't interested in supporting NT for their platform any more.
Clearly you don't work for a business that depends on some ancient piece of software that was developed by a contractor 15 years ago who has since lost the sources.
There are *far* more of those businesses out there than you might believe. The ability to run applications written back in 1995 is crucial to Windows success.
Not quite. IE used to allow the installation of arbitrary *signed* binaries (in the internet zone).
Back when the ActiveX plugin model was created (1996), the internet was a very different place.
The signing requirement was thought to make a difference (since it blocked arbitrary binaries). What Microsoft didn't realize was that the bad guys just had to find a control with a security vulnerability in it (and there are thousands of controls with security vulnerabilities), host it on their site and ask the browser to load the vulnerable control - the signing requirement wasn't as useful as people though.
Because of this, Microsoft has steadily increased the restrictions on ActiveX controls, adding things like site lock (an ActiveX control can indicate that it only works on a particular site), running the ActiveX controls in a sandbox, adding a killbit list to block vulnerable controls, etc..
The IE team can't get rid of ActiveX controls because of the staggering number of sites that rely on them (apparently the South Korean banking industry is completely dependant on ActiveX controls not to mention the number of intranet sites that depend on them).
Ummm... Have you looked at the Apple patch record? This page seems to indicate that they release security fixes every couple of weeks or so (none since January but every two weeks or so before then). The last quicktime fix contained fixes for over a dozen different CVE issues.
Mod parent up +1 informative.
You've hit on the key difference between ActiveX and NPAPI - for NPAPI, the user has to download and install the plugin outside the browser, which means that an attacker couldn't guarantee that a particular plugin was present. For ActiveX, a web page could cause the plugin to be installed automatically which meant that an attacker could be sure that a plugin was present. Of course the code that allowed for silent installs has been gone for the better part of a decade but as you said, old painful memories die hard.
If you read this article from the IE blog (from 2005), they claim that ActiveX plugins run in a sandbox. The MSDN documentation for low rights IE has similar contents.
On Windows XP, there are effectively no differences between ActiveX and NPAPI - plugins carry the same risks. For Windows Vista and Windows 7, ActiveX plugins run in the IE "sandbox" which runs with restricted access to the desktop (it's called "low rights IE"). Since Firefox doesn't support a restricted access sandbox (yet), NPAPI plugins are thus more dangerous since they can instantly do anything that the user can do (ActiveX controls need to break out of the sandbox first). Note that in some cases, the IE sandbox is disabled (for instance it's disabled in the local machine zone and for intranet sites).
The original Chrome sandbox only applied to its rendering and JS engine, plugins like flash ran with full access to the desktop. However I believe that Chrome's current extension model runs most extensions in its sandbox as well (I'm not 100% sure - the wikipedia page for chrome is ambiguous on this).
A sandbox acts as a defense-in-depth feature, like data execution protection and ASLR. In general, the more of these features which are enabled, the safer you are when browsing the web.
To be fair, NT4 service pack 1 had serious issues communicating with *nix systems over the internet. Of course that was in 1995 and the issues were fixed in NT4 SP2 (which was rushed to production to fix the issues).
But hey, just because an issue was fixed 15 years ago, it shouldn't stop an anti-windows rant, should it?
Actually the GP was right. DOS 1.0 didn't have directories, just drive #s. directories (and the "\" character) were added in DOS 2.0 (around 1983 or so).
And you know what? That's *exactly* how drive letters are implemented in Windows (NT). There's a symbolic link \Global??\D: which points to \Device\HardDisk0Partition1 (this is from memory, . When the Win32 subsystem parses a file path, it prepends "\Global??\" to the beginning of the file path (among other manipulations like removing "..") before passing it to the low level NT APIs.
You can see some of this with the SysInternals "winobj" tool.
Actually the decision to allow deleting a file which is in use is up to the application. If the application opens the file with FILE_SHARE_DELETE, the OS will allow the open file to be renamed or deleted.
Very few applications take advantage of this because they don't tend to like having their files deleted underneath them. But an application can be built which allows this.