It's painful to watch Android deal with endemic security problems that Windows began addressing over a decade ago. Note this isn't the first occurrence of crapware resulting from OS customization ending up on a few million Android devices, I remember at least one more vendor shipping a setuid root binary.
Can anyone comment on Windows 8's customization model from the manufacturer's perspective? A wild guess is that something like this is much less likely: even if a driver leaves some kernel object unsecured, access is difficult given how heavily walled off native APIs are on WinRT.
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.
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).
> 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.
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.
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.
Can anyone comment on Windows 8's customization model from the manufacturer's perspective? A wild guess is that something like this is much less likely: even if a driver leaves some kernel object unsecured, access is difficult given how heavily walled off native APIs are on WinRT.