Погнали 🌝

https://xn--r1a.website/mintsifry/2406

11 декабря буду на открытой конференции ИСП РАН https://www.isprasopen.ru/, если кто захочет пересечься пишите в комменты или в личку. В этот раз я без доклада =)

Для меня самая интересная секция будет 12 декабря - "Технологии анализа, моделирования и трансформации программ", но посмотреть мне её получится только в записи

Доклады секции, которые меня заинтересовали

- Возвращаясь к восстановлению потока управления по бинарному коду: подход, основанный на абстрактной интерпретации

- Применение формальных спецификаций системы команд для функционального тестирования языковых виртуальных машин

- TSAR: инструмент для оценки статических анализаторов

- Многоаспектный подход к поиску утечки ресурсов на основе статического анализа

- Извлечение шаблонов HTTP-запросов из мобильных приложений методом статического анализа

- Уязвимости GCC и LLVM к атакам на конвейер оптимизации

- Конструирование программных систем, нацеленное на обеспечение безопасности

NANOWAR OF STEEL - HelloWorld.java (Source Code Video) | Napalm Records

Металл-группа Nanowar of Steel выпустила трек, в котором спела валидный код на Java

Исходный код, он же текст песни
https://github.com/NanowarOfSteel/HelloWorld

Пятница, какая надо пятница! 🤘

Ребята из Cyber Media "поймали" после очередного митапа и позадавали разные вопросы про фаззинг-тестирование: от что это вообще такое до как попробовать https://xn--r1a.website/secmedia/2338. Enjoy!

Я в целом согласен с основной мыслью поста, за исключением слов должны. Это open source, тут никто никому ничего в общем случае не должен 🌝

Сейчас Kubernetes воспринимается как «готовое» и самодостаточное ПО — грубо говоря, как отдельная программа. Да, чтобы его использовать в проде, придется добавить к нему разных cloud native-инструментов: CNI, service mesh и т.п. штуковины. Однако всё же K8s выглядит именно как приложение (иногда его даже называют ОС для облаков). 

На мой взгляд, такое понимание Kubernetes заводит рынок в тупик. Очевидно, что сложность оркестратора должна расти, очевидно, что будет все больше сфер, в которых он будет использоваться и которые способны извлечь немало пользы из внедрения K8s. И требованиям этих сфер он должен соответствовать, чтобы быть успешным продуктом и сохранять свои лидирующие позиции.

Рынок должен начать смотреть на Kubernetes как на Linux Kernel. Что я имею в виду? В трезвом уме сисадмин маленькой или средней компании вряд ли станет говорить на работе, что не нужно использовать дистрибутив Linux — мол, сейчас он возьмет ядро и соберет свой дистрибутив. Так просто не принято: все понимают, что надо выбирать готовый дистрибутив, подходящий под конкретный набор задач. Да, есть и универсальные дистрибутивы, которые более-менее успешно могут использоваться под разные задачи, однако помимо дистрибутивов общего пользования (generic purpose), есть и куча специфических дистрибутивов вроде того же Talos Linux, Kali Linux, VyOS, DSL, SLAX, которые заточены под конкретные виды задач.
. . .
Многие ли инженеры четко и полноценно понимают, что там скрыто в недрах Linux Kernel, какие крутилки ядра применены в том или ином дистрибутиве Linux? А все потому, что рынок принял дистрибутив как некий эталон юнита с минимальной единицей бизнес-ценности, дробить эту абстракцию до уровня ядра или отдельных компонентов ядра просто нет смысла. Конечно, крупные компании собирают свои дистрибутивы — например, тот же Microsoft уже в новой технологической истории сделал Azure Linux. Однако большинству компаний это не нужно.

Тут возникает вопрос: а как поменять это мышление? Что для этого должно произойти? На мой взгляд, для полноценного запуска этого тектонического сдвига необходимы следующие процессы:

- Рабочие группы CNCF (TAG App Delivery, Technical Oversight Committee, а также мейнтейнеры и главные спонсоры Kubernetes) должны запустить дискуссии по этой теме. Обсудить перспективы и угрозы, в итоге выработав некую продуктовую стратегию. Потому что в итоге Kubernetes как продукт должен претерпеть достаточно серьезные изменения — одно дело, когда разрабатывается полноценное ПО и совсем другое, когда разрабатывается компонент, пусть и центральный. 

- TAG App Delivery, Technical Oversight Committee должны начать говорить с рынком и транслировать в него послание о том, что необходимо много платформ, чтобы были альтернативы. А также создать документы и технические условия (или инициировать формирование новой рабочей группы), позволяющие максимально упростить процесс создания платформы (собственно, Kubernetes как продукт должен сфокусироваться именно на том, что он становится центральным компонентом сторонней платформы).

- Талантливые и предприимчивые инженеры, а также часть тех компаний, которые разрабатывали свои внутренние платформы, должны переключиться на разработку публичных платформ (свободных или проприетарных — это уже вопрос второй, главное, чтобы были альтернативы). 

- Крупные игроки различных рынков должны начать объединяться вокруг различных платформ или создавать новые, которые максимально соответствуют требованиям конкретного рынка и заточены под него.

- CNCF и другие open source-организации должны брать такие проекты под свое крыло и помогать им развиваться, а также выделять под продвижение такого подхода временные слоты на ключевых конференциях, которые они организуют (речь, например, о Kubecon).

Неизбежное будущее Kubernetes: почему оркестратор должен пойти по пути Linux Kernel
https://habr.com/ru/companies/aenix/articles/865238/

Канал автора @glina_nauchit

Абсолютно потрясающий пост о том как RCE на GameBoy Colour запускали. Для этого была выбрана игра Pokemon Crystal JP (именно японская версия), которая умела работать с Mobile Adapter GB (это железяка, которая позволяет подключать GameBoy к Интернетам; картинку прицепил к посту)

Если кратко, то сначала автор разревёрсил работу Mobile Adapter GB, например

The ROM doesn’t handle DNS, it just has a command to ask the mobile phone to lookup a domain for it and send an IP address back.

Потом разобрал "протокол" взаимодействия игры с HTTP и POP(!!11!) -серверами, через которые происходило получение покемонов в игре.

После этого изучил различные существующие эксплойты для игры и обратил внимание на один конкретный (https://glitchcity.wiki/wiki/0x1500_control_code_arbitrary_code_execution), который использовали спидраннеры (он не подходил для японской версии и требовал доработки)

Следующим этапом было исследование протокола взаимодействия для организации битвы покемонов (https://archives.glitchcity.info/forums/board-76/thread-7509/page-0.html). В результате длительных мучений был написан скрипт, который позволял снимать временной лимит для битв (10 минут в день) и продвинуться дальше.

В конце автору через RCE удалось вывести цифру 3 на экран (скину GIFку в комменты, на ней самом конце это видно).

В статье огромное количество технических подробностей с пояснениями, иллюстрациями и ссылками. Всем кто, как и я, любит подобное очень рекомендую.

Tetsuji: Remote Code Execution on a GameBoy Colour 22 Years Later
https://xcellerator.github.io/posts/tetsuji/
+
GitHub
https://github.com/xcellerator/tetsuji

РебятЫ из @secmedia взяли интервью у меня и посвящено оно open source, движухе внутри и вокруг него, а также про процессы работы с open source-кодом в своем проекте и почему создание российских платформ для открытого кода не решает всех проблем.

Анатолий Карпенко, Luntry: Как только вы что-то внесли в проект в виде зависимости или тулинга – оно моментально становится вашим
https://securitymedia.org/articles/interview/anatoliy-karpenko-luntry-kak-tolko-vy-chto-to-vnesli-v-proekt-v-vide-zavisimosti-ili-tulinga-ono-mom.html

Кидаться замечаниями можно в комментарии и в личку @rusdacent 🌝

Сегодня официально выпустили новую версию Kubernetes — 1.32. Среди главных нововведений — возможность задавать ресурсы на уровне пода, асинхронное вытеснение подов планировщиком, нулевое ожидание (sleep) для PreStop-хуков, новые эндпоинты /statusz и /flagz для ключевых компонентов K8s, более гранулярная авторизация для API kubelet’а, внешнее управление ключами сервисных учётных записей и специальная функция, с помощью которой плагины смогут подсказывать планировщику, когда стоит повторить попытку планирования.

Kubernetes 1.32: возможность задавать ресурсы на уровне пода и асинхронное вытеснение подов планировщиком
https://habr.com/ru/companies/flant/articles/864988/