Введение

В нашем предыдущем посте Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models мы рассказали о фреймворке для исследований уязвимостей при помощи языковых моделей и продемонстрировали его потенциал, усовершенствовав показатели современных бенчмарков CyberSecEval2 компании Meta. С тех пор Naptime эволюционировал в Big Sleep — совместный проект Google Project Zero и Google DeepMind.

Сегодня мы с радостью готовы поделиться первой уязвимостью из реального мира. обнаруженной агентом Big Sleep: отрицательным переполнением (underflow) буфера стека с возможностью реализации эксплойтов в SQLite, — широко используемом опенсорсном движке баз данных. Мы обнаружили уязвимость и сообщили о ней разработчикам в начале октября, и они устранили её в тот же день. К счастью, мы обнаружили эту проблему до её появления в официальном релизе, так что она не затронула пользователей SQLite.

Мы считаем, что это первый публичный пример обнаружения ИИ-агентом ранее неизвестной уязвимости безопасности по памяти в широко используемом реальном ПО. В этом же году на мероприятии DARPA AIxCC команда Team Atlanta обнаружила разыменование нулевого указателя в SQLite, что вдохновило нас использовать его в нашем тестировании, чтобы проверить, сможем ли мы найти более серьёзную уязвимость.

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

Сама уязвимость довольно любопытна, к тому же существующая инфраструктура тестирования SQLite (и через OSS-Fuzz, и через собственную инфраструктуру проекта) не обнаружила проблему, так что мы провели дополнительное исследование.

Ближе к концу превосходной ленты Вима Вендерса «Идеальные дни» главный герой Хираяма пьёт пиво под мостом после того, как увидел, как Бизнесмен ухаживает за девушкой, в которую влюблён Хираяма. Внезапно к нему подходит Бизнесмен. Всё оказалось не так просто, но их беседа приводит их к фундаментальным вопросам:

Бизнесмен: Тени. Становятся ли они темнее, когда накладываются друг на друга?
Хираяма: Не знаю.
Бизнесмен: Я не знаю ещё очень многого... Именно так заканчивается жизнь... Наверно.
Хираяма: Давайте узнаем прямо сейчас.
Бизнесмен: Что?

И они выходят на свет уличного фонаря, чтобы изучить свои тени (сцена целиком).

Хотя Бизнесмен и не видит разницы, Хираяма уверен, что пересекающиеся тени действительно становятся темнее. «Они должны становиться темнее, это логично». Очень сильная сцена.

К сожалению, Хираяма ошибается. Тени не становились темнее. Источник света всего один, и он довольно далеко, поэтому тень — это просто отсутствие света. Не важно, сколько раз перекрыт источник света.

В 3D-видеоиграх же тени — это нечто совсем иное. Очень легко нарисовать тёмное пятно под ногами персонажа и предполагать, что всё остальное освещено. Возможно, Хираяма вспоминал тень-пятно из Metal Gear Solid, которая становится темнее, когда накладывается на другие?

Когда мы взаимодействуем с текстовым файлом при помощи редактора, то, что мы видим, не всегда отражает содержимое файла. Да, содержимое файла с неформатированным текстом — это байтовые коды, закодированные в таких форматах, как ASCII, UTF8 и UTF16, и в этих байтовых кодах находится источник истины. Но в конечном итоге, именно текстовый редактор выбирает, как интерпретировать и отображать пользователю источник истины (двоичные коды). Это значит, что два файла могут выглядеть одинаково или один и тот же файл может выглядеть по-разному в зависимости от редактора.

Текстовый редактор может подсвечивать (или нет) отдельные части на основании распознанного им синтаксиса, может управлять отображением табов (2 пробела, 4 пробела или даже 8). Он решает, как кодировать нажатие клавиши Tab, например, как \t или как заданное количество пробелов. То же относится и к нажатию на клавишу Enter для создания новой строки — будет ли она кодироваться как \n (UNIX) или \r\n (Windows), зависит от конфигурации редактора.

Текстовый редактор скрывает подробности, чтобы пользователю не пришлось слишком много думать. Однако довольно часто такие подробности протекают сквозь защитный слой, который пытается создать редактор. И мы часто не замечаем подобные тонкости, пока не столкнёмся с ними.

Основная цель моей статьи — поделиться своим опытом и проблемами, с которыми можно столкнуться, работая с неформатированным текстом.

В начале пандемии Мойра Олмстед ненадолго покинула колледж, чтобы выйти замуж, после чего готова была вернуться к занятиям. Несколько месяцев подряд она выкраивала время между работой на полную ставку и уходом за младенцем для участия в программе со свободным графиком, позволявшей обучаться удалённо. На седьмом месяце беременности вторым ребёнком в 2023 году Олмстед поступила на онлайн-курсы педагогики в Центральном методистском университете.

В начале осеннего семестра Олмстед отправила письменное домашнее задание по курсу, один из трёх конспектов по прочитанному, которые нужно было писать каждую неделю. Вскоре после этого она ей пришла оценка: ноль. Обратившись к своему преподавателю, она узнала, что инструмент выявления ИИ определил её работу как сгенерированную искусственным интеллектом. По словам преподавателя, одно из её заданий уже было помечено таким же образом ранее.

Для 24-летней Олмстед это обвинение стало огромным ударом. Кроме того, оно угрожало её дальнейшей учёбе в университете. «Я была потрясена, ведь у меня могли забрать плоды моих трудов за то, чего я не делала», — рассказывает она.

• Когда следует перехватывать исключения, генерируемые вызываемыми вами функциями, а когда этого делать не нужно?
• Как узнать, какие классы исключений нужно перехватывать?
• Что нужно делать при перехвате исключений для их «обработки»?
• Почему перехватывание всех исключений считается порочной практикой, и когда делать это приемлемо?

• Уязвимость к hash flooding.
• В случае защиты от hash flooding случайными seed порядок итераций становится недетерминированным, что мешает при тестировании снэпшотов, создании воспроизводимых сборок и так далее.
• При вставке может требоваться рехэширование, что в наихудших случаях создаёт для больших хэш-таблиц ужасные задержки.
• Многократное увеличение больших распределений памяти без фрагментации сложно реализовать в целевых платформах wasm, потому что трюки с виртуальной памятью недоступны, а для страниц невозможно выполнить unmapping.
• Векторные команды в wasm ограничены, а команды AES отсутствуют. Это делает многие хэш-функции ещё более медленными.

Помните те времена, когда понятие «сениор-разработчик» ещё что-то значило? Я —да, и я не могу избавиться от ностальгии по этому чёткому разделению. В последние годы наша отрасль стала свидетелем ужасной инфляции названий должностей, превратившей чёткую градацию «джуниор-мидл-сениор» в хаотичный парад обесценившихся титулов.

Звание «сениор», когда-то бывшее признаком большого опыта и знаний, обесценилось больше всего. Сегодня разработчиков начинают величать «сениорами» невероятно быстро, часто всего спустя три-четыре года работы. Как будто путь к «сениорству», бывший когда-то марафоном нарабатывания навыков и разнопланового опыта, превратился в спринтерский забег.

Такой резкий рост количества громких должностей не просто сбивает с толку, но и разрушает весь смысл карьерных ступенек в сфере технологий. Каждое новое название должности стремится превзойти предыдущее в громкости, при этом парадоксально знача всё меньше и меньше. Для всех затронутых этим, от ищущих работу до менеджеров по найму, такая инфляция затуманила понимание профессионального развития и признания заслуг.

Похоже, популярный способ преобразования строки в верхний или нижний регистр заключается в побуквенном изменении.

Но он ошибочен по многим причинам.

Во-первых, std::tolower — это неадресуемая функция. Среди прочего, это значит, что мы не можем брать адрес функции, как мы делаем это здесь, когда передаём указатель на функцию std::transform. То есть нам нужно использовать лямбду.

Один из разделов статьи Overview of cross-architecture portability problems я посвятил проблемам, возникающим из-за использования 32-битного типа time_t. Это архитектурное решение, до сих пор влияющее на использующие glibc системы с Gentoo, приведут к тому, что у 32-битных приложений в 2038 году начнут возникать ужасные сбои: они будут получать ошибку -1 вместо текущего времени и не смогут выполнять stat() файлов. Одним словом, возникнет полный хаос.

Считается, что решением будет переход на 64-битный тип time_t. Musl уже перешёл на него, а glibc поддерживает его как опцию. Многие другие дистрибутивы, например, Debian, совершили этот переход. К сожалению, дистрибутивам на основе исходников, например, Gentoo, сделать это не так просто. Поэтому мы по-прежнему обсуждаем эту проблему и экспериментируем, пытаясь понять, как пользователи максимально безопасно могли бы выполнить апгрейд.

К сожалению, это совершенно нетривиально. Во-первых, мы говорим о переломном изменении ABI — ситуация «всё ли ничего». Если в API библиотеки используется time_t, то всё связанное с ней должно использовать ту же ширину типа. В этом посте я бы хотел подробно рассмотреть этот вопрос: почему это плохо и что мы можем сделать, чтобы повысить безопасность.

Введение

При разработке или портировании игры для PC приходится иметь дело с пользовательским вводом, который обычно разделяется на три категории источников: мышь, клавиатуру и геймпады.

По началу может показаться, что работать с мышью и клавиатурой проще всего, но на самом деле это не так; по крайней мере, когда мы говорим о Windows. Множество очень популярных AAA-игр было выпущено с серьёзными проблемами ввода с мышами верхнего ценового диапазона, и в некоторых популярных движках по-прежнему существует эта проблема.

В этой статье мы изучим причины этого, а также создадим работающее, но неудовлетворительное решение. Думаю, для правильной работы с такими аксессуарами, как рули, джойстики и другие симуляторные устройства, требуется целый дополнительный уровень сложности, но пока мне пока не доводилось работать над игрой, в которой бы нужен был такой ввод, поэтому в статье мы не будем его рассматривать.

• Точка контакта мяча с ракеткой определяет угол отражения
• У ракеток нет ограничений по скорости
• Мяч отскакивает от верха и низа экрана

Опенсорсные модели становятся всё объёмнее, поэтому потребность в надёжной инфраструктуре для выполнения крупномасштабного обучения ИИ сегодня как никогда высока. Недавно наша компания выполнила fine-tuning модели LLaMA 3.1 405B на GPU AMD, доказав их способность эффективно справляться с крупномасштабными задачами ИИ. Наш опыт был крайне положительным, и мы с радостью выложили всю свою работу на GitHub в опенсорс.

GPU AMD, и в особенности серия MI300X — это серьёзная альтернатива ИИ-оборудованию NVIDIA, обеспечивающая больше производительности на вложенный доллар. Наша система состояла из одного узла с 8 GPU AMD MI300x, а для fine-tuning мы использовали JAX. В этой статье мы расскажем всю историю fine-tuning LLaMA 405B, в том числе и подробности шардинга параметров и реализации LoRA.

Qualcomm — не новичок в мире интегрированной графики. Её линейка Adreno GPU использовалась во многих поколениях SoC Snapdragon для сотовых телефонов. Но компании Qualcomm всегда было тесно в рамках телефонного рынка, она таила амбиции расширить свою мощь и выйти на другой уровень производительности. Сегодня её Snapdragon X Elite выпускается с прицелом на рынок ноутбуков. Adreno тоже переносится на рынок более высокой производительности, на котором есть такие конкуренты, как iGPU Intel Xe-LPG в Meteor Lake и iGPU AMD RDNA 3 в Phoenix.

При работе над поддержкой незнакомой мне кодовой базы я трачу кучу времени на поиск строк при помощи grep. Даже в проектах, полностью написанных мной, мне нужно много искать: имена функций, сообщения об ошибках, имена классов и тому подобное. Если я не могу найти нужное, то я буду как минимум расстроен, а как максимум могу создать опасную ситуацию, если предположу, что какой-то элемент больше не нужен, ведь я не могу найти ссылок на него в кодовой базе. На основании этих ситуаций я выработал правила, которые позволяют повысить греппабельность кода.

Сетевые коммутаторы — простые устройства: принимаешь пакет, отправляешь пакет. К счастью, люди придумали, как усложнить их, и изобрели управляемые коммутаторы.

Обычно они реализуются добавлением веб-интерфейса, конфигурирующего настройки и контролирующего такие параметры, как состояние портов. В более дорогих коммутаторах есть доступ к альтернативным интерфейсам, например, Telnet и последовательным консольным портам.

Однако есть и вторая категория управляемых коммутаторов, о которых вспоминают не сразу, это коммутаторы, находящиеся внутри маршрутизаторов потребительского уровня. Эти маршрутизаторы — небольшие устройства на Linux, имеющие внутри чип коммутатора, один или несколько портов с внутренним подключением к CPU, а остальные выведены наружу как физические порты.

e|-----------------|-----------------|-----------------|-----------------|
B|-----------------|-----------------|-----------------|-----------------|
G|-----3---5-------|---3---6-5-------|-----3---5-----3-|-----------------|
D|-5---3---5-----5-|---3---6-5-------|-5---3---5-----3-|---5-------------|
A|-5-------------5-|-----------------|-5---------------|---5-------------|
E|-----------------|-----------------|-----------------|-----------------| <- верх

Что такое One Million Checkboxes?