Te respondo otra vez:

Aparte de los overflows (buffer, heap, integer, etc) existen lo que se llaman Race conditions, o condiciones de carrera, aunque creo que ya no se dan tanto como antes.

Una race condition es cuando un programa entre la llamada a función privilegiada, y acceso a algún recurso (generalmente un fichero o un socket) tarda un tiempo, que a nuestros ojos es instántaneo, pero para un procesador puede ser visto como a cámara lenta.

Por ejemplo, imagina que hay una máquina empaquetando zapatos. Coge una caja, la abre, introduce los zapatos en la caja, y la cierra.

La condición de carrera sería si hubiera alguien, persona o máquina más rápido que el proceso de introducir los zapatos y cerrar la caja.

Si una persona consigue mediante un gesto rápido ¡zas! quitar los zapatos o sustituirlos por otro, tendríamos una condición de carrera.

En un programa por ejemplo se produciría una condición de carrera si:

1. Se abre un fichero con datos importantes,
2. Se le otorgan permisos  con permisos de administrador.
3. Se escribe el fichero.

Si entre el paso 1 y 2, Otro programa está sobreescribiendo repetidamente (en un bucle) ese fichero y es más rápido que el programa con la condición de carrera un usuario no priviegiado podría escribir en ese fichero antes de que le sean otorgados los permisos adecuados.

Otra race condition más tonta puede ser que los pasos sean o si los pasos fueran 1,3 y 2 (grave error), porque entonces tendría el programa atacante más tiempo todavía.

Si buscan por condición de carrera o race condition verás un montón de problemas de este tipo.

En cuanto a la segunda pregunta, hombre, un programa es un programa, es solo un trozo de código.

Por ejemplo:

#include <stdio.h>
  int main(void) {
    puts ("Hola Mundo");
}

Ahí tienes un programa invulnerable al 100%. ¿Que no hace mucho? no deja de ser un programa.

Lo que tú vienes a decir, más que un programa es una aplicación (Gmail, Oscommerce, Internet Explorer, Office, Firefox, Adobe Acrobat Reader).

Las aplicaciones tienen normalmente muchas formas de recibir datos de un atacante, las 3 que has descrito, más un socket TCP o una tubería, una redirección del shell de comandos (que no deja de ser sino un fichero), argumentos en la línea de comandos, etc.

Cuanto mayor es el programa y más personas participen, más dificil es de mantener y siempre se puede escapar algo por dejadez o ignorancia (un programador nuevo, por ejemplo).

A las aplicaciones, las propias empresas realizan auditorías.

En teoría si es posible que hay aplicaciones con 0 bugs, pero la práctica es diferente.
De todas maneras hay aplicaciones en las que una vez que el programador ha aprendido, las parchea bien y las continúa programando de manera segura.

O sea que siempre puede haber algún fallo que se pueda descubrir, pero técnicamente pueden existir programas perfectos hasta que se descubra algún tipo nuevo de vulnerabilidad no descubierta (piensa la primera vez que se descubrión un heap overflow) por ejemplo...

Espero que te haya aclarado algo.