By +Dietrich Schmitz
(tap tap....is this mic on?)
 |
| Windows 8 (x86) Security A veritable leaking collander. |
So far as I can tell, several hackers have succeeded in pawning Windows Legacy (x86). And from my perspective security should not be part of the responsibility of third-party software developers, that is, to bolster their applications with security sandboxes.
No, this is a complete diversion from the real, ongoing, old story. Microsoft's Windows 8 Legacy (x86) suffers from and inherits the circa 2000 WinNT kernel replete with all of its attendant security woes-- Windows is a collander.
The real issue is, if an exploit does succeed in breaking from a buffer overflow and attempts to escalate and access administrative privileges, why isn't the underlying operating system, Windows, intercepting the SYSTEM call process id? Hmm. Good question.
It isn't.
And, Google Engineers have all along (several years) inserted into their Chromium.org documentation their 'caveats' regarding just how much bolstering they can do on a Windows platform. It is clearly written and this is the text:
"Other caveats
The operating system might have bugs. Of interest are bugs in the Windows API that allow the bypass of the regular security checks. If such a bug exists, malware will be able to bypass the sandbox restrictions and broker policy and possibly compromise the computer. Under Windows, there is no practical way to prevent code in the sandbox from calling a system service.
In addition, third party software, particularly anti-malware solutions, can create new attack vectors. The most troublesome are applications that inject dlls in order to enable some (usually unwanted) capability. These dlls will also get injected in the sandbox process. In the best case they will malfunction, and in the worst case can create backdoors to other processes or to the file system itself, enabling specially crafted malware to escape the sandbox."
Okay, read that carefully now. What it says is that Google cannot stop a successful exploit, particularly an injected dll, from making a call to a SYSTEM service.
Now, if you ask me, at the point that the hackers have fuzzed the Windows executable and found a 'chink', it's game over. Because they know full well how to inject a DLL and they know full well that nothing is standing in their way from invoking a system call. The system will dutifully comply with the spawned process id with no other cross-checks.
That my friends is bad. Very bad. And that makes the whole Pwn2Own contest like 'shooting fish in a barrel'.
I have wagered that this year's entrant, a Google Samsung 550 Chromebook, will not have one successful exploit. This is the first year that any Linux-based operating system hardware has been submitted into the competition, by the way[1].
What sets Linux apart?
Well, in the case of Chromebook's ChromeOS, the kernel now employs seccomp-bpf (Berkey Packet Filters). What that means is that even if there is a successful exploit, it then must pass its system call and go thru seccomp-bpf which has a narrow limited set of system functions which can be performed in the context of the browser, none of which is administrative (root) control.
If you are using a Linux Distro with a kernel equal to or newer than 3.5 (Ubuntu 12.10 kernel 3.2 is backported to support seccomp-bpf), then Google Chrome is taking advantage of the seccomp-bpf sandbox support provided by the underlying Linux kernel. Here is a screen print of what you should expect to see in Chrome with a url of chrome://sandbox:
 |
| Chrome Sandbox Status Screen |
You see, unlike Microsoft Windows, Linux does take security seriously--very seriously--and stands in the way of any exploit to stop it cold in its tracks. There are other security measures being used in other Distros; Ubuntu uses AppArmor (an SELinux Module) and RedHat (Fedora too) uses SELinux sandboxing.
That is security the way it should be. No more shooting fish in a barrel. Software Vendors should innovate great software and assume the operating system is doing its job--including security!
Be safe with Linux. Be safe with Google's Chromebook.
-- Dietrich
[1] Edit: Pwnium 3 will take place on-site at the CanSecWest conference on March 7. Contestants will attempt to hack a Samsung 550 Chromebook. Pwnium 1 & 2 were held last year in two separate locations.
[1] Edit: Pwnium 3 will take place on-site at the CanSecWest conference on March 7. Contestants will attempt to hack a Samsung 550 Chromebook. Pwnium 1 & 2 were held last year in two separate locations.
Update: As predicted, all Chrome OS hack attempts failed.
0 comments:
Post a Comment