¿Qué tan peligroso es acceder a una matriz fuera de los límites?

¿Qué tan peligroso es acceder a una matriz fuera de sus límites (en C)? A veces puede suceder que leo desde fuera de la matriz (ahora entiendo que luego accedo a la memoria utilizada por otras partes de mi programa o incluso más allá) o estoy tratando de establecer un valor en un índice fuera de la matriz. El programa a veces falla, pero a veces simplemente se ejecuta, dando solo resultados inesperados.

Ahora lo que me gustaría saber es, ¿qué tan peligroso es esto realmente? Si daña mi programa, no es tan malo. Si, por otro lado, rompe algo fuera de mi programa, porque de alguna manera logré acceder a una memoria totalmente ajena, entonces es muy malo, me imagino. Leí mucho ‘cualquier cosa puede pasar’, ‘la segmentación podría ser el problema menos grave’, ‘su disco duro podría volverse rosa y los unicornios podrían estar cantando debajo de su ventana’, lo cual está muy bien, pero ¿cuál es realmente el peligro?

Mis preguntas:

1. ¿Puede la lectura de valores desde fuera de la matriz dañar algo además de mi programa? Me imagino que solo mirar las cosas no cambia nada, o ¿cambiaría, por ejemplo, el atributo ‘última vez que se abrió’ de un archivo al que accedí?
2. ¿La configuración de valores fuera de la matriz puede dañar algo además de mi programa? De esta pregunta de desbordamiento de pila, deduzco que es posible acceder a cualquier ubicación de memoria, que no hay garantía de seguridad.
3. Ahora ejecuto mis pequeños programas desde XCode. ¿Proporciona eso alguna protección adicional alrededor de mi programa donde no puede llegar fuera de su propia memoria? ¿Puede dañar XCode?
4. ¿Alguna recomendación sobre cómo ejecutar mi código intrínsecamente defectuoso de forma segura?

Uso OSX 10.7, Xcode 4.6.

Usted escribe:

Leí mucho de ‘cualquier cosa puede pasar’, ‘la segmentación podría ser el problema menos grave’, ‘su disco duro podría volverse rosa y los unicornios podrían estar cantando debajo de su ventana’, todo lo cual está bien, pero ¿cuál es realmente el peligro?

Pongámoslo de esa manera: carga un arma. Apúntalo fuera de la ventana sin ningún objetivo en particular y dispara. ¿Cuál es el peligro?

El tema es que no lo sabes. Si su código sobrescribe algo que bloquea su programa, está bien porque lo detendrá en un estado definido. Sin embargo, si no falla, los problemas comienzan a surgir. ¿Qué recursos están bajo el control de su programa y qué podría hacerles? Conozco al menos un problema importante que fue causado por tal desbordamiento. El problema estaba en una función de estadísticas aparentemente sin sentido que estropeó una tabla de conversión no relacionada para una base de datos de producción. El resultado fue algo muy limpieza costosa después. En realidad, hubiera sido mucho más barato y más fácil de manejar si este problema hubiera formateado los discos duros … en otras palabras: los unicornios rosas podrían ser su menor problema.

La idea de que tu sistema operativo te protegerá es optimista. Si es posible, trate de evitar escribir fuera de los límites.

No verificar los límites puede provocar efectos secundarios desagradables, incluidos agujeros de seguridad. Uno de los feos es ejecución de código arbitrario. En un ejemplo clásico: si tiene una matriz de tamaño fijo y usa strcpy() para colocar una cadena proporcionada por el usuario allí, el usuario puede proporcionarle una cadena que desborda el búfer y sobrescribe otras ubicaciones de memoria, incluida la dirección del código donde la CPU debe regresar cuando finaliza su función.

Lo que significa que su usuario puede enviarle una cadena que hará que su programa esencialmente llame exec("/bin/sh")que lo convertirá en shell, ejecutando todo lo que quiera en su sistema, incluida la recopilación de todos sus datos y convirtiendo su máquina en un nodo de botnet.

Ver Rompiendo la pila por diversión y ganancias para obtener detalles sobre cómo se puede hacer esto.

NSArrayA los s en Objective-C se les asigna un bloque específico de memoria. Exceder los límites de la matriz significa que estaría accediendo a una memoria que no está asignada a la matriz. Esto significa:

1. Esta memoria puede tener cualquier valor. No hay forma de saber si los datos son válidos según su tipo de datos.
2. Esta memoria puede contener información confidencial, como claves privadas u otras credenciales de usuario.
3. La dirección de memoria puede no ser válida o estar protegida.
4. La memoria puede tener un valor cambiante porque otro programa o subproceso está accediendo a ella.
5. Otras cosas utilizan el espacio de direcciones de la memoria, como los puertos asignados a la memoria.
6. Escribir datos en una dirección de memoria desconocida puede bloquear su programa, sobrescribir el espacio de memoria del sistema operativo y, en general, hacer que el sol implosione.

Desde el aspecto de su programa, siempre desea saber cuándo su código excede los límites de una matriz. Esto puede provocar que se devuelvan valores desconocidos, lo que provocaría que su aplicación se bloqueara o proporcionara datos no válidos.

Si alguna vez realiza programación a nivel de sistemas o programación de sistemas integrados, pueden suceder cosas muy malas si escribe en ubicaciones de memoria aleatorias. Los sistemas más antiguos y muchos microcontroladores usan E/S mapeada en memoria, por lo que escribir en una ubicación de memoria que se asigna a un registro periférico puede causar estragos, especialmente si se hace de forma asíncrona.

Un ejemplo es la programación de memoria flash. El modo de programación en los chips de memoria se habilita escribiendo una secuencia específica de valores en ubicaciones específicas dentro del rango de direcciones del chip. Si otro proceso escribiera en cualquier otra ubicación en el chip mientras eso sucede, causaría que el ciclo de programación fallara.

En algunos casos, el hardware ajustará las direcciones (los bits/bytes más significativos de la dirección se ignoran), por lo que escribir en una dirección más allá del final del espacio de direcciones físicas dará como resultado que los datos se escriban justo en el medio.

Y finalmente, las CPU más antiguas como la MC68000 pueden bloquearse hasta el punto de que solo un reinicio de hardware puede hacer que vuelvan a funcionar. No he trabajado en ellos durante un par de décadas, pero creo que cuando se encontró con un error de bus (memoria inexistente) al intentar manejar una excepción, simplemente se detuvo hasta que se afirmó el reinicio del hardware.

Mi mayor recomendación es un complemento descarado para un producto, pero no tengo ningún interés personal en él y no estoy afiliado a ellos de ninguna manera, pero basado en un par de décadas de programación C y sistemas integrados donde la confiabilidad era crítica, la PC de Gimpel Lint no solo detectará ese tipo de errores, sino que lo convertirá en un mejor programador de C/C++ al constantemente insistiéndote en los malos hábitos.

También recomendaría leer el estándar de codificación MISRA C, si puede obtener una copia de alguien. No he visto ninguno reciente, pero en los viejos tiempos daban una buena explicación de por qué deberías/no deberías hacer las cosas que cubren.

No sé tú, pero aproximadamente la segunda o tercera vez que recibo un volcado de memoria o un bloqueo de cualquier aplicación, mi opinión sobre la compañía que la produjo se reduce a la mitad. La 4ª o 5ª vez y lo que sea que sea el paquete se convierte en estantería y conduzco una estaca de madera a través del centro del paquete/disco en el que vino solo para asegurarme de que nunca vuelva a atormentarme.