Samsung intentionally created new kernel-userspace interface to bypass normal kernel security mechanisms and give userspace direct access to RAM and IO registers, allowing them to put low-level device drivers in userspace. I'm pretty sure that somebody writing a Windows driver for this hardware could use the same "architecture" as well.

However, Windows is less likely to see such hacks because they are usually created to avoid dealing with kernel's GPL.

Userspace is really not the issue here at all. The problem is that the device was given full access permissions to every role on the system, when it should have been (trivially) limited to only system services. All of Android is userspace and relies on the kernel's userspace protection system (standard unix permissions) for security.

It's just a major mistake on Samsung's side that could have been avoided with 5 seconds of thought by the engineer.

This exploit doesn't have anything to do with "crapware", it has to do with a flawed implementation of how the camera accesses the memory.

The code in the Windows kernel is never touched by anyone outside of Microsoft, unlike Android where is it necessary for every OEM to have to modify the kernel just to get Android to run on their device.

To compare Android to Windows Phone or Windows RT, the issue is one of closed source versus open source. Microsoft bakes support for certain SOC into Windows Phones kernel, which is why all Windows Phones have the same specs. The open nature of Android leaves it vulnerable to OEMs screwing things up.

I've no doubt the authors of Carrier IQ would say its keylogger had nothing to do with crapware, merely being a flawed implementation of "measuring operational information in Android devices", the end effect is the same.

The Windows kernel is touched by anyone who ever writes a driver for it, in other words every vendor shipping a Windows 8 tablet or phone today, or historically for any vendors that shipped Windows CE devices (which was the market I was comparing to, but it's also been true on desktops for all history).

The customization referred to is where carriers or hardware vendors takes white label software (Android, Windows CE, Windows 8), adds their own juice in the form of spyware, drivers, preinstalled apps, clicks a button and out pops something that gets flashed to devices.

Carrier IQ has nothing to do with this exploit or with the issue at hand, which is not an issue of "crapware".

The Windows kernel is closed source, no other OEMs are compiling it.

Your argument is flawed.

My comment was comparing security properties of customization processes of the two operating systems, not making any argument (which would require claims to disputed facts – I don't believe I made any).

They're not compiling it, they're writing drivers for it which are then linked in without a recompile.

> The code in the Windows kernel is never touched by anyone outside of Microsoft

Not exactly true. Device manufacturers and antimalware vendors add kernelmode device drivers all the time. It's not unheard of for very similar problems with that code to be found.

>unlike Android where is it necessary for every OEM to have to modify the kernel just to get Android to run on their device.

I think that will change once Android starts using the linux 3.7 kernel, which is supposed to unify ARM kernels.

Half the problem is that Linux's module interface is intentionally hobbled for non-GPL users, and in any case has no stable, versioned API. There'll probably never be something like a 'generic binary' Android, as there is Windows, that users just add some extra modules to, and that is by design.

Unless there is something I an missing, having a big kernel taking up RAM and disk space with support for hardware your phone doesn't have would be a waist of limited resources.

It would make porting CyanogenMod and other custom ROM's a lot easier to other phones, so I don't think that would be a waste. If manufacturers aren't going to support the devices anymore, at least the community will. Plus, it should make it a little easier for manufacturers, too.

The important difference is that nobody outside Microsoft can tell you whether something like this is in their current releases - and Microsoft will never say a word about it.

With Android we don't need to wait for Samsung or Google to acknowledge the problem and fix it. As someone else pointed out, Cyanogenmod is already patched.

This is to be expect for any operating system that becomes interesting enough for attacks.

Maybe when micro-kernels finally manage to become mainstream, or security rules like LinuxSE and similar, can the problem be minimized.

That causality is wrong. The vulnerability doesn't exist because Samsung products are attractive to exploit. It's a brain-damaged driver (exposes physical memory directly, which even /dev/mem doesn't anymore; and it's created with global write priviledges, meaning that literally no one with a clue about security ever looked at it). Samsung screwed up badly here.

A microkernel wouldn't have helped them here -- it looks to me like this driver exists precisely to defeat the existing protections that prevent userspace access to device memory. If that was the requirement, no kernel architecture would have helped this.

This problem (carelessness) cannot be minimized by micro-kernels or any other technical system, as this is not a technical fault. Samsung parked the company Mercedes in the middle of nowhere and left the key in the ignition and the engine running.

You may have done the same thing before - created a network share of your photos for others to see, but forgot to set the permissions to read-only instead of writable? This is exactly what Samsung did - they specifically marked a device with direct access to the devices memory as writable by everyone.

There are simply no technical solutions to incompetence ;) - this should never have made it out of engineering, let alone past QA.