Quiz: Analyse avancée de la sécurité et preuve de programmes — 12 perguntas

1. Quel est le rôle principal de l'analyse de liveness dans l'optimisation des programmes ?

A. Générer automatiquement des tests unitaires pour vérifier le comportement du programme

B. Détecter les erreurs de syntaxe dans le code source avant la compilation

C. Identifier le code mort pour supprimer les instructions inutiles sans modifier le comportement observable

D. Calculer la complexité temporelle d'une boucle pour améliorer ses performances

Answer: (C)

Explicação

L'analyse de liveness rétrograde identifie précisément le code mort, notamment les affectations inutiles, afin d'optimiser le programme en supprimant ces instructions sans impacter son comportement observable. À revoir : Analyse de liveness et élimination de code mort (DCE). Appui du cours : « L'analyse de liveness rétrograde permet d'identifier précisément le code mort, notamment les affectations inutiles, pour optimiser le programme en supprimant ces instructions sans impact sur le comportement observable. »

2. En quoi l'analyse d'initialisation en avant diffère-t-elle de l'analyse en arrière en Java ?

A. L'analyse en avant calcule les variables non initialisées après une affectation, l'analyse en arrière vérifie l'initialisation avant usage

B. L'analyse en avant ajoute un `obs(T)` implicite avant chaque affectation, l'analyse en arrière vérifie les variables utilisées dans une expression

C. L'analyse en avant ignore les variables dans les conditions, l'analyse en arrière analyse uniquement les variables locales

D. L'analyse en avant vérifie que les variables sont initialisées avant utilisation, tandis que l'analyse en arrière identifie les variables bien initialisées avant une affectation

Answer: (D)

Explicação

L'analyse en avant vérifie que toutes les variables utilisées dans une expression sont initialisées avant l'affectation, tandis que l'analyse en arrière ajoute un `obs(T)` implicite avant chaque affectation pour déterminer les variables bien initialisées. Ces définitions montrent clairement leur différence fonctionnelle respective. À revoir : Analyse d'initialisation des variables en Java et méthodes en avant et en arrière. Appui du cours : « L'analyse en arrière ajoute un `obs(T)` implicite avant chaque affectation pour déterminer les variables bien initialisées comme celles non live en entrée. L'analyse en avant vérifie que toutes les variables utilisées dans une expression sont initialisées… »

3. Qu'est-ce que l'état abstrait A dans l'analyse avancée DCE avec graphes de contrôle de flux ?

A. Une liste ordonnée des instructions exécutées dans le programme

B. Un ensemble de variables mortes à chaque point de contrôle dans le programme

C. Une fonction associant à chaque point de contrôle soit un ensemble de variables live-in, soit un goto vers un autre point de contrôle, formant une structure union-find

D. Un graphe représentant uniquement les branchements conditionnels du programme

Answer: (C)

Explicação

L'état abstrait A est défini comme une fonction qui, pour chaque point de contrôle PCk, associe soit un ensemble L (live-in), soit une structure G(p') représentant un goto vers un autre point de contrôle, formant ainsi une structure union-find pour gérer la connectivité et les cycles dans le CFG. À revoir : Analyse avancée DCE avec graphes de contrôle de flux (CFG) et itérations. Appui du cours : « État abstrait A : C’est une fonction qui, pour chaque point de contrôle PCk, associe soit à un ensemble L (live-in), soit à une structure G(p') représentant un goto vers un autre point de contrôle p'. La notation G*A désigne la fermeture transitive de cette… »

4. Que signifie l'assertion `p == q` dans l'interprétation abstraite du domaine des pointeurs ?

A. Que p et q pointent nécessairement vers la même adresse mémoire

B. Que les valeurs nullité de p et q sont compatibles, sans garantir qu'ils pointent vers la même adresse

C. Que p et q sont tous deux NULL avec certitude

D. Que p est non NULL et q est NULL

Answer: (B)

Explicação

L'assertion `p == q` impose uniquement que les valeurs nullité de p et q soient compatibles, en intersectant leurs couples (Z, N), mais elle ne garantit pas qu'ils pointent vers la même adresse, comme indiqué dans le passage. À revoir : Interprétation abstraite du domaine des pointeurs et gestion des assertions nullité. Appui du cours : « L'assertion `p == q` impose que les valeurs nullité de p et q soient compatibles, en intersectant leurs couples (Z, N), sans garantir qu'ils pointent vers la même adresse. »

5. En quoi les clauses `requires` et `ensures` diffèrent-elles dans les spécifications ACSL ?

A. `requires` et `ensures` ont la même fonction dans les spécifications ACSL

B. `requires` exprime les préconditions, tandis que `ensures` exprime les postconditions

C. `requires` indique les variables modifiées, tandis que `ensures` exprime les conditions d'entrée

D. `requires` décrit les conditions après exécution, tandis que `ensures` décrit les conditions avant

Answer: (B)

Explicação

La source précise que `requires` est utilisé pour les préconditions (conditions avant exécution) et `ensures` pour les postconditions (conditions après exécution), ce qui explique leur différence fonctionnelle. À revoir : Preuve de programmes avec WP et spécifications ACSL en C. Appui du cours : « Les spécifications ACSL utilisent `requires` pour les préconditions, `ensures` pour les postconditions, et `assigns` pour indiquer les variables modifiées. »

6. Comment appliquer efficacement les bonnes pratiques pour prévenir les débordements et erreurs d'allocation en langage C ?

A. Utiliser uniquement des types signés pour toutes les variables et ignorer les avertissements du compilateur

B. Éviter l'utilisation de types non signés et ne pas activer d'options de compilation spécifiques pour garder la flexibilité

C. Utiliser le type `size_t` pour les tailles et effectuer des tests explicites sur les limites, tout en activant les options de compilation comme `-Wall -Wextra -Werror` et `-fstack-protector`

D. Éviter les tests de limites pour améliorer la performance et ne pas modifier les options de compilation

Answer: (C)

Explicação

Le source indique clairement que l'utilisation de `size_t` pour les tailles, combinée à des tests explicites sur les limites, évite les débordements. De plus, activer des options de compilation comme `-Wall -Wextra -Werror` et `-fstack-protector` renforce la prévention des vulnérabilités liées aux débordements. À revoir : Vulnérabilités classiques en C : débordements, comportements indéfinis et corrections. Appui du cours : « - L'utilisation de `size_t` pour les tailles et de tests explicites sur les limites permet d'éviter les débordements et erreurs d'allocation. - Les options de compilation telles que `-Wall -Wextra -Werror`, `-fstack-protector`, `-ftrapv` et… »

7. Quel est le rôle principal de la normalisation et de la vérification des chemins dans la protection contre une attaque de type path traversal ?

A. Éviter l'insertion d'en-têtes SMTP non désirés dans les messages

B. Bloquer l'injection de code JavaScript dans les pages web

C. Empêcher l'exécution de commandes système arbitraires

D. Empêcher l'accès à des fichiers en dehors du répertoire autorisé

Answer: (D)

Explicação

La normalisation et la vérification des chemins servent à s'assurer que les chemins d'accès restent dans le répertoire autorisé, empêchant ainsi l'accès à des fichiers en dehors de ce répertoire, ce qui est la fonction clé pour protéger contre les attaques de type path traversal. À revoir : Principales injections (commande, SQL, XSS, SMTP, path traversal) et leurs protections. Appui du cours : « - **Path traversal** : Vulnérabilité permettant d'accéder à des fichiers en dehors du répertoire prévu en utilisant des chemins relatifs ou absolus malveillants, corrigée par la normalisation et la vérification que les chemins restent dans le répertoire… »

8. Quelle est la conséquence directe d'un débordement de buffer sur la pile ?

A. Rendre la mémoire non exécutable pour empêcher l'injection de code

B. Écraser l'adresse de retour et rediriger l'exécution vers un shellcode

C. Randomiser les adresses mémoire pour empêcher la prédiction

D. Conserver une copie protégée des adresses de retour pour détecter les modifications

Answer: (B)

Explicação

Le débordement de buffer sur la pile permet d'écraser l'adresse de retour, ce qui conduit à rediriger l'exécution vers un shellcode, comme indiqué dans la source. À revoir : Attaques par débordement de buffer et protections de la pile (canari, ASLR, DEP, shadow stack). Appui du cours : « Un débordement de buffer sur la pile permet d'écraser l'adresse de retour et de rediriger l'exécution vers un shellcode. »

9. Comment doit-on appliquer le principe de moindre privilège dans un programme Python qui gère une exception OSError ?

A. Augmenter les privilèges temporairement dans le bloc d'exception OSError

B. Abaisser les privilèges dans tous les chemins d'exécution, y compris dans le bloc d'exception OSError

C. Abaisser les privilèges uniquement si aucune exception n'est levée

D. Ignorer la gestion des privilèges dans le bloc d'exception OSError

Answer: (B)

Explicação

Le texte précise qu'il est essentiel d'abaisser les privilèges dans tous les chemins d'exécution, y compris lors d'une exception OSError, ce que l'exemple Python illustre clairement. À revoir : Use-after-free, variables non initialisées et principe de moindre privilège. Appui du cours : « **Except OSError** : Un bloc d'exception en Python qui capture les erreurs liées aux opérations système, où il est essentiel d'abaisser les privilèges dans tous les chemins d'exécution, y compris lors de cette exception. »

10. Qu'est-ce que le plugin EVA dans Frama-C ?

A. Un plugin qui réalise une analyse statique automatique par interprétation abstraite, détectant des erreurs potentielles avec des alarmes colorées

B. Un plugin qui produit des obligations de preuve déductive avec des couleurs bleu, vert et orange

C. Un outil de Frama-C qui insère automatiquement des assertions d'absence de dépassement d'entier

D. Un module qui découpe les obligations de preuve pour localiser précisément les échecs

Answer: (A)

Explicação

Le plugin EVA est décrit comme un plugin de Frama-C réalisant une analyse statique automatique par interprétation abstraite, avec détection d'erreurs potentielles et alarmes colorées. Les autres options décrivent des fonctions du plugin WP ou de ses options, pas d'EVA. À revoir : Utilisation des plugins Frama-C EVA et WP pour analyse statique et preuve. Appui du cours : « Plugin EVA (interprétation abstraite) : Un plugin de Frama-C qui réalise une analyse statique automatique par interprétation abstraite, détectant des erreurs potentielles avec des alarmes colorées en vert, orange et rouge, mais pouvant produire des fausses… »

11. En quelle année est prévu l'examen portant sur les exercices types, pièges fréquents et bonnes pratiques en sécurité et preuve de programmes ?

A. 2026

B. 2023

C. 2024

D. 2025

Answer: (D)

Explicação

Le titre indique clairement que les points clés concernent l'examen 2025, ce qui fixe l'année prévue pour cet examen. À revoir : Points clés pour l'examen 2025 : exercices types, pièges fréquents et bonnes pratiques. Appui du cours : « ## 📖 11. Points clés pour l'examen 2025 : exercices types, pièges fréquents et bonnes pratiques »

12. Que signifie la méthode "Relancer jusqu'à tout vert" dans le contexte de Frama-C WP ?

A. Supprimer toutes les annotations pour simplifier la preuve

B. Exécuter plusieurs cycles d'annotation, de vérification et de correction jusqu'à validation complète des preuves

C. Lancer uniquement une vérification statique sans correction itérative

D. Compiler le code une seule fois avec tous les warnings activés

Answer: (B)

Explicação

La méthode "Relancer jusqu'à tout vert" consiste à répéter itérativement annotation, vérification et correction dans Frama-C WP jusqu'à ce que toutes les obligations de preuve soient validées sans échec, comme précisé dans la source. À revoir : TP sécurité C et WP Frama-C : exercices pratiques et méthodologie. Appui du cours : « - **Relancer jusqu'à tout vert** : Une méthode itérative consistant à exécuter plusieurs cycles d'annotation, de vérification et de correction dans Frama-C WP jusqu'à ce que toutes les obligations de preuve soient validées sans échec. »