[HTC Wildfire S] no.human.being:
Well crashing a process (aka "Denial of Service"-attack) is one thing, but buffer overflows can often be used for actually overtaking the entire execution context (and with it the privileges) of foreign (possibly even remote) processes. There are dozens of possibilities of overtaking entire remote machines (e. g. servers) using buffer overflow methods.

Over the last 2 years, I have done quite a bit of research concerning buffer overflow methods that could be performed on a well-known, highly privileged daemon process, that's being used on many machines running POSIX compliant systems. It's quite shocking what you can find when you start digging very deep into this, but this would obviously bring us very far off-topic.

The main vulnerability we discovered is fixed now, but chances are that if the vulnerability was known to you when it was still there, the privileges you gained via the exploit at that time will stick with you for quite some amount of time, as the exploit messes with a cryptographic key storage on the target system and you cannot easily distinguish the "legit" keys from "illegit" ones that were injected using the exploit once the exploit got through, so if you used the exploit at the time where the vulnerability was still there, your keys will be "authenticated" to the server and will remain so even after installing a patched version, that no longer exposes the vulnerability, until a system administrator actively removes the "illegit" keys from the key storage.

So buffer overflow attacks aren't just "fun" at all. They're a very serious "weapon" in the arsenal of a hacker or penetration tester.

It's an interesting thing, however, that the "big machines" (computers, servers, etc.) are much easier to overtake than embedded systems. The security of Android actually seems very "hardened". It's not perfect (you see, exploits such as zergRush do succeed), but if this was a regular Linux machine, I would probably have been through with it on the first day by cracking its shadow files (that Android doesn't make use of at all).You see, Linux isn't that insecure either. It's used for large servers in critical applications. But it doesn't secure "against the will of the owner". On a Linux machine, physical access is root access. This means that attaining root privileges on a Linux machine is not that difficult, as long as you're "physically present" on the computer. This is by design. Linux only secures against processes and remote users and errors by local users, not neccessarily against local users that are really willing to overtake the system.

With Android the case is different. Android is definitely designed to secure against the phone user. It was designed to prevent the phone user from fiddling around too much with the system. Additionally, Android's attack surface seems to be extremely reduced from the Linux one, as it's much more "lightweight" and has much less daemon processes running. This is probably mainly due to ressource constraints on the embedded systems, but I must also admit that Google seems to have done quite a good job in securing the system. Of course the act of "securing against the owner" is questionable, but at least it seems they knew how to do it, so probably the overall security of Android isn't that bad either.