I spoke in my previous entry about how, when using Symbian's C++ descriptors for variables, traditional buffer overflows can be turned into denial of service (DoS) conditions. Well, I thought it might be important to point out that traditional overflows can still exist in Symbian-developed software to this day. Although not recommended, Symbian does allow the inclusion of 'libc\string.h', among other headers; this allows programmers to utilize all of the unsafe “C” functions we have become accustomed to (such as strcpy, strcat, sprintf, etc.).
The subject of buffer overflows, the danger they pose, and how best to mitigate them is well documented on the Internet; so, for brevity’s sake I won't cover it here yet again. However, what I will say is that some of the research I've done at Symantec has shown that these overflows are no less exploitable than if they were present on the desktop. Tim Hurman of Pentest Ltd. (here in the U.K.) demonstrated the same thing on Windows CE at the end of 2005 and recently, Collin Mulliner demonstrated this on Windows CE via MMS. To compound the issue, Symbian doesn't currently have technologies such as address space layout randomization (ASLR) or stack cookies to help mitigate the problem. While it is true that Symbian 9 can support the equivalent of NX (No eXecute bit—this allows the settings of an area of memory to be non-executable, which in turn can make exploitation more difficult in certain circumstances), this is only true for ARM’s v6 CPU where it manifests itself as XN (eXecute Never). In such a price-competitive hardware market, I wonder how many OEM's will choose to deploy the ARM v6 CPU if a cheaper alternative exists.
So, the question arises: when would developers write such code (that is, code that utilizes ANSI C string handling)? I would expect to see examples of such code (and thus, potential overflows) in Symbian applications that are based, in part, on highly portable code. That is, code that may have a generic engine, which runs on many operating systems and where only the user interface/threading model/file system access etc. are operating system-specific. Also, you never know; some crazy hardware OEM could write a kernel driver or two that included such code. :-)
While Symbian (especially Symbian 9) presents a drastically lower attack surface than say, Windows CE 5, there exists the potential for exploitable vulnerabilities that yield remote compromise. It is important that developers of all applications employ a secure secure development lifecycle (SDL) in their respective organizations to ensure they don't unwittingly expose their customers to an increased risk through the inclusion of unsafe code.