Règle
Empêcher commun segmentation de segmentation modèles.
Pointeur pointeur déréférences, débordements débordements de mémoire tampon,
et erreurs de type "use-after-free erreurs provoquent plantages et sécurité sécurité.
Langues prises en charge : C/C++Introduction
Les erreurs de segmentation restent la source la plus courante de plantages et de vulnérabilités exploitables dans les applications C/C++. Ces violations d'accès mémoire se produisent lorsque le code tente de lire ou d'écrire dans une mémoire qu'il ne possède pas, généralement via des déréférencements de pointeurs nuls, des dépassements de tampon (buffer overflows), des pointeurs pendants (dangling pointers) ou l'accès à de la mémoire libérée. Une seule segfault peut faire tomber des serveurs de production, mais pire encore, de nombreux schémas de segfault sont exploitables pour l'exécution de code arbitraire.
Pourquoi c'est important
Implications de sécurité : Les dépassements de tampon (buffer overflows) et les vulnérabilités de type use-after-free sont à la base de la plupart des exploits de corruption de mémoire. Les attaquants les exploitent pour écraser les adresses de retour, injecter du shellcode ou manipuler le flux de contrôle du programme. La vulnérabilité Heartbleed de 2014 était une lecture excessive de tampon (buffer over-read). Les exploits modernes ciblent toujours ces schémas car ils offrent un accès direct à la mémoire aux attaquants.
Stabilité du système : Les erreurs de segmentation font planter votre application immédiatement, sans dégradation progressive. Dans les systèmes de production, cela signifie des requêtes abandonnées, des transactions interrompues et un état corrompu. Contrairement aux exceptions de langages de haut niveau qui peuvent être interceptées, les segfaults terminent le processus, nécessitant des procédures de redémarrage et de récupération.Expansion de la surface d'attaque : Chaque déréférencement de pointeur non vérifié, strcpy, memcpy, ou l'accès à un tableau sans vérification des limites, constitue un point d'entrée potentiel pour l'exploitation. Les attaquants enchaînent ces vulnérabilités, utilisant l'une pour corrompre la mémoire de manière à permettre l'exploitation d'une autre.
Exemples de code
❌ Non conforme :
void process_user_data(const char* input) {
char buffer[64];
strcpy(buffer, input); // No bounds checking
char* token = strtok(buffer, ",");
while (token != NULL) {
process_token(token);
token = strtok(NULL, ",");
}
}
int* get_config_value(int key) {
int* value = (int*)malloc(sizeof(int));
*value = lookup_config(key);
return value; // Caller must free, but no documentation
}Pourquoi c'est dangereux : Le strcpy() L'appel provoque un débordement de tampon si l'entrée dépasse 63 octets, permettant aux attaquants d'écraser la mémoire de la pile. Le get_config_value() La fonction provoque des fuites de mémoire à chaque appel et crée un risque de pointeur orphelin si les appelants libèrent la mémoire alors que d'autres parties du code y font encore référence.
✅ Conforme :
void process_user_data(const char* input) {
if (!input) return;
size_t input_len = strlen(input);
char* buffer = malloc(input_len + 1);
if (!buffer) return;
strncpy(buffer, input, input_len);
buffer[input_len] = '\0';
char* token = strtok(buffer, ",");
while (token != NULL) {
process_token(token);
token = strtok(NULL, ",");
}
free(buffer);
}
int get_config_value(int key, int* out_value) {
if (!out_value) return -1;
*out_value = lookup_config(key);
return 0; // Caller owns out_value memory
}Pourquoi c'est sûr : Les vérifications de pointeurs nuls préviennent les crashs de déréférencement. L'allocation dynamique élimine les limites de taille de tampon fixes. La copie avec vérification des limites avec strncpy() empêche le débordement. Sémantique de propriété claire dans get_config_value() où l'appelant fournit la mémoire, évitant ainsi la confusion d'allocation et les fuites.
Conclusion
La sécurité de la mémoire en C et C++ exige une programmation défensive à chaque opération de pointeur et allocation de mémoire. Les erreurs de segmentation ne sont pas inévitables ; elles peuvent être évitées grâce à des vérifications de nullité cohérentes, une validation des limites et des modèles clairs de propriété de la mémoire. Détecter ces schémas avant la production prévient à la fois les plantages et les vulnérabilités exploitables.
.avif)
