![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
malyj_gorganСлухайте, а хтось може в парі абзаців пояснити, що то таке сабж і з чим його їдят? Дідько з нею, з його vulterability'ею, я хочу зрозуміти, чим був такий хороший чи зручний чи потрібний сам log4j, що та вульнерабіліті виявилася такою проблємною? Тільки пояснити так, на хлопский розум, без відсилань в непотрібні абревіатури.
Дякую!
Дякую!
no subject
Date: 2021-12-26 01:02 am (UTC)no subject
Date: 2021-12-30 11:13 pm (UTC)Но от ідея, що коли треба надсилати логи кудись ще, крім stdout/err, для цього треба застосовувати окреме знаряддя з окремою логікою/дозволами/адмініструванням. Щоби легше було контролювати безпеку. Ні, воно, звичайно,зручніше, коли все на купу...
В одному університеті студентські карточки мали індивідуальний номер студента. Номер цей, по ідеї був, непублічним, тому придумали класний хід: раз він все одно секретний, то давайте зробимо його таким самим, як SSN, щоби в бухгалтерії все працювало з одним номером і не мучитися з зайвими даними. Геніально спрощує життя! А що студентська айдішка, крім запису на курси в черговому семестрі, використовується для всього на світі, від видачі м'ячиків у спортзалі до проходу в їдальню чи кафе чи комп'ютерну лабораторію, тому кожен студент носить її завжди і всюди, легко губить, відновлює, і далі носить, то ну і шо? Зручно же!
Так і тут: логгінг використовує кожен, кому не лінь. А працювати з функціональністю, де є ризик компроментації безпеки системи, повинні лише окремі відділи. Smth like that.
no subject
Date: 2021-12-30 11:47 pm (UTC)no subject
Date: 2021-12-31 12:40 am (UTC)- Ви, мишки, перетвориться на їжачків. В їжачків колючки, їх ніхто не чипає!
- Класна ідея! стоп, а як нам це зробити?
- Так, це вже деталі, а я стратегією займаюся!
:))))
Якщо б так легко було б визначити - в якому коді є ризик компроментації, а в якому ні? Це ж зовсім не тривіальна задача.
Як приклад - хак айфонів від сумнозвісної NSO. Здавалося би - чого небезпечного є тому, що ти надсилаєш комусь анімовану гіфку, а Епл хоче, щоб вона програвалася по колу, а не як в оригінальному вигляді.
Для цього треба змінити прапорець в хедері - беремо стандартну бібліотеку, робимо копію, змінюємо прапорець - здавалося, що тут небезпечного?
Але хтось зробив помилку і замість "зробити копію" викликався метод "відрендерити та зробити копію". Окей, що тут страшного?
Та поки нічого, але цей метод вже не дивиться на розширення файлу, і йому під виглядом гіфки можна підсунути PDF. А всередині PDF - лежить JBIG2, древнючий формат кодування для факсів.
Ну, формат і формат, чого тут поганого? В принципі, нічого, але цей формат написан для факсів. І він має вбудовану систему візуальної корекції - щоб не переплутати "6" з "8". А для цього він вміє маніпулювати чорно-білими гліфами та робити з ними AND, OR, NOT, XOR.
Це вже цікаво - формально він тюрінг-повний.
І тут починається цікаве - використовуючи переповнення на цієї віртуальної тюрінг-машині технічно можна виконати код, якщо ти знаєш, де що в пам'яті лежить. Але ж в реальному телефоні фіг вгадаєш. І тоді хакери пишуть на цих вентилях програму на 70 тищ інструкцій, яка аналізує - що це за телефон і що на ньому виконується.
Упс.
А все що ти хотів - програвати анімовану гіфку по колу. І як заздалегідь дізнатися, що САМЕ ЦЯ операція несе за собою ризик компроментації системи?
no subject
Date: 2021-12-31 01:40 am (UTC)no subject
Date: 2021-12-31 01:57 am (UTC)Хоча, звичайно, є приклади і коли нічого не зробиш. Доступ до лівих місць в пам'яті мав кілька цікавих експлоітів. Мене особисто найбільше вразив Rowhammer: використання фізичних ефектів для зміни пам'яті -- це круто.
no subject
Date: 2021-12-31 02:23 am (UTC)І як нам визначити, який саме об'єм прав (а) має тий, чи інший метод, і (б) якій об'єм йому потрібен?
Якщо б це було тривіальною задачею в складних системах... Можна розібрати хоча б на прикладі вишепроцитованої вразливості в iMessage.
Що в цьому коді вказує на потенційну ескалацію функціональності?
Чи, наприклад, контекст та організований логінг - необхідні, так? Хтось може сказати - а давайте все ліпити (включно з повним контекстом) в stdout, а sidecar вже збере і розбереться, що треба залишити.
І іноді цій підхід може працювати. А іноді - створювати ще більші вразливості (хоча б тому, що повний контекст та inter-process communication це вже небезпечно, небезпечніше, ніж це робити всередині процесу).
І тому практики integration/deployment за межами critical safety infrastructure важливіші за ідеальний код (хоча б тому, що ідеальний код не можливий принципово, а значить, нам треба вчитись щось робити з неідеальним кодом).
Але, ці практики звучать просто - і навіть відчуваються просто коли вже втілені. А саме втілення дуже складне, бо воно не про 0 та 1, не про алгоритми, не про формальні методи, а про взаємодію людей.
no subject
Date: 2021-12-31 08:39 am (UTC)Це не лише софта стосується, а всього, отакий вічний пошук балансу між тим, щоб довіряти відповідальності інших, чи обмеженням прав і можливостей цих інших на інструментальному/нормативному рівні (тобто, обмеженням доступу до / можливостей відповідних інструментів). Воно ж присутнє всюди: доступ до зброї, регулювання будівництва і вуличного руху, регулювання споживацьких товарів. А вже у вихованні дітей ти про це думаєш щодня багато разів. Так от, на цьому філософському рівні я вважаю, що майже всюди ми зловживаємо інструментальним контролем, але саме ось тут -- навпаки. Хоча забороняти ті чи інші інструменти я не закликаю, закликаю самообмежуватися :)
no subject
Date: 2021-12-31 05:22 pm (UTC)(Це, звісно, в умовах "типового" software development задач - є купа edge cases де ці практики є корисними.)
Що до людей, які вміють, не хочуть чи не мають можливості - це дуже класне питання, яке починається з incentives. Якщо, наприклад, cost-saving менеджер каже "be your own QA" - то можна розробнику розраховувати на бонус за вдосконалення testing pipeline чи скорочення часу виконання тестів на годину? Відповідь на це питання проводить чітку межу між компаніями (чи командами в компанії).
Бо incentives define behavior - якщо за такі практики менеджмент підтримує працівників, то більшість людей активно починає вчитися, хотіти, та шукати можливість. Не все, але більшість.
А що до нестачі інструментального контролю - я погоджусь. Але не в сенсі "тримати та не пущати", а в сенсі саме instruments.
- Штурман, приборы!
- Триста!
- Что триста?
- А что приборы?
Менеджмент coding/integration/deployment practices як раз починається з вимірів того, що в тебе відбувається в цих місцях. А з цим, як правило, дуже сумно - хоча усі інструменти є на ринку, в Гугл найматися, щоб їх використовувати - вже не треба.
no subject
Date: 2021-12-31 07:21 pm (UTC)Я в індустрію попав, коли замість засилля класичних практик почало ставатися засилля заборони класичних практик. В результаті, спостерігав два колективи, де падіння якості продукту дуже чітко слідувало за відмовою від окремого QA і перекладанням усієї відповідальності за якість/безпеку коду на тих людей, які його пишуть. (В третьому колективі окремого к'юей, здається, і не було, тому падіння якості константувати не можу) Якщо ти помітив, я з самого верху не наполягаю на універсальності свого розуміння, як все має працювати, а навпаки, критикую випадки, коли насаджувався первний універсальний підхід тому, що "так модно" або "так дешевше цього місяця"
> ...до бізнес-результатів.
А ось тут вірю. Бізнес результати найчастіше націлені на короткий і середній горизонт подій, тоді як практики типу "звільнимо к'юєїв, хай програмісти просто пишуть кращий код" короткочасно якраз вигідні, а проблеми проявляються в майбутньому. Ще раз: я не кажу, що воно обов'язково всюди так, але у тих двох випадках, які я спостерігав, так і було: новий підхід знижував видатки і збільшував швидкість видачі продукту, бізнес покращувався... зате через 2-3 роки проблеми виростали лавиноподібно, одна компанія зменшилася втричі і пройшла через Chapter 11, друга просто накрилася, але "винен" уже був хтось інший. Звичайно, проблеми з підходом до кодування були не джерелом усіх проблем, а одним із симптомів. Але убиває не причина хвороби, а саме симптоми, це я як медик кажу :)
> ... про менеджерів і інсентівз ...
Exactly! Все правда, і те, що джерелом таких проблем найчастіше є менеджмент, і те, що інженери, в принципі, самі винні, що ведуться, можуть і не вестися.
> Але не в сенсі "тримати та не пущати", а в сенсі саме instruments.
Правильно. "Тримати і не пущати" і "силою заганяти" -- два однаково шкідливі перегиби в різні боки (часто в один)
> ...починається з вимірів того, що в тебе відбувається в цих місцях... в Гугл найматися, щоб їх використовувати - вже не треба.
А тут починаються сумні реалії життя: абстрактно все вимірювати і грамотно організовувати було би класно, але коли у тебе 2/3 команди пішло, нікого нормального найняти не виходить, менеджмент, який до цього докотився, уже помінявся... а ти сидиш в новорічний вечір перед проектом, який тріщить по швах і думаєш, що "блін, якби у них була хоч пара к'юеїв, вони би до цього не допустили" Десь так. Так що це у мене менше універсальні міркування, а більше крик душі :)
no subject
Date: 2021-12-31 07:51 pm (UTC)А що вони можуть зробити, якщо менеджер вирішує звільняти SRE та QA - що є антіпатерном, навіть в компаніях, де девелопери самі займаються тестуванням?
Сказали своє фу менеджменту, менеджмент їх не послухав, що далі? Далі залишається єдина можливість - перейти через дорогу в компанію з більш адекватним менеджментом, що вони і роблять, ні?
Класична проблема:
- В тебе ж сокира тупа!
- Та нема коли точити, рубати треба!
Але ж проблема в тому, що якщо не почати щось робити - ані з retention, ані з hiring, ситуація краще не стане.
Бо навіщо йти працювати, там де бардак та проблеми, якщо можна піти туди, де нема бардаку та проблем?
Як кажуть: "You can change the organization or you can change the organization."
В мене є підозра, що саме це буде примушувати індустрію сепаруватися на окремі прошарки - в одному треш і угар, в іншому адекватні (хоча і неідеальні) практики, і перетинатися ці два світи не будуть.
no subject
Date: 2021-12-31 08:15 pm (UTC)> Бо навіщо йти працювати, там де бардак та проблеми, якщо можна піти туди, де нема бардаку та проблем?
От я і пробую щось робити. Паралельно працюю, планую реорг, перевіряю домашні завдання кандидатів. Ну і, паралельно думаю, чи то таки самому піти туди, де менше проблем, чи своїм прикладом почати покращення в плані retention. Піти -- це вихід, але лишитися -- це шанс щось змінити тут, заробивши на цьому якісь дивіденди. От і думаю.... а в перервах скаржуся тобі :)
no subject
Date: 2021-12-31 08:03 pm (UTC)Якщо ми вже почали звертатися до медичних аналогій, то гірше за відсутність лікування може бути тільки невміле та часткове лікування: хоч software engineering взяти, хоч бактеріальну інфекцію.
no subject
Date: 2021-12-31 11:53 pm (UTC)От, до речі, не обов'язково. Комбінація ефекта плацебо з "само пройшло" часто виступає не набагато гірше, ніж реальне лікування. Враховуючи вартість реального лікування, це створює купу етичних парадоксів, які дають право на існування всяким чаклунствам і гомеопатіям. Трохи спрощеним, але ральним є сценарій, коли треба вибрати що краще: коли у тебе виздоровіє п'ять пацієнтів з десяти, а п'ять помирає від неправильного лікування, чи помирає три пацієнти, а семеро виздоровлює від 70%-ефективної терапії, але ця терапія така дорога, що п'ять з цих семи банкрутує, і через стрес і падіння достатку втрачає 10 років life expectancy.
Словом, ну їх нафіг, ті медичні аналогії.