А працювати з функціональністю, де є ризик компроментації безпеки системи, повинні лише окремі відділи.
- Ви, мишки, перетвориться на їжачків. В їжачків колючки, їх ніхто не чипає! - Класна ідея! стоп, а як нам це зробити? - Так, це вже деталі, а я стратегією займаюся!
:))))
Якщо б так легко було б визначити - в якому коді є ризик компроментації, а в якому ні? Це ж зовсім не тривіальна задача.
Як приклад - хак айфонів від сумнозвісної NSO. Здавалося би - чого небезпечного є тому, що ти надсилаєш комусь анімовану гіфку, а Епл хоче, щоб вона програвалася по колу, а не як в оригінальному вигляді.
Для цього треба змінити прапорець в хедері - беремо стандартну бібліотеку, робимо копію, змінюємо прапорець - здавалося, що тут небезпечного?
Але хтось зробив помилку і замість "зробити копію" викликався метод "відрендерити та зробити копію". Окей, що тут страшного?
Та поки нічого, але цей метод вже не дивиться на розширення файлу, і йому під виглядом гіфки можна підсунути PDF. А всередині PDF - лежить JBIG2, древнючий формат кодування для факсів.
Ну, формат і формат, чого тут поганого? В принципі, нічого, але цей формат написан для факсів. І він має вбудовану систему візуальної корекції - щоб не переплутати "6" з "8". А для цього він вміє маніпулювати чорно-білими гліфами та робити з ними AND, OR, NOT, XOR.
Це вже цікаво - формально він тюрінг-повний.
І тут починається цікаве - використовуючи переповнення на цієї віртуальної тюрінг-машині технічно можна виконати код, якщо ти знаєш, де що в пам'яті лежить. Але ж в реальному телефоні фіг вгадаєш. І тоді хакери пишуть на цих вентилях програму на 70 тищ інструкцій, яка аналізує - що це за телефон і що на ньому виконується.
Упс.
А все що ти хотів - програвати анімовану гіфку по колу. І як заздалегідь дізнатися, що САМЕ ЦЯ операція несе за собою ризик компроментації системи?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2021-12-31 12:40 am (UTC)- Ви, мишки, перетвориться на їжачків. В їжачків колючки, їх ніхто не чипає!
- Класна ідея! стоп, а як нам це зробити?
- Так, це вже деталі, а я стратегією займаюся!
:))))
Якщо б так легко було б визначити - в якому коді є ризик компроментації, а в якому ні? Це ж зовсім не тривіальна задача.
Як приклад - хак айфонів від сумнозвісної NSO. Здавалося би - чого небезпечного є тому, що ти надсилаєш комусь анімовану гіфку, а Епл хоче, щоб вона програвалася по колу, а не як в оригінальному вигляді.
Для цього треба змінити прапорець в хедері - беремо стандартну бібліотеку, робимо копію, змінюємо прапорець - здавалося, що тут небезпечного?
Але хтось зробив помилку і замість "зробити копію" викликався метод "відрендерити та зробити копію". Окей, що тут страшного?
Та поки нічого, але цей метод вже не дивиться на розширення файлу, і йому під виглядом гіфки можна підсунути PDF. А всередині PDF - лежить JBIG2, древнючий формат кодування для факсів.
Ну, формат і формат, чого тут поганого? В принципі, нічого, але цей формат написан для факсів. І він має вбудовану систему візуальної корекції - щоб не переплутати "6" з "8". А для цього він вміє маніпулювати чорно-білими гліфами та робити з ними AND, OR, NOT, XOR.
Це вже цікаво - формально він тюрінг-повний.
І тут починається цікаве - використовуючи переповнення на цієї віртуальної тюрінг-машині технічно можна виконати код, якщо ти знаєш, де що в пам'яті лежить. Але ж в реальному телефоні фіг вгадаєш. І тоді хакери пишуть на цих вентилях програму на 70 тищ інструкцій, яка аналізує - що це за телефон і що на ньому виконується.
Упс.
А все що ти хотів - програвати анімовану гіфку по колу. І як заздалегідь дізнатися, що САМЕ ЦЯ операція несе за собою ризик компроментації системи?