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...
With the advent of the Symbian mobile operating system we have been introduced to several new descriptors for different types of variables. These descriptors are used when writing software with Symbian's C++ API and are not standard C-style strings, but instead “classes” that perform strict type and length checking. These classes are designed to protect against buffer overflows and general memory corrupt bugs, among other things.
While this design is helpful because it stops overflows from overwriting the stack and heap, developers could develop a false sense of security. For what traditionally would have been a vulnerability that leads to arbitrary code execution, it is now potentially a vulnerability that causes a denial of service (DoS) condition.
In a previous blog I wrote about security in municipal Wi-Fi networks and talked about what I called network identification. I wanted to talk a little more about that now. I think this is actually one of the hardest problems to deal with.
Just to recap, the problem is that when you attempt to connect to a wireless network, you do so based on the network name (the SSID). That name, however, is a very poor identifier. The administrator of the access point can name it whatever they like. So, if I want to setup an access point and name it "GoogleWi-Fi", I can. And now when anyone in range attempts to connect to a wireless network they will see one called "GoogleWi-Fi". So, how do you know who you're connecting to?
People have suggested a number of approaches. I've heard some suggestions around educating users...
I posted a blog in May that spoke about the potential for remote code execution on Windows CE devices and the problems involved with patching. I also alluded to some research Symantec had been doing at the time. Well, at DefCon this past weekend, Collin Mulliner demonstrated a remote code execution flaw via MMS on Windows CE.
Collin's slides show how he used a malformed MMS message to achieve arbitrary code execution on a device, simply by having a user view the message. This is obviously of great concern; Windows Mobile devices are becoming more and more prevalent and the substantial challenges with patching continue to exist.
At the end of 2005, the Symantec Advanced Threat Research team performed a detailed...
