diff --git a/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md b/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md index 42092bba4..aed6c05e2 100644 --- a/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md +++ b/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md @@ -74,7 +74,7 @@ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space # Disable ASLR ``` ## Exploit -Експлойт використовує bof, щоб повернутися до виклику **`sigreturn`** та підготувати стек для виклику **`execve`** з вказівником на `/bin/sh`. +Експлойт використовує bof, щоб повернутися до виклику **`sigreturn`** і підготувати стек для виклику **`execve`** з вказівником на `/bin/sh`. ```python from pwn import * @@ -136,7 +136,7 @@ return 0;
-Отже, якщо буде витік, можна **використати цю адресу для доступу до `sigreturn`**, якщо бінарний файл не завантажує його: +Отже, якщо буде витік, можна **використати цю адресу для доступу до `sigreturn`**, якщо бінар не завантажує його: ```python from pwn import * @@ -181,7 +181,7 @@ p.interactive() ## Автоматичне знаходження гаджетів `sigreturn` (2023-2025) -У сучасних дистрибутивах `sigreturn` тромпліна все ще експортується сторінкою **vDSO**, але точний зсув може варіюватися в залежності від версій ядра та параметрів збірки, таких як BTI (`+branch-protection`) або PAC. Автоматизація його виявлення запобігає жорсткому кодуванню зсувів: +У сучасних дистрибутивах `sigreturn` тромплін все ще експортується сторінкою **vDSO**, але точний зсув може варіюватися в залежності від версій ядра та параметрів збірки, таких як BTI (`+branch-protection`) або PAC. Автоматизація його виявлення запобігає жорсткому кодуванню зсувів: ```bash # With ROPgadget ≥ 7.4 python3 -m ROPGadget --binary /proc/$(pgrep srop)/mem --only "svc #0" 2>/dev/null | grep -i sigreturn @@ -191,7 +191,7 @@ rp++ -f ./binary --unique -r | grep "mov\s\+x8, #0x8b" # 0x8b = __NR_rt_sigret ``` Обидва інструменти розуміють **AArch64** кодування і перерахують кандидатні `mov x8, 0x8b ; svc #0` послідовності, які можна використовувати як *SROP gadget*. -> Примітка: Коли бінарні файли компілюються з **BTI**, перша інструкція кожної дійсної цілі непрямого переходу є `bti c`. `sigreturn` тромпліни, розміщені компілятором, вже містять правильну BTI приземну платформу, тому гаджет залишається придатним для використання з неправа кодом. +> Примітка: Коли бінарні файли компілюються з **BTI**, перша інструкція кожної дійсної цілі непрямого переходу - це `bti c`. `sigreturn` тромпліни, розміщені компілятором, вже містять правильну BTI приземну платформу, тому гаджет залишається придатним для використання з неправа кодом. ## Зв'язування SROP з ROP (поворот через `mprotect`) @@ -213,17 +213,17 @@ Linux 5.16 ввів більш сувору валідацію сигналів * `uc_flags` повинен містити `UC_FP_XSTATE`, коли присутній `extra_context`. * Зарезервоване слово в `struct rt_sigframe` повинно бути нульовим. -* Кожен вказівник у запису *extra_context* вирівняний і вказує всередину адресного простору користувача. +* Кожен вказівник у записі *extra_context* вирівняний і вказує всередину адресного простору користувача. -`pwntools>=4.10` автоматично створює відповідні кадри, але якщо ви створюєте їх вручну, переконайтеся, що ви ініціалізували *reserved* нулями і пропустіть запис SVE, якщо ви дійсно не потребуєте його — в іншому випадку `rt_sigreturn` поверне `SIGSEGV` замість повернення. +`pwntools>=4.10` автоматично створює відповідні кадри, але якщо ви створюєте їх вручну, переконайтеся, що ви ініціалізували *reserved* нулями і пропустіть запис SVE, якщо ви дійсно не потребуєте його — в іншому випадку `rt_sigreturn` поверне `SIGSEGV` замість того, щоб повернутися. Починаючи з основного Android 14 та Fedora 38, користувацький простір компілюється з увімкненими за замовчуванням **PAC** (*Pointer Authentication*) та **BTI** (`-mbranch-protection=standard`). *SROP* сам по собі не підлягає впливу, оскільки ядро безпосередньо перезаписує `PC` з підготовленого кадру, обходячи автентифікований LR, збережений на стеку; однак будь-який **наступний ROP-ланцюг**, який виконує непрямі переходи, повинен переходити до інструкцій з увімкненим BTI або PAC-адресам. Майте це на увазі при виборі гаджетів. -Shadow-Call-Stacks, введені в ARMv8.9 (і вже увімкнені на ChromeOS 1.27+), є мірою пом'якшення на рівні компілятора і *не* заважають SROP, оскільки жодні інструкції повернення не виконуються — потік управління передається ядром. +Shadow-Call-Stacks, введені в ARMv8.9 (і вже увімкнені на ChromeOS 1.27+), є мірою захисту на рівні компілятора і *не* заважають SROP, оскільки жодні інструкції повернення не виконуються — потік управління передається ядром. ## Посилання * [Документація з обробки сигналів Linux arm64](https://docs.kernel.org/arch/arm64/signal.html) -* [LWN – "AArch64 branch protection comes to GCC and glibc" (2023)](https://lwn.net/Articles/915041/) +* [LWN – "Захист гілок AArch64 приходить до GCC та glibc" (2023)](https://lwn.net/Articles/915041/) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md index 6ce6fe41b..61556bf4c 100644 --- a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md +++ b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md @@ -6,11 +6,11 @@ Є 3 способи вказати вміст сторінки в iframe: -- Через `src`, вказуючи URL (URL може бути крос-доменним або того ж домену) -- Через `src`, вказуючи вміст за допомогою протоколу `data:` -- Через `srcdoc`, вказуючи вміст +- Через `src`, що вказує на URL (URL може бути крос-доменним або того ж домену) +- Через `src`, що вказує на вміст, використовуючи протокол `data:` +- Через `srcdoc`, що вказує на вміст -**Доступ до змінних батьківського та дочірнього контексту** +**Доступ до змінних батьківського та дочірнього контекстів** ```html