Return-Oriented Programming
Qu'est-ce que Return-Oriented Programming ?
Return-Oriented ProgrammingLe ROP est une technique d'exploitation par reutilisation de code qui enchaine de courtes sequences terminees par RET pour executer un calcul arbitraire sans injecter de code.
Hovav Shacham a introduit le ROP dans son article de 2007 « The Geometry of Innocent Flesh on the Bone », en montrant que le return-into-libc pouvait être généralisé jusqu'à un calcul Turing-complet et ainsi vaincre DEP/W^X. L'attaquant corrompt la pile et y écrit une chaîne d'adresses, chacune pointant vers un gadget court — quelques instructions se terminant par RET. Après l'exécution de chaque gadget, RET dépile l'adresse suivante : le contrôle circule donc à travers des octets exécutables déjà présents (libc, le programme, les bibliothèques), sans code injecté que DEP pourrait intercepter.
Comme chaque adresse de gadget est absolue, le ROP suppose de connaître l'emplacement du code en mémoire, précisément ce que l'ASLR randomise ; les exploits réels l'associent donc à une fuite d'information. Les variantes généralisent la primitive : JOP (sauts) et COP (appels) enchaînent des sauts/appels indirects au lieu de retours, et SROP (sigreturn) détourne la restauration du cadre de signal du noyau pour fixer tous les registres d'un coup. Le Blind ROP (Bittau et al., 2014) construit une chaîne contre un service distant sans binaire, en observant les plantages.
Le ROP est la raison principale de toute une génération de contre-mesures. Les défenses visent l'une de trois surfaces : disponibilité des gadgets, intégrité du flux de contrôle ou sûreté mémoire à la source. Intel CET (depuis Tiger Lake, 2020) impose une shadow stack matérielle qui détecte les adresses de retour altérées et un Indirect Branch Tracking (endbr64) contre JOP/COP ; ARM propose Pointer Authentication et BTI. Les langages à mémoire sûre comme Rust éliminent le bug de corruption qui amorce la chaîne.
flowchart TD A["Bug de corruption memoire<br/>depassement de pile"] --> B["Ecrase l'adresse de retour"] B --> C["La pile contient desormais<br/>une chaine de gadgets"] C --> G1["Gadget 1: pop rdi, ret"] G1 --> G2["Gadget 2: pop rsi, ret"] G2 --> G3["Gadget 3: syscall, ret"] G3 --> X["execve /bin/sh"] D1["DEP: pile non executable"] -. contourne par reutilisation .-> C D2["ASLR"] -. requiert une fuite .-> C D3["Shadow stack Intel CET"] -. bloque un RET invalide .-> G1
● Exemples
- 01
Exploit enchainant des gadgets pop-rdi/syscall de la glibc pour appeler execve("/bin/sh").
- 02
Exploit noyau combinant fuite KASLR et ROP vers commit_creds(prepare_kernel_cred(0)).
● Questions fréquentes
Qu'est-ce que Return-Oriented Programming ?
Le ROP est une technique d'exploitation par reutilisation de code qui enchaine de courtes sequences terminees par RET pour executer un calcul arbitraire sans injecter de code. Cette notion relève de la catégorie Sécurité applicative en cybersécurité.
Que signifie Return-Oriented Programming ?
Le ROP est une technique d'exploitation par reutilisation de code qui enchaine de courtes sequences terminees par RET pour executer un calcul arbitraire sans injecter de code.
Comment se défendre contre Return-Oriented Programming ?
Les défenses contre Return-Oriented Programming combinent habituellement des contrôles techniques et des pratiques opérationnelles, comme détaillé dans la définition ci-dessus.
Quels sont les autres noms de Return-Oriented Programming ?
Noms alternatifs courants : ROP, Attaque par reutilisation de code, Return-to-libc.