3,1. Programas de seguros Considere lo que queremos decir cuando decimos que un programa es "seguro".

Vimos en el captulo 1 que la seguridad implica un cierto grado de confianza que el programa aplica espera que la confidencialidad, integridad y disponibilidad. Desde el punto de vista de un programa o un programador, cmo podemos mirar a un componente de software o un fragmento de cdigo y evaluar su seguridad? Esta cuestin es, por supuesto, similar al problema de la evaluacin de la calidad del software en general. Una forma de evaluar la seguridad o la calidad es pedirle a la gente para nombrar las caractersticas del software que contribuyen a su seguridad general. Sin embargo, es probable que obtener respuestas diferentes a diferentes personas. Esta diferencia se debe a la importancia de las caractersticas depende de quin est analizando el software. Por ejemplo, una persona puede decidir que el cdigo es seguro, ya que toma mucho tiempo para romper sus controles de seguridad. Y alguien ms puede decidir el cdigo es seguro si se ha ejecutado durante un perodo de tiempo sin aparentes fracasos. Sin embargo, una tercera persona puede decidir que cualquier fallo potencial en el cumplimiento de los requisitos de seguridad hace que el cdigo inseguro. Una evaluacin de la seguridad tambin puede ser influenciado por la perspectiva general de una persona sobre la calidad del software. Por ejemplo, si la idea de su gerente de calidad es la conformidad con las especificaciones, entonces se podra considerar el cdigo de seguridad si cumple con los requisitos de seguridad, sean o no los requisitos son completa o correcta. Este punto de vista de seguridad desempe un papel cuando un fabricante mayor de computadoras entregado todas sus mquinas con las cerraduras con llave, ya que una cerradura con llave fue escrito en los requisitos. Pero las mquinas no eran seguras, porque todos los bloqueos se han configurado para utilizar la misma clave! Por lo tanto, otro punto de vista de la seguridad es la aptitud para el propsito, en este punto de vista, el fabricante claramente tena margen de mejora. En general, los profesionales suelen mirar a la cantidad y tipos de fallas de las pruebas de la calidad de un producto (o falta de ella). Por ejemplo, los desarrolladores de rastrear el nmero de defectos encontrados en los requisitos, diseo, e inspecciones de cdigo y los utilizan como indicadores de la posible calidad del producto final. Recuadro 1.3 se explica la importancia de separar las causas de faultsthe problemsfrom los fracasos, los efectos de las fallas.

Fijacin de Fallas Una manera de juzgar la calidad en materia de seguridad ha estado reparando las fallas. Es posible argumentar que un mdulo en el que 100 faltas fueron descubiertos y se fija es mejor que otro en el que slo 20 errores fueron descubiertos y se fija, lo que sugiere que el anlisis ms riguroso y las pruebas haban llevado a la conclusin de que el mayor nmero de fallas. Au contraire, desafa a su amigo: una pieza de software con 100 fallas descubiertas es de por s llena de problemas y claramente podra haber cientos ms esperando a aparecer. La opinin de su amigo se ve confirmada por la literatura de pruebas de software, software que tiene muchos defectos desde el principio es probable que muchos otros siguen esperando a ser encontrado.

Recuadro 1.3: IEEE Terminologa para la Calidad

Con frecuencia, se habla de "errores" en el software, un trmino que puede significar muchas cosas diferentes dependiendo del contexto. Un error puede ser un error en la interpretacin de un requisito, un error de sintaxis en una pieza de cdigo, o la causa (como-todava-desconocido) de un fallo del sistema. El IEEE ha sugerido una terminologa estndar (en el estndar IEEE 729) para la descripcin de los errores en nuestros productos de software [IEEE83]. Cuando un ser humano comete un error, un error de llamada, en la realizacin de alguna actividad de software, el error puede conducir a un fallo o una definicin incorrecta paso, mando, proceso, o los datos en un programa de ordenador. Por ejemplo, un diseador puede malinterpretar un requisito y crear un diseo que no est de acuerdo con la intencin real del analista requisitos y el usuario. Este fallo de diseo es una codificacin del error, y puede dar lugar a otras fallas, como el cdigo incorrecto y una descripcin incorrecta en un manual de usuario. Por lo tanto, un solo error puede generar muchas faltas, y un fallo puede residir en cualquier desarrollo de producto o mantenimiento. Una falla es una desviacin del comportamiento requerido del sistema. Puede ser descubierta antes o despus de la entrega del sistema, durante la prueba, o durante la operacin y mantenimiento. Dado que los documentos de requerimientos puede contener fallos, un fallo indica que el sistema no funciona como se requiere, aunque se pueden realizar como se especifica. Por lo tanto, una falla es una vista del interior del sistema, como se ve por los ojos de los desarrolladores, mientras que un fracaso es un punto de vista externo: un problema que ve el usuario. No todos los fallos corresponde a un fallo, por ejemplo, si el cdigo defectuoso nunca se ejecuta o un estado particular, nunca se escribe, entonces el fallo nunca har que el cdigo de error. Los primeros trabajos en la seguridad informtica se bas en el paradigma de la "penetracin y el parche", en el que los analistas de buscar y reparar las fallas. A menudo, una alta calidad "equipo tigre" se convocara para probar la seguridad de un sistema al tratar de hacer que falle. La prueba fue considerada como una "prueba" de la seguridad, si el sistema ha soportado los ataques, se considera seguro. Por desgracia, con demasiada frecuencia la prueba se convirti en un contraejemplo, en el que los problemas graves no slo una sino varias de seguridad fueron descubiertos. El descubrimiento de problemas, a su vez condujo a un esfuerzo rpido para "parchar" el sistema para reparar o restaurar la seguridad. (Vase el anlisis de Schell en [SCH79].) Sin embargo, los esfuerzos fueron en gran medida de parche intil, haciendo que el sistema menos seguro en lugar de ms seguridad, ya que con frecuencia introduce nuevas fallas. Hay por lo menos cuatro razones para ello. La presin para reparar un problema especfico de alentar un enfoque estrecho de la falla en s y no en su contexto. En particular, los analistas prestaron atencin a la causa inmediata del fracaso y no el diseo subyacente o faltas requisitos. La falla a menudo efectos secundarios no obvias en lugares distintos de la zona inmediata de la falla. Fijacin de un problema a menudo causado un fallo en otro lugar, o el parche abordado el problema en un solo lugar, y no en otros lugares relacionados. La culpa no puede ser fijado correctamente debido a la funcionalidad del sistema o el rendimiento sufrira como consecuencia.

Un comportamiento inesperado Las deficiencias de penetrar-y-patch llevado a los investigadores a buscar una mejor manera de estar seguro de que el cdigo cumple con sus requisitos de seguridad. Una manera de hacerlo es comparar las necesidades con el comportamiento. Es decir, para entender la seguridad del programa, podemos examinar los programas para ver si se comportan como sus diseadores previsto o esperado los usuarios. Llamamos a esta conducta inesperada una falla de seguridad del programa, sino que es un comportamiento inapropiado de los programas causado por una vulnerabilidad del programa. Por desgracia, la terminologa en el mbito de la seguridad informtica no es compatible con el estndar IEEE se describe en la barra lateral 3-1; los trminos "vulnerabilidad" y "error" no se asignan directamente a la caracterizacin de las fallas y los fracasos. Un defecto puede ser un fallo o avera, y una vulnerabilidad por lo general describe una clase de defectos, como un desbordamiento de bfer. A pesar de la inconsistencia, es importante que recordemos que debemos ver las vulnerabilidades y fallas a partir de dos perspectivas, causa y efecto, para que podamos ver lo que falla que caus el problema y lo que falta (si existe) es visible para el usuario. Por ejemplo, un caballo de Troya puede haber sido inyectado en un pedazo de la explotacin de un defecto codea vulnerabilitybut el usuario an no ha visto el comportamiento malicioso que el caballo de Troya. Por lo tanto, debemos abordar las fallas del programa de seguridad de dentro y fuera, para encontrar las causas no slo de las fallas existentes, sino tambin de los incipientes. Por otra parte, no es suficiente para identificar estos problemas. Tambin hay que determinar la forma de prevenir el dao causado por posibles defectos. Programa de las fallas de seguridad pueden derivar de cualquier tipo de fallo de software. Es decir, que cubren todo, desde una interpretacin errnea de los requisitos del programa a un error de un solo carcter en la codificacin o incluso escribiendo. Los defectos pueden resultar de problemas en un componente nico cdigo o del fracaso de varios programas o trozos de programa para interactuar de forma compatible a travs de una interfaz compartida. Las fallas de seguridad pueden reflejar el cdigo que fue diseado intencionalmente o codificados para ser malicioso o cdigo que se desarroll slo en una forma descuidada o equivocada. Por lo tanto, tiene sentido dividir las fallas del programa en dos categoras distintas lgicas: involuntarios errores humanos frente a las fallas maliciosos, inducido deliberadamente. Estas categoras nos ayudan a entender algunas formas de prevenir la introduccin accidental o intencional de los defectos en el cdigo futuro, pero todava tenemos que hacer frente a sus efectos, independientemente de la intencin. Es decir, en las palabras de Sancho Panza en El hombre de La Mancha ", no importa si la piedra da en el cntaro o el lanzador golpea la piedra, va a ser mal para el cntaro". Un error involuntario puede causar dao por igual a los usuarios y sus organizaciones, como puede un error inducido deliberadamente. Por otra parte, un ataque al sistema a menudo se aprovecha de un fallo de seguridad no intencional para realizar dao intencional. De la lectura de la prensa popular (ver Recuadro 3-2), se podra concluir que los incidentes intencionales de seguridad (llamado ataques cibernticos) es la mayor amenaza para la seguridad hoy en da. De hecho, los errores humanos involuntarios lisos, son ms numerosos y causan mucho ms dao. Recuadro 3.2: el Continuo Aumento en los ataques cibernticos Emergencia la Universidad Carnegie Mellon Equipo de Respuesta (CERT) el seguimiento del nmero y tipo de vulnerabilidades y ataques cibernticos en todo el mundo informado. Parte de la misin del CERT es advertir a los usuarios y desarrolladores de nuevos problemas y tambin para proporcionar

informacin sobre la forma de solucionarlos. De acuerdo con el centro de coordinacin CERT, menos de 200 vulnerabilidades conocidas fueron reportados en 1995, y ese nmero oscil entre 200 y 400 de 1996 a 1999. Sin embargo, el nmero aument dramticamente en 2000, con ms de 1.000 vulnerabilidades conocidas en el ao 2000, casi 2.420 en 2001, y 4.129 en 2002. A continuacin, la tendencia parece disminuir ligeramente con 3.784 en 2003 y 3.780 en 2004, pero el recuento se dispar de nuevo con 5.990 en 2005 y 1.597 en el primer trimestre de 2006 solamente. (Para conocer las estadsticas actuales, consulte http://www.cert.org/stats/cert_stats.html~~V Nmero de vulnerabilidades). Cmo se traduce esto en los ataques cibernticos? CERT se notificaron ms de 137.000 incidentes en 2003 y 319.992 en total para los aos 19882003. Debido a que el nmero de incidentes se haba vuelto tan grande, la ataca tan generalizado, y la estructura de informacin utilizada tan ampliamente, CERT dej de publicar un recuento de los incidentes en el 2004, argumentando que los indicadores ms significativos eran necesarios. Por otra parte, a partir de junio de 2006, Symantec Norton antivirus comprobado por ms de 72 mil patrones de virus conocidos. El Computer Security Institute y el FBI cooperan para realizar una encuesta anual de aproximadamente 500 grandes instituciones: empresas, organizaciones gubernamentales e instituciones educativas [CSI05]. La respuesta, desde 1999 hasta 2005 ha sido bastante constante: en cada ao, aproximadamente el 40 por ciento de los encuestados informaron de uno a cinco incidentes, el 20 por ciento de seis a diez, y el 10 por ciento ms de diez. Los encuestados reportaron prdidas totales superiores a $ 42 millones debido a los ataques de virus. Est claro que es tiempo de tomar en serio la seguridad, tanto como usuarios y desarrolladores. Lamentablemente, no contamos con las tcnicas para eliminar o tratar todos los fallos de seguridad del programa. Como Gasser [GAS88] notas, la seguridad es fundamentalmente fuerte, la seguridad a menudo entra en conflicto con la utilidad y el rendimiento, no hay "" bala de plata "para alcanzar la seguridad sin esfuerzo, y las falsas soluciones de seguridad impiden el progreso real hacia una programacin ms seguro. Hay dos razones para esta situacin angustiante. Programa de controles se aplican a nivel de cada programa y el programador. Cuando se prueba un sistema, tratamos de asegurarnos de que la funcionalidad prescrita en los requisitos se implementa en el cdigo. Es decir, nos tomamos un "debe hacer" lista de control y verificar que el cdigo hace lo que se supone que debe hacer. Sin embargo, la seguridad es tambin acerca de la prevencin de ciertas acciones: un "no debe hacer" la lista. Un sistema no debera hacer nada que no en su "debe hacer" la lista. Es casi imposible asegurar que un programa hace precisamente lo que su diseador o usuario previsto, y nada ms. Independientemente de la intencin del diseador o programador, en un sistema grande y complejo, las piezas que tienen que encajan bien interactuar en un nmero inmanejable de muchas formas. Nos vemos obligados a examinar y probar el cdigo para los casos tpicos o probable, que no de forma exhaustiva puede probar todas las combinaciones del estado y los datos para verificar el comportamiento de un sistema. As que el tamao y la complejidad impide la prevencin de defecto total o mediacin. Los programadores que deseen implantar el cdigo malicioso puede tomar ventaja de esta incompleto y ocultar algunos defectos con xito, a pesar de nuestros mejores esfuerzos.

Tcnicas de programacin y el software de ingeniera cambian y evolucionan mucho ms rpidamente que las tcnicas de seguridad informtica. As que a menudo nos encontramos tratando de obtener la tecnologa del ao pasado, mientras que los desarrolladores de software estn adoptando rpidamente year'stechnology today'sand siguiente. Sin embargo, la situacin est lejos de ser sombro. La seguridad informtica tiene mucho que ofrecer a la seguridad del programa. Al comprender qu puede ir mal y cmo protegerse contra ella, podemos disear tcnicas y herramientas para asegurar la mayora de las aplicaciones informticas. Tipos de fallas Para ayudar a nuestra comprensin de los problemas y de su prevencin o correccin, podemos definir las categoras que distinguen a un tipo de problema de otro. Por ejemplo, Landwehr et al. [LAN94] se presenta una taxonoma de las fallas del programa, que se dividen por primera vez en fallas intencionales y accidentales. Asimismo, se dividen las fallas intencionales en los 'malos' y no malintencionada. En la taxonoma, las fallas involuntarias se dividen en seis categoras: Error de validacin (incompleta o inconsistente): comprobaciones de permisos error de dominio: el acceso controlado a los datos serializacin y alias: el orden del programa de flujo inadecuada identificacin y autenticacin: base para la autorizacin lmite de violacin condicin: fracaso en el primer caso o la ltima otros errores lgicos explotables Otros autores, tales como Tsipenyuk et al. [TSI05], el proyecto OWASP [OWA05], y Landwehr [LAN93], han elaborado listas similares. Esta lista nos da una visin general til de las formas en que los programas pueden dejar de cumplir con sus requisitos de seguridad. Salimos de nuestra discusin de las dificultades de identificacin y autenticacin para el captulo 4, en el que se investiga tambin la separacin en los dominios de ejecucin. En este captulo, nos dirigimos a las otras categoras, cada una de ellas tiene ejemplos interesantes

3,2. Los errores no malintencionada de programa El ser humano, los programadores y desarrolladores de otros comete muchos errores, la mayora de las cuales son intencionales y no malintencionada. Muchos de dichos errores causar un mal funcionamiento del programa, pero no conducen a vulnerabilidades de seguridad ms graves. Sin embargo, algunas clases de errores han afectado a los programadores y los profesionales de la seguridad durante dcadas, y no hay razn para creer que va a desaparecer. En esta seccin se consideran tres tipos de errores clsicos que han permitido a muchas brechas de seguridad ms recientes. Le explicamos cada tipo, por qu es relevante para la seguridad, y cmo puede prevenirse o mitigarse. Desbordamiento de bfer Un desbordamiento de bfer es el equivalente informtico de tratar de verter dos litros de agua en una jarra de un litro: Un poco de agua va a derramarse y hacer un lo. Y en la computacin, lo que es un lo de estos errores han hecho! Definicin Un buffer (o matriz o una cadena) es un espacio en el que los datos se llevar a cabo. Un tampn reside en la memoria. Debido a que la memoria es finito, la capacidad de un tampn es finita. Por esta razn, en muchos lenguajes de programacin, el programador debe declarar el tamao mximo del bfer para que el compilador puede dejar de lado esa cantidad de espacio. Veamos un ejemplo para ver como desbordamientos de bfer que puede suceder. Supongamos que un programa en lenguaje C y contiene la declaracin: muestra de carbn de lea [10];

El compilador deja de lado 10 bytes para almacenar el buffer, un byte por cada uno de los 10 elementos de la matriz, muestra [0] a travs de la muestra [9]. Ahora ejecute la instruccin: muestra [10] = 'B';

El subndice est fuera de lmites (es decir, que no se encuentra entre 0 y 9), as que tenemos un problema. Lo ms bonito de resultados (desde una perspectiva de la seguridad) es que el compilador para detectar el problema y marcar el error durante la compilacin. Sin embargo, si la declaracin se muestra [i] = 'B';

no hemos podido identificar el problema hasta que se estableci durante la ejecucin de un subndice demasiado grande. Sera til si, durante la ejecucin, el sistema produce una advertencia de un mensaje de error con el subndice de los lmites. Desafortunadamente, en algunos idiomas, tamaos de bfer no tiene que estar predefinidas, as que no hay manera de detectar un error fuera de la cancha. Ms importante an, el cdigo necesario para revisar cada subndice en contra de su valor mximo potencial toma tiempo y el espacio durante la ejecucin y los recursos que se aplican para

detectar un problema que se produce con poca frecuencia. Incluso si el compilador se cuidaron en el anlisis de la declaracin tampn y uso, este mismo problema puede ser causado con punteros, para los que no hay manera razonable para definir un lmite apropiado. Por lo tanto, algunos compiladores no generan el cdigo para comprobar superior a los lmites. Vamos a examinar este problema ms de cerca. Es importante reconocer que el desbordamiento potencial causa un serio problema slo en algunos casos. El problema ocurrencia depende de lo que es adyacente a la muestra matriz. Por ejemplo, supongamos que cada uno de los diez elementos de la muestra matriz se llena con la letra A y la referencia errnea utiliza la letra B, como sigue: for muestra muestra (i = 0; [i] [10] i <= 9; = = i + +) 'A'; 'B'

Todos los programas y elementos de datos estn en la memoria durante la ejecucin, compartiendo el espacio con el sistema operativo, otro cdigo, y las rutinas residentes. As que hay cuatro casos a considerar en la decisin de que el 'B' se va, como se muestra en la Figura 3-1. Si se desborda el personaje extra en el espacio de datos del usuario, simplemente sobrescribe un valor variable existente (o puede ser escrito en un lugar, que an no se utiliza), quizs afectando resultado del programa, sino que afecta a ningn otro programa o de datos.

Figura

3-1.

Lugares

donde

el

desbordamiento

de

buffer

puede.

En el segundo caso, el "B" entra en rea de programa del usuario. Si se superpone a una instruccin ya ejecutada (lo que no se volver a ejecutar), el usuario debe percibir ningn efecto. Si se superpone a una instruccin que an no se ha ejecutado, la mquina va a tratar de ejecutar una instruccin con el cdigo de operacin 0x42, el cdigo interno de "B" del personaje. Si no hay ninguna instruccin con 0x42 cdigo de operacin, el sistema se detiene ante una excepcin de instruccin ilegal. De lo contrario, la mquina se utilice bytes posteriores como si fueran el resto de la instruccin, con xito o fracaso dependiendo del significado de los contenidos. Una vez ms, slo el usuario puede experimentar un efecto. Los casos ms interesantes ocurren cuando el sistema posee el espacio inmediatamente despus de la matriz, que se desborda. Trasladndose hacia los datos del sistema o reas de cdigo produce resultados similares a los de espacio del usuario: la computacin con un valor defectuosa o est tratando de ejecutar una operacin incorrecta. Implicacin de Seguridad En esta seccin se consideran defectos del programa por causas intencionales o no malintencionada. Sin embargo, recuerde que incluso si una falla provino de un error de buena fe, el fallo todava puede causar daos graves. Un atacante malicioso puede explotar estas fallas. Supongamos que una persona con malas intenciones entiende el dao que se puede hacer por un

desbordamiento de bfer, es decir, se trata de algo ms que un programador normal, errante. El programador malicioso se ve en los cuatro casos descritos en la Figura 3-1 y piensa sinuosamente sobre los dos ltimos: Qu valores de los datos que el atacante podra introducir el tampn justo despus de causar dao o perjuicio, y lo previsto cdigos de instruccin que el sistema podra verse obligado a ejecutar? Hay muchas respuestas posibles, algunas de las cuales son ms malvolos que otros. A continuacin, presentamos dos ataques de desbordamiento de bfer que se utilizan con frecuencia. (Ver [ALE96] para ms detalles.) En primer lugar, el atacante puede reemplazar el cdigo en el espacio del sistema. Recuerde que cada programa se aplica por el sistema operativo y que el sistema operativo se puede ejecutar con privilegios ms altos que los de un programa regular. Por lo tanto, si el atacante puede hacerse con el control al hacerse pasar por el sistema operativo, el atacante puede ejecutar muchos comandos en un papel de gran alcance. Por lo tanto, mediante la sustitucin de unas pocas instrucciones inmediatamente despus de regresar de procedimiento de su propia, el atacante recupera el control del sistema operativo, posiblemente con privilegios elevados. Si el bfer se desborda en el espacio del sistema de cdigo, el atacante simplemente inserta datos de desbordamiento que se corresponden con el cdigo de mquina para obtener instrucciones. Por otro lado, el atacante puede hacer uso del puntero de pila o el registro de retorno. Llamadas subprocedimiento se manejan con una pila, una estructura de datos en la que el elemento ms reciente insertado es el siguiente eliminado (ltimo en llegar, primero servido). Esta estructura funciona bien porque las llamadas a procedimientos se pueden anidar, con cada cambio provoca que el control de traslado de regreso a la rutina inmediatamente anterior en su punto de ejecucin. Cada vez que un procedimiento se llama, sus parmetros, la direccin de retorno (la direccin inmediatamente despus de su llamada), y otros valores locales se insertan en una pila. Un puntero de pila antigua tambin se inserta en la pila, y un registro puntero de pila se recarga con la direccin de estos nuevos valores. El control se transfiere entonces a la subprocedimiento. A medida que el subprocedimiento se ejecuta, obtiene los parmetros que se encuentra utilizando la direccin apuntada por el puntero de pila. Tpicamente, el puntero de pila es un registro en el procesador. Por lo tanto, al causar un desbordamiento en la pila, el atacante puede cambiar ya sea el puntero de pila de edad (cambiando el contexto del procedimiento de llamada) o la direccin de retorno (lo que provoca el control de la transferencia donde el atacante quiere que cuando se restablezca el subprocedimiento). Cambiando el contexto o la direccin de retorno permite al atacante redirigir la ejecucin de un bloque de cdigo que el atacante quiera. En ambos casos, un poco de experimentacin es necesaria para determinar en donde el desbordamiento es y cmo controlarlo. Sin embargo, el trabajo a realizar es relativamente smallprobably un da o dos para un analista competente. Estos desbordamientos de buffer son cuidadosamente explicado en un documento elaborado por Mudge [MUD95] del grupo de seguridad L0pht el famoso ordenador. Pincus y Baker [PIN04] revis los desbordamientos de bfer diez aos despus de Mudge y encontr que, lejos de ser un aspecto menor de ataque, desbordamientos de bfer ha sido un vector de ataque muy importante y han dado lugar a varios otros tipos de ataques nuevos. Un estilo alternativo de desbordamiento de bfer se produce cuando los valores de los parmetros se

pasan en una rutina, especialmente cuando los parmetros se pasan a un servidor web en Internet. Los parmetros se pasan en la lnea de direccin, con una sintaxis similar a la http://www.somesite.com/subpage/userinput.asp?parm1 Y parm2 = = (808) 555-1212 2009Jan17

En este ejemplo, la pgina inputdelusuario recibe dos parmetros, parm1 con valor (808) 555-1212 (quizs un nmero de telfono EE.UU.) y parm2 con valor 2009Jan17 (quizs una fecha). El navegador web en la mquina de la persona que llama a aceptar los valores de un usuario que probablemente completa los campos en un formulario. El navegador codifica los valores y los transmite de nuevo a la pgina web del servidor. El atacante podra cuestionar lo que el servidor se hara con un nmero de telfono muy largo, por ejemplo, uno con 500 o 1000 dgitos. Pero, usted dice, no hay telfono en el mundo tiene un nmero, que es, probablemente, exactamente lo que el desarrollador cree, por lo que el desarrollador ha asignado 15 o 20 bytes para un nmero de telfono mxima esperada de longitud. El programa de choque con 500 dgitos? Y si se bloquea, se puede hacer para dormir de una manera predecible y utilizable? (Para obtener la respuesta a esta cuestin, vase la investigacin de Litchfield del programa de Microsoft marcador [LIT99].) Pasar una cadena muy larga a un servidor web es una ligera variacin en el clsico de desbordamiento de bfer, pero no menos efectiva. Como se seal anteriormente, los desbordamientos de bfer han existido casi tan largo como los lenguajes de programacin de alto nivel con las matrices. Durante mucho tiempo, eran simplemente una molestia para los programadores y usuarios, una de las causas de los errores y, a veces incluso bloqueos del sistema. Ms bien poco, los atacantes han utilizado como vehculos para provocar primero una cada del sistema y, a continuacin un fracaso controlado, con una implicacin grave de seguridad. El gran nmero de vulnerabilidades de seguridad basados en desbordamientos de bfer muestra que los desarrolladores deben prestar ms atencin ahora a lo que se haba pensado para ser slo una molestia menor. La mediacin incompleta La mediacin incompleta es otro problema de seguridad que ha estado con nosotros desde hace dcadas. Los atacantes estn explotando para causar problemas de seguridad. Definicin Consideremos

el

ejemplo

de

la = =

seccin (808)

anterior: 555-1212 2009Jan17

http://www.somesite.com/subpage/userinput.asp?parm1 Y parm2

Los dos parmetros de parecerse a un nmero de telfono y una fecha. Es probable que el cliente (usuario) navegador web entra en esos dos valores en el formato especificado para facilitar el

procesamiento del lado del servidor. Qu pasara si parm2 se presentaron en 1800Jan01? O 1800Feb30? O 2048Min32? O 1Aardvark2Many? Algo es probable que falle. Al igual que con los desbordamientos de bfer, una posibilidad es que el sistema podra fallar catastrficamente, con una rutina es no en un error de tipo de datos, ya que trat de manejar un mes, llamado "Min" o incluso un ao (como 1800) que estaba fuera de rango. Otra posibilidad es que el programa receptor seguira para ejecutar pero podra generar un resultado muy malo. (Por ejemplo, imagine la cantidad de inters que vencen hoy en un error de facturacin con una fecha de inicio del 1 de enero 1800.) Por otra parte, el servidor de procesamiento puede tener una condicin predeterminada, de decidir el tratamiento 1Aardvark2Many el 3 julio de 1947. Las posibilidades son infinitas. Una manera de abordar los posibles problemas es tratar de anticiparse a ellos. Por ejemplo, el programador en los ejemplos anteriores puede haber escrito el cdigo para comprobar la correccin en el lado del cliente (es decir, el navegador del usuario). El programa cliente puede buscar y fuera de la pantalla los errores. O bien, para evitar el uso de datos sin sentido, el programa puede restringir las opciones slo a los vlidos. Por ejemplo, el programa de suministro de los parmetros podra haberlos solicitado mediante el uso de una lista desplegable o la eleccin de la que slo los doce meses convencionales habran sido posibles opciones. Del mismo modo, el ao podra haber sido probado para asegurar que el valor fue entre 1995 y 2015, y los nmeros de la fecha tendra que haber sido apropiado para los meses en que se producen (no 30 de febrero, por ejemplo). El uso de estas tcnicas de verificacin, el programador puede haberse sentido bien aislado de los problemas posibles que un usuario descuidado o malicioso podra causar. Sin embargo, el programa sigue siendo vulnerable. Al comprimir el resultado en la direccin URL de retorno, el programador deja estos campos de datos en un lugar que el usuario puede acceder (y modificar). En particular, el usuario puede editar la lnea de direccin, cambiar los valores de los parmetros, y vuelva a enviar la lnea. En el lado del servidor, no hay manera de que el servidor para saber si la lnea de la respuesta lleg desde el navegador del cliente o como resultado de la del usuario de la edicin de la URL directamente. Decimos en este caso que los valores de los datos no son completamente mediada: Los datos sensibles (a saber, los valores de los parmetros) estn en una condicin expuesta, incontrolada. Implicacin de Seguridad La mediacin incompleta es fcil de explotar, pero se ha ejercitado con menor frecuencia que los desbordamientos de bfer. Sin embargo, los valores de datos sin control representan una seria vulnerabilidad potencial. Para demostrar las implicaciones de seguridad de este defecto, se utiliza un ejemplo real, slo el nombre del proveedor ha sido cambiado para proteger a los culpables. Las cosas, Inc., fue una muy grande, proveedor internacional de productos de consumo, llamados Objetos. La empresa estaba dispuesta a vender sus objetos a travs de un sitio web, con lo que pareca ser una norma de aplicacin de comercio electrnico. La direccin de las cosas decidi dejar que algunos de sus internos a los desarrolladores producir el sitio web para que sus clientes pueden ordenar los objetos directamente desde la web.

Para acompaar a la pgina web, las cosas se desarrollaron una lista de precios completa de sus objetos, incluyendo fotos, descripciones, y djate caer-mens para el tamao, forma, color, olor, y cualquier otra propiedad. Por ejemplo, un cliente en la web pueden optar por comprar 20 de los objetos parte 555A nmero. Si el precio de una parte como eran de $ 10, el servidor web correctamente sera calcular el precio de las 20 piezas a $ 200. Luego, el cliente puede decidir si tener o no los objetos enviados por barco, por el transporte terrestre o por va electrnica. Si el cliente tuviera que elegir una entrega barco, el navegador del cliente Web que completar un formulario con parmetros como los siguientes: http://www.things.com/order.asp?custID=101&part=555A&qy=20&price = 10 & = barco en barco y shipcost = 5

&

total

205

Hasta ahora, todo bien, todo en el pasaje de parmetros es correcto. Sin embargo, este procedimiento deja abierta la declaracin de parmetros para la manipulacin maliciosa. Las cosas no deberan tener que pasar el precio de los artculos de nuevo a s mismo como un parmetro de entrada, presumiblemente, las cosas sabe lo mucho que su coste de objetos, y es poco probable que cambie radicalmente desde el momento en que el precio se cotiza en el mercado unas cuantas pantallas anterior. Un atacante malicioso puede decidir la explotacin de esta peculiaridad mediante el suministro de lugar la siguiente direccin URL, donde ha sido el precio reducido de $ 205 a $ 25: http://www.things.com/order.asp?custID=101&part=555A&qy=20&price = 1 y = barco en barco y shipcost =

&

total

25

Sorpresa! Funcion. El atacante podra haber ordenado los objetos de las cosas en cualquier cantidad a cualquier precio. Y s, este cdigo se ejecuta en el sitio web por un tiempo antes de que el problema fue detectado. Desde una perspectiva de seguridad, la ms seria preocupacin sobre este problema fue la cantidad de tiempo que podra haber corrido sin ser detectados. Si el mundo entero de pronto ech a correr al sitio web de las cosas y los objetos comprados en una fraccin de su precio, las cosas probablemente habran notado. Pero las cosas es lo suficientemente grande que nunca se han detectado unos pocos clientes un da de la eleccin de los precios que eran similares (pero ms pequeo que) el precio real, por ejemplo 30 por ciento de descuento. La divisin de comercio electrnico que han demostrado un beneficio ligeramente menor que las otras divisiones, pero la diferencia probablemente no habra sido suficiente para levantar las cejas de nadie, la vulnerabilidad podra haber pasado desapercibido durante aos. Afortunadamente, las cosas contrat a un consultor para hacer una revisin rutinaria de su cdigo, y el consultor de encontrar el error rpidamente. Este programa falla en el diseo web es fcil de imaginar en entornos web. Aquellos de nosotros interesados en la seguridad hay que preguntarse cuntos problemas similares hay en la ejecucin de cdigo de hoy? Y cmo esas vulnerabilidades cada vez se encuentra?

Tiempo-de-Comprobar errores de tiempo de uso La falla de programacin tercer investigar implica la sincronizacin. Para mejorar la eficiencia, los procesadores y sistemas operativos modernos suelen cambiar el orden en que las instrucciones y los procedimientos se ejecutan. En particular, las instrucciones que parecen ser adyacente en realidad no puede ser ejecutada inmediatamente despus de la otra, ya sea por orden intencionalmente cambiado o debido a los efectos de otros procesos en ejecucin concurrente. Definicin El control de acceso es una parte fundamental de la seguridad informtica, queremos asegurarnos de que slo los que debe acceder a un objeto que se les permite el acceso. (. Estamos estudiando los mecanismos de control de acceso en los sistemas operativos con mayor detalle en el Captulo 4) Todo el acceso solicitado debe estar regido por una poltica de acceso que indica que est permitido el acceso a lo que, a continuacin, la solicitud debe estar mediado por un agente de acceso de la poltica econmica la aplicacin de . Sin embargo, un problema de la mediacin incompleta se produce cuando el acceso no est marcada universalmente. El tiempo de comprobar el tiempo de uso (TOCTTOU) falla de la preocupacin de que la mediacin se lleva a cabo con un "bait and switch" en el centro. Tambin se conoce como una serializacin o defecto de sincronizacin. Para comprender la naturaleza de esta falla, considerar a una persona es la compra de una escultura que cuesta $ 100. El comprador retira cinco billetes de $ 20 a partir de una billetera, cuidadosamente que cuenta en la parte delantera del vendedor, y los pone sobre la mesa. Entonces el vendedor se da vuelta para escribir un recibo. Si bien la espalda del vendedor se convierte, el comprador lleva un billete de $ 20. Cuando el vendedor se da la vuelta, las manos del comprador a la pila de facturas, toma el recibo, y se va con la escultura. Entre el momento en que se comprob la seguridad (contando los billetes) y el acceso (el intercambio de la escultura de los proyectos de ley), cambi una condicin: Qu se comprob ya no es vlida cuando el objeto (es decir, la escultura) se accede. Una situacin similar puede ocurrir con los sistemas de computacin. Supongamos una solicitud de acceso a un archivo se presenta como una estructura de datos, con el nombre del archivo y el modo de acceso presentan en la estructura. Un ejemplo de tal estructura se muestra en la Figura 3-2.

Figura 3-2. Estructura de datos para acceso a archivos. La estructura de datos es esencialmente un "billete de trabajo", que requiere un sello de la autorizacin, una vez autorizado, se pone en una cola de cosas por hacer. Normalmente el mediador de control de acceso recibe la estructura de datos, determina si el acceso debe ser permitido, y, o bien rechaza el acceso y se detiene o permite el acceso y enva la estructura de datos para el controlador de archivo para su procesamiento.

Para llevar a cabo esta secuencia de autorizacin, el mediador de control de acceso tendra que buscar el nombre del archivo (y la identidad del usuario y cualquier otro parmetro relevante) en las tablas. El mediador puede comparar los nombres en la tabla al nombre del archivo en la estructura de datos para determinar si el acceso es la adecuada. Lo ms probable es que el mediador se copie el nombre de archivo en su propia rea de almacenamiento local y comparar desde all. Comparando de

la copia sale de la estructura de datos en el rea del usuario, bajo control del usuario. Es en este punto que el defecto mediacin incompleta puede ser explotado. Mientras que el mediador est comprobando derechos de acceso para el mi_archivo archivo, el usuario puede cambiar el nombre del archivo descriptor de your_file, el valor que se muestra en la Figura 3.3. Despus de haber ledo el billete de trabajo una vez, el mediador no se espera que vuelva a leer el billete antes de aprobarla, el mediador se apruebe el acceso y enviar el descriptor de ahora modificado para el controlador de archivo.

Figura 3-3. Modificado de datos. El problema se llama un tiempo de comprobar defecto tiempo de uso debido a que explota el retardo entre las dos veces. Es decir, entre el momento en que se comprob el acceso y el tiempo se utiliz el resultado de la comprobacin, se produjo un cambio, invalidando el resultado de la comprobacin. Implicacin de Seguridad La implicacin de la seguridad aqu es bastante claro: Comprobacin de una accin y realizar otra es un ejemplo de control de acceso eficaz. Se debe tener cuidado cuando un desfase o prdida de control se produce, asegurndose de que no hay manera de corromper los resultados de la verificacin durante ese intervalo. Afortunadamente, hay maneras de prevenir la explotacin del lapso de tiempo. Una forma es asegurar que los parmetros crticos no estn expuestas durante cualquier prdida de control. El software de control de acceso debe tener los datos de la solicitud hasta que la accin solicitada se ha completado. Otro modo es para asegurar la integridad de serie, es decir, para permitir ninguna interrupcin (prdida de control) durante la validacin. O la rutina de validacin inicial puede copiar datos desde el espacio del usuario para areaout de la rutina de los controles de los usuarios de validacin reachand realizan en la copia. Finalmente, la rutina de validacin puede sellar los datos de la solicitud con una suma de comprobacin para detectar modificacin. Las combinaciones de Fallas de programa no malintencionada Estas tres vulnerabilidades son lo suficientemente malo cuando cada uno se considera por s mismo. Pero quizs el peor aspecto de los tres defectos es que pueden ser utilizados juntos como un paso en un ataque de varios pasos. Un atacante no puede estar contento con causar un desbordamiento de bfer. En cambio, el atacante puede comenzar un ataque de tres puntas con un desbordamiento de bfer para desbaratar toda la ejecucin de cdigo arbitrario en la mquina. Al mismo tiempo, el atacante puede explotar un tiempo de comprobar error de tiempo de uso para agregar un nuevo ID de usuario en el sistema. El atacante inicia la sesin como el nuevo usuario y explota una falla de la mediacin incompletas para obtener estatus privilegiado, y as sucesivamente. El atacante inteligente utiliza los defectos como bloques de construccin comunes para construir un complejo ataque. Por esta razn, debemos conocer y proteger contra fallos ms simples. (Ver recuadro 3-3 para otros ejemplos de los efectos de los errores involuntarios.) Por desgracia, este tipo de fallas se han generalizado y peligroso. Como vemos en la siguiente seccin, de apariencia inocua fallas del programa pueden ser explotadas por atacantes maliciosos para plantar cdigo intencionadamente daina.

3,3. Los virus y otros cdigos maliciosos Por s mismos, los programas rara vez son las amenazas de seguridad. Los programas funcionan en los datos, la adopcin de medidas slo cuando los datos y cambios de estado se disparar. Gran parte del trabajo realizado por un programa es invisible a los usuarios que no puedan estar al tanto de cualquier actividad maliciosa. Por ejemplo, cundo fue la ltima vez que vio un poco? Sabe usted en qu forma un archivo de documento se almacena? Si conoces a un documento reside en algn lugar de un disco, puede encontrarlo? Se puede saber si un programa de juego hace nada, adems de su espera interaccin con usted? Qu archivos son modificados por un procesador de textos cuando se crea un documento? Qu programas se ejecutan al iniciar el ordenador o abrir una pgina web? La mayora de los usuarios no pueden responder a estas preguntas. Sin embargo, ya que los usuarios normalmente no ve los datos directamente al ordenador, un usuario malicioso puede hacer que los programas sirven como vehculos para acceder y modificar datos y otros programas. Echemos un vistazo a los posibles efectos de cdigos maliciosos y, a continuacin examinar en detalle varios tipos de programas que pueden ser utilizados para la interceptacin o modificacin de datos. Por qu preocuparse por el cdigo malicioso? Ninguno de nosotros, como lo inesperado, sobre todo en nuestros programas. El cdigo malicioso se comporta de manera inesperada, gracias a la intencin de un programador malicioso. Pensamos en el cdigo malicioso que acecha dentro de nuestro sistema: la totalidad o parte de un programa que se est ejecutando o incluso una parte desagradable de un programa separado que de alguna manera se une a otro programa (bueno). Cmo se produjera tal situacin? La ltima vez que instala un paquete de software importante, como un procesador de textos, un paquete estadstico, o un plug-in de Internet, ejecutar un comando, tpicamente llamado INSTALL o SETUP. A partir de ah, el programa de instalacin tom el control, la creacin de algunos archivos, escribiendo en otros archivos, borrar datos y archivos, y tal vez cambiar el nombre de unos pocos que se iba a cambiar. Unos minutos ms y un disco bastante pocas accede ms tarde, que tena un montn de nuevo cdigo y datos, todo listo para que usted con un mnimo de intervencin humana. Aparte de las descripciones generales de la caja, en los archivos de documentacin, o en las pginas web, que no tena absolutamente ninguna idea de exactamente qu "regalos" que haba recibido. Se esperaba que todo lo que recibi fue buena, y fue probablemente. La misma incertidumbre existe cuando usted, sin saberlo descarga una aplicacin, tales como un applet de Java o un control ActiveX, mientras se visualiza una pgina web. Miles o millones de bytes de los programas y datos se transfieren, y cientos de modificaciones se pueden hacer a los archivos existentes, todo ocurre sin su explcito consentimiento o conocimiento. Cdigo malicioso puede hacer mucho (dao) El cdigo malicioso puede hacer cualquier cosa de cualquier otro programa puede, como escribir un mensaje en una pantalla de ordenador, detener un programa en ejecucin, generando un sonido, o borrado de un archivo almacenado. U otros cdigos maliciosos pueden hacer nada en absoluto en estos momentos, puede ser plantada con permanecer en estado latente, sin ser detectados, hasta que algn evento desencadena el cdigo para actuar. El gatillo puede ser una hora o la fecha, un intervalo (por ejemplo, despus de 30 minutos), un evento (por ejemplo, cuando un programa en particular se ejecuta), una condicin (por ejemplo, cuando la comunicacin se produce en una interfaz de red), una contar (por ejemplo, la quinta vez que ocurre algo), una combinacin de stos, o de una

situacin aleatoria. De hecho, el cdigo malicioso pueden hacer cosas diferentes cada vez, o nada, la mayor parte del tiempo con algo dramtico en la ocasin. En general, el cdigo malicioso puede actuar con toda la previsibilidad de un nio de dos aos: Sabemos que, en general, lo que en dos aos lo hacemos, puede incluso saber lo que un determinado de dos aos de edad, hace a menudo en ciertas situaciones, pero dos aos de edad tienen una asombrosa capacidad de hacer lo inesperado. El cdigo malicioso se ejecuta bajo la autoridad del usuario. De este modo, el cdigo malicioso se puede tocar todo lo que el usuario puede tocar, y de la misma manera. Normalmente, los usuarios tienen control completo sobre su cdigo propio programa y los archivos de datos, ya que pueden leer, escribir, modificar, aadir, e incluso eliminarlos. Y bien que deberan. Sin embargo, el cdigo malicioso puede hacer lo mismo, sin el permiso del usuario o incluso el conocimiento. Cdigo malicioso se ha utilizado durante mucho tiempo La literatura popular y la prensa siguen poniendo de relieve los efectos de cdigos maliciosos, como si se tratara de un fenmeno relativamente reciente. No es. Cohen [COH84] a veces se le atribuye el descubrimiento de los virus, pero en realidad Cohen dio un nombre a un fenmeno conocido desde mucho antes. Por ejemplo, Thompson, en su conferencia de 1984 el Premio Turing, "Reflexiones sobre la Confianza Confianza" [THO84], el cdigo se describe que se puede pasar por un compilador. En esa conferencia, se refiere a un documento de la Fuerza Area anterior, la evaluacin de la seguridad Multics por Karger y Schell [KAR74, KAR02]. De hecho, las referencias al comportamiento del virus se remontan al menos hasta 1970. 1970 Ware estudio (a conocer pblicamente en 1979 [WAR79]) y el estudio de la planificacin de Anderson para la Fuerza Area de los EE.UU. [AND72] todava describen con precisin las amenazas, vulnerabilidades y fallos de los programas de seguridad, especialmente los intencionales. Qu hay de nuevo cdigo malicioso es el nmero de casos distintos y las copias que han aparecido y aparece la velocidad con la que el cdigo de explotacin. (Ver recuadro 3-4 en el tiempo de ataque.) As que el cdigo malicioso es an ms, y sus efectos son ms penetrantes. Es importante para nosotros para aprender cmo se ve y cmo funciona para que podamos tomar medidas para evitar hacer dao o por lo menos mediar sus efectos. Cmo puede el cdigo malicioso tomar el control de un sistema? Cmo se puede presentar en un sistema? Cmo difundir cdigo malicioso? Cmo se puede reconocer? Cmo puede ser detectado? Cmo puede ser detenido? Cmo se puede prevenir? Nos dirigimos a estas preguntas en las secciones siguientes. Tipo de cdigos maliciosos El cdigo malicioso o programa de pcaro es el nombre general para los efectos imprevistos o no deseados en los programas o partes de programas, causada por un agente de la intencin de dao. Esta definicin excluye los errores involuntarios, aunque tambin pueden tener un efecto negativo grave. Esta definicin excluye tambin la coincidencia, en el que dos programas benignos se combinan para ofrecer un efecto negativo. El agente es el autor del programa o de la persona que hace que su distribucin. Segn esta definicin, la mayora de los defectos encontrados en las inspecciones de software, revisiones, y las pruebas no estn considerados como cdigo malicioso, porque pensamos en ellos como no intencional. Sin embargo, tenga en cuenta al leer este captulo que las fallas no intencionales de hecho, puede invocar las mismas respuestas como maldad intencional; una causa benigna todava puede dar lugar a un efecto desastroso.

Es probable que se han visto afectados por un virus en un momento u otro, ya sea debido a que su equipo est infectado por uno o porque no podan acceder a un sistema infectado, mientras que sus administradores estaban limpiando el desorden un hecho. De hecho, el virus podra haber sido en realidad un gusano: La terminologa de cdigo malicioso se utiliza a veces imprecisa. Un virus es un programa que puede replicarse a s mismo y transmitir cdigo malicioso a otros programas modificndolos maliciosas. El trmino "virus" fue acuado por el programa afectado acta como un virus biolgico: Infecta otros sujetos sanos adhirindose al programa y, o bien destruir o convivir con ella. Dado que los virus son insidiosos, no podemos suponer que un programa de limpieza de ayer sigue siendo limpio en la actualidad. Adems, un buen programa puede ser modificado para incluir una copia del programa del virus, por lo que el programa infectado buen misma empieza a actuar como un virus, infectando a otros programas. La infeccin se propaga a un ritmo geomtrico, con el tiempo superando a un sistema de cmputo completo y se extienda a todos los dems sistemas conectados. Un virus puede ser transitoria o residente. Un virus tiene una vida transitoria que depende de la vida de su husped, el virus se ejecuta cuando el programa adjunto se ejecuta y termina cuando su programa adjunto termina. (Durante su ejecucin, el virus puede propagarse transitoria de su infeccin a otros programas.) Un virus residente se sita a s mismo en la memoria, entonces puede permanecer activa o activarse como un programa independiente, incluso despus de sus extremos el programa adjunto. Un caballo de Troya es el cdigo malicioso que, adems de su efecto principal, tiene un segundo efecto, malicioso no obvias. [1] Como ejemplo de un caballo de Troya equipo, tenga en cuenta una secuencia de comandos de inicio de sesin que solicita la identificacin de un usuario y una contrasea, pasa a la identificacin informacin sobre el resto del sistema para el procesamiento de inicio de sesin, pero tambin conserva una copia de la informacin para ms tarde, el uso malicioso. En este ejemplo, el usuario ve solamente el inicio de sesin que ocurre como se espera, por lo que no hay ninguna razn evidente para sospechar que cualquier otra accin tuvo lugar. [1] El nombre es una referencia a las leyendas griegas de la guerra de Troya. La leyenda cuenta cmo los griegos engaaron a los troyanos a romper su muro de defensa para tener un caballo de madera, llena de los ms valientes de los soldados griegos, en su ciudadela. En la noche, los soldados descendieron y seas a sus tropas que la forma en la era claro ahora, y Troy fue capturado. Una bomba lgica es un tipo de cdigo malicioso que "detona" o se apaga cuando se produce una condicin especificada. Una bomba de tiempo es una bomba lgica, cuyo gatillo es una hora o fecha. Una trampilla o puerta trasera es una caracterstica de un programa mediante el cual una persona puede tener acceso al programa que no sea por la llamada obvia y directa, tal vez con privilegios especiales. Por ejemplo, un programa de cajero automtico puede permitir a nadie entrar en el nmero 990099 en el teclado para procesar el registro de las transacciones de todo el mundo en esa mquina. En este ejemplo, la trampa podra ser intencional, con fines de mantenimiento, o podra ser una manera ilcita, con el ejecutor de borrar cualquier registro de un crimen. Un gusano es un programa que se propaga copias de s mismo a travs de una red. Conmocin y

Hupp [SHO82] son aparentemente el primero en describir un gusano, que, curiosamente, fue con fines maliciosas. La principal diferencia entre un gusano y un virus es un gusano que se opera a travs de las redes, y un virus puede propagarse a travs de cualquier medio (pero por lo general utiliza copiados los archivos de programa o de datos). Adems, el gusano se propaga copias de s mismo como un programa independiente, mientras que el virus se propaga copias de s mismo como un programa que se conecta o incrusta en otros programas. White et al. [WHI89] tambin definen un conejo como un virus o gusano que se auto-replica sin lmite, con la intencin de agotar un recurso de computacin. Un conejo podra crear copias de s mismo y almacenarlos en el disco en un esfuerzo para llenar completamente el disco, por ejemplo

3,4. Cdigo malicioso dirigido Hasta ahora, hemos visto cdigo annimo escrito a afectar a los usuarios y las mquinas de forma indiscriminada. Otra clase de cdigo malicioso est escrito para un sistema en particular, para una aplicacin particular, y para un propsito particular. Muchas de las tcnicas de los creadores de virus de aplicar, pero tambin hay algunos nuevos. Bradbury [BRA06] mira el cambio en el tiempo en los objetivos y las competencias de los autores de cdigos maliciosos. trampillas Una trampilla es un punto de entrada de indocumentados a un mdulo. Los desarrolladores insertar una trampilla en el desarrollo de cdigo, tal vez para probar el mdulo, para proporcionar "ganchos" por el cual se conectan las futuras modificaciones o mejoras, o para permitir el acceso si el mdulo debe fallar en el futuro. Adems de estos usos legtimos, trampillas puede permitir que un programador acceso a un programa una vez que se coloca en la produccin. Ejemplos de trampillas Dado que los sistemas informticos son estructuras complejas, por lo general los programadores desarrollar y probar los sistemas en un metdico, de forma organizada y modular, aprovechando la forma en que se compone el sistema de mdulos o componentes. A menudo, los programadores primera prueba de cada pequeo componente del sistema separado de los otros componentes, en un paso llamado unidad de pruebas, para asegurar que el componente funciona correctamente por s mismo. Luego, los desarrolladores de componentes de la prueba juntos durante las pruebas de integracin, para ver cmo funcionan, ya que enviar mensajes y los datos de uno a otro. En lugar de pegar todos los componentes juntos en un "big bang", enfoque, los grupos de probadores lgicos del grupo de unos pocos componentes, y cada uno de racimo se ha probado de una manera que permite a los probadores para controlar y entender lo que puede hacer que un componente o su interfaz no. (Para un anlisis ms detallado de las pruebas, consulte Pfleeger y Atlee [PFL06a].)

3,5. Controles contra las amenazas de programa El panorama que acabamos de describir no es agradable. Hay muchas maneras de un programa puede fallar y muchas maneras de convertir las fallas subyacentes en los fallos de seguridad. Por supuesto, es mejor centrarse en la prevencin que la cura, cmo podemos usar los controles durante el developmentthe software de la especificacin, diseo, escritura y anlisis de la programto encontrar y eliminar los tipos de exposiciones que hemos discutido? La disciplina de la ingeniera de software se ocupa de esta cuestin ms a nivel mundial, la elaboracin de criterios para garantizar la calidad del software. En este libro, se proporciona un resumen de varias tcnicas que pueden resultar tiles en la bsqueda y correccin de fallas de seguridad. Para mayor profundidad, nos remitimos a los textos como Pfleeger et al. [PFL01] y Pfleeger y Atlee [PFL06a]. En esta seccin se analizan tres tipos de controles: de desarrollo, sistema operativo y administrativo. Se discute cada uno de ellos. Controles de desarrollo Muchos controles se pueden aplicar durante el desarrollo de software para descubrir y solucionar problemas. As que vamos a empezar por examinar la naturaleza del desarrollo en s mismo, para ver qu tareas estn involucrados en la especificacin, el software de diseo, construccin y prueba. La naturaleza del desarrollo de software El desarrollo de software a menudo se considera un esfuerzo solitario, un programador se sienta con una especificacin o diseo y muele lnea tras lnea de cdigo. Pero, en realidad, el desarrollo de software es un esfuerzo de colaboracin, la participacin de las personas con habilidades diferentes que combinan su experiencia para producir un producto de trabajo. El desarrollo requiere de personas que pueden especificar el sistema, mediante la captura de los requisitos y la construccin de un modelo de cmo debera funcionar el sistema desde el punto de vista del usuario disear el sistema, proponiendo una solucin al problema descrito por los requisitos y la construccin de un modelo de la solucin implementar el sistema, utilizando el diseo como un anteproyecto para la construccin de una solucin de trabajo probar el sistema, para asegurar que cumple con los requisitos y aplica la solucin como se pide en el diseo revisar el sistema en varias etapas, para asegurarse de que los productos finales son consistentes con los modelos de especificacin y diseo documentar el sistema, por lo que los usuarios puedan recibir capacitacin y apoyo administrar el sistema, para estimar qu recursos sern necesarios para el desarrollo y para hacer un seguimiento cuando el sistema se llevar a cabo

problemas de mantenimiento del sistema, el seguimiento de encontrar, los cambios necesarios, y los cambios realizados y la evaluacin de sus efectos en la calidad general y la funcionalidad Una persona puede hacer todas estas cosas. Pero ms a menudo que no, un equipo de desarrolladores trabaja en conjunto para realizar estas tareas. A veces un miembro del equipo hace ms de una actividad, una de las pruebas puede tomar parte en una revisin de los requisitos, por ejemplo, o un ejecutor puede escribir documentacin. Cada equipo es diferente, y la dinmica del equipo juega un papel importante en el xito del equipo. Tenga en cuenta los tipos de ataques sofisticados que se describen en la seccin anterior. Balfanz [BAL04] nos recuerda que debemos disear sistemas que sean a la vez seguro y utilizable, recomendando los siguientes puntos: No Las Cuidado Mantener Pensar se puede herramientas con a localmente, las los adaptar no la seguridad son capas clientes actuar utilizable. soluciones. superiores. satisfechos. localmente.

Podemos examinar los productos y procesos para ver cmo tanto contribuyen a la calidad y en particular a la seguridad como un aspecto de la calidad. Comencemos con el producto, para tener una idea de cmo reconocer a software de alta calidad segura. La modularidad, encapsulacin y ocultamiento de informacin Cdigo por lo general tiene una larga vida til y se ha mejorado con el tiempo, cambian las necesidades y los fallos se encuentren y resuelvan. Por esta razn, un principio clave de la ingeniera del software es crear un diseo o el cdigo en pequeas unidades autnomas, llamadas componentes o mdulos, cuando un sistema se escribe de esta manera, decimos que es modular. La modularidad ofrece ventajas para el desarrollo del programa en general y la seguridad en particular. Si un componente est aislado de los efectos de otros componentes, entonces es ms fcil de rastrear un problema para el fallo que caus y para limitar el dao que el fallo cause. Tambin es ms fcil de mantener el sistema, ya que los cambios a un componente aislado no afectan a otros componentes. Y es ms fcil ver dnde puede estar la vulnerabilidad si el componente es aislado. A esto le llamamos la encapsulacin de aislamiento. El ocultamiento de informacin es otra caracterstica de software modular. Cuando la informacin se oculta, se esconde cada componente de su aplicacin concreta, o alguna otra decisin de diseo de los dems. As, cuando se necesita un cambio, el diseo general puede permanecer intacta mientras que slo los cambios necesarios se hacen a los componentes particulares