Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Security Response

Windows CE 6: The Improvement Over Windows CE 5

Created: 15 Dec 2006 08:00:00 GMT • Updated: 23 Jan 2014 18:54:27 GMT
Ollie  Whitehouse's picture
0 0 Votes
Login to vote

Ciao! Back in May, at the Microsoft Embedded Developer Conference in Las Vegas, Microsoft provided a number of presentations on Windows CE 6. The following is a summary of the improvements in Windows CE 6, which either directly or indirectly impact upon the security. The points below are taken from the slide decks of the presentations and are distilled down with some commentary added. It should be noted that it is not currently clear when or if Windows CE 6 will be adopted by the Windows Mobile Group. This entry follows up on the blog regarding Windows CE/Mobile 5, which I posted earlier this week.

From the talk Windows CE 6 Overview by David Kelly & Tim Kiesow of Microsoft, I have taken the following points away:
  • It supports safe SEH for security compliance (/GS)
  • Secure C Run-Time Libraries (Same as Windows CE 5.1)
  • PREfast support for ARM, MIPS, and SH
  • Increase from 32 to 32,000 processes on the device
  • Instead of a single 2GB VM for all processes now 2GB per process (more akin to the desktop)
  • Separation of user and kernel mode space
  • File system can support data encryption
  • Added 802.11i support for WPA2 compliance
  • Windows Media DRM 10 PD and ND

The “Premium source program” will provide more access to more source code, including:
• Graphic windowing and events subsystem (GWES)
• Networking (TCP/IP, IPv6)
• Expanded file system
• More device drivers

From the talk Inside The Windows CE Kernel by John Hatch & Bor-Ming Hsieh of Microsoft, the following points were taken away:
• Critical OS components moved into kernel space (critical drivers, file system, and graphical window manager into the kernel)
• New shared heap (R/W for kernel R/O for user land)
• 1GB per process space
• New operating system layout
• In-depth security review of (implies there might have been issues):
o System calls
o Handles
o Exception Handling
o Memory Allocation
o Loader
• Improved parameter validation for system calls (implies there might have been issues)
• Per-Process page and handle tables
o Greatly improves process isolation
o Improves code robustness
• Secure stack
o System calls run on special kernel side stacks
o Safeguards system calls from stack tampering
• Robust heaps
o Heap control structures separated from heap data
• Safe Remote Heaps for OS components
o OS servers can open heaps in user process
o R/W for servers, R/only for user
o Performance optimization and safety from tampering

From the talk Developing Bootloaders for Windows CE by Glen Langer of Microsoft and Steve Maillet of Embedded Fusion, I have taken the following points away:
• Support for secure boot loaders
• Public / private key based
• Based around file signing
• Features supported in hardware (partial list)
o On-chip, tamper-resistant boot ROM
o On-chip RAM (secure key storage)
o Cryptographic support
o JTAG can be disabled
o Fusible or one-time programmable elements
• They acknowledge if JTAG is enabled, it all “falls apart”
• There are more complex attack scenarios that require secure PCB design to mitigate

From the talk Porting Drivers to the Next Version of Windows CE by Juggs Ravalia of Microsoft, the following points were taken away:
• Embedded (nested) pointers and how they can be used for attack, such as:
o Pass an embedded pointer to some kernel address space and ask the driver to read/write to the addressed buffer, thereby potentially modifying the kernel
o There is a lot of emphasis around validation to mitigate this
o The kernel will perform parameter pointer validation
o It’s down to the API to perform embedded pointer validation
• The thread permissions model has changed in drivers (so they don't have to change their own permissions)
• There is strong emphasis on copying the “callers buffer” (with secure copy) and then using that copy, as opposed to using the callers buffer itself (which could subsequently be modified)

All in all, it looks like Microsoft have sat down and taken a long hard look at the security of Windows CE. Certainly, what the above does demonstrate is that Microsoft is realizing there is a need to address security in mobile devices (which was also evident from my previous blog posts on Windows CE/Mobile security). However, unlike their desktop environment where there is normally a method of upgrading older PCs to newer operating systems, it is rare in the mobile handset world for manufacturers to provide significant upgrade ROMs from older devices. Part of the reason for this is technical, but mostly it’s financial: why would a handset manufacturer want to give (or charge a paltry sum) for an upgrade to old hardware when it can have its customers replace handsets every six months with new ones and make more profit? This may be sad, but it’s true, I’m afraid. When it comes to security, this path is a real headache!