That's... Interesting. Buffer overflow attacks were once considered "speculative at best".

Here's a question: What happens when you take drivers which were designed to run only local content (and thus have never been hardened against malicious content) and expose their entire API surface to the internet?

The answer is similar to the answer to the question: What happens when you take network services which were designed to run only intranet content (and thus have never been hardened against malicious content) and expose their entire API surface to the internet?

We know the answer to the second question: Sasser, Blaster, etc.

Why would the answer to the first question be any different?

And then pray that none of the users of the server ever put any patient data on the server. This means that the calendar data can't include patient names (they're personally identifiable).

Good luck booking appointments without knowing the name of the person who has the appointment.

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.