Угрозы безопасности

Всем привет,

Минутка деанона, меня зовут Анатолий Маковецкий, я Security Team Lead в Exness.
Сразу извинюсь перед теми, кто ожидает увидеть технический write-up, здесь его не будет. Также в материале описаны настолько очевидные на первый взгляд вещи, что даже не факт, что они являются таковыми, но вы резонно можете меня спросить, как меня наняли и когда я уже перестану притворяться безопасником (ответ на картинке под катом) :).



Погнали.


Изображение: Telegram канал Information Security Memes (http://personeltest.ru/aways/t.me/infosecmemes)

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

Согласитесь, это же так классно в условиях отсутствия строгого менеджмента, выстроенных процессов, понятных приоритетов и иного счастья, скакать с системы на систему, находить красивые баги на поверхности или чуть глубже на основе чужих свежих ресерчей или собственного опыта, показывать впечатляющие пути их эксплуатации. Это реально позволяет выстроить диалог с другими ИТ-командами, заработать немного авторитета. Куда-то меня не туда понесло

Да, правильно, настоящая информационная безопасность зиждется на процессах, ISO, 27k в зубы и пошли выносить мозги ИТ и топ-менеджменту, все расскажем, все разложим, обоснуем и покажем, никто не поспорит, ведь, надо, только станут ли наши процессы в полях лучше от внедрения очередного стандарта?

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


Фото: s.66.ru

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

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

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

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

1. Информационные безопасники топят за необходимость защиты всего и вся, часто не расставляя реальные приоритеты, и радуются любой возможности прилюдно линчевать кого-то гордо нахмурив брови проявить себя при нарушении кем-то построенного или недостроенного процесса.
2. Практические безопасники часто концентрируются на недопустимости наличия уязвимостей где бы то ни было, так как это потенциально компрометирует все окружение, но имеют также пробелы в части приоритезации, отдавая более высокий приоритет более уязвимой системе, чем более чувствительной, но менее* уязвимой.

Часто мы опираемся на чужой опыт, на чужие приоритеты, о которых где-то прочитали, которые не всегда неверные и неподходящие, но часто достаточно не оптимальные для конкретных условий, из разряда Quick Start, что порой, все же, может оказаться оправдано, когда кругом перекати-поле и коршуны кружат, и явно лучше, чем ничего, но бизнес тем временем живет сам по себе.

Да, кстати, а что там про диалог бизнеса и безопасности? По моему глубокому мнению, мы (безопасники) очень часто пытаемся продать бизнесу то, что он не понимает, что ему не сильно нужно и то, что к нему слабо относится, либо ничего продать даже не пытаемся. То есть наша аргументация как представителей безопасности строится на идеях и устоях нашей же индустрии, от которой бизнес может оказаться очень далек, а мотивировать нужно понятным языком и обоснованно, тогда эффект будет предсказуемее, долговременнее, а вовлеченность бизнеса выше. В конечном итоге, за бюджетом нам идти именно к бизнесу, как бы ни хотелось, чтоб все было наоборот :)

А зачем мы вообще нужны бизнесу? Иногда безопасность нужна для галочки, так как просто-напросто требуется. Давайте такие кейсы оставим, а поговорим про случаи, когда безопасность появляется из-за понимания потребности в ней. Правильный бизнес хочет денег всесторонне оценивать наперед потенциальные риски, бороться с ними заранее, а также своевременно и эффективно реагировать на реализующиеся угрозы, делать из них выводы на будущее и становиться сильнее. То есть нас нанимают, чтобы мы помогали, но как мы можем помочь?

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

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

Давайте на минутку уйдем в сторону и представим себе общий процесс моделирования угроз, как вижу его я:

1. Мы определяем ценные активы компании, а ценные это те, нарушение свойств которых ведет в конечном итоге к потерям, по опыту, которые в итоге сводятся к финансовым прямо или косвенно, если речь о коммерческой компании. Здесь у нас, как правило, получается та или иная информация, которую мы должны защищать из собственного интереса или по причинам регулирования. Не довелось мне работать на золотых приисках, может, там и не информация на первом месте.
2. Ранжируем те самые ценные активы, чтоб хоть как-то расставить приоритеты.
3. Определяем системы, в которых эти ценные активы обрабатываются и хранятся, а в современной компании, как правило, все обрабатывается автоматизировано, в информационных системах (а то, что кто-то из работников может утащить фикус с подоконника, да пачку кофе с общей кухни, тут смело пренебрегаем, плохо, но масштаб не тот).
4. Ранжируем системы по степени влияния на свойства тех самых ценных активов.
5. Определяем процессы, которые влияют на наши ценные активы, и, вероятно, реализуются в системах, которые мы определили выше, хотя не всегда.
6. Ранжируем процессы по степени влияния на активы и бизнес в целом.
7. На стыке получаем связи активов с системами и процессами, понимаем**, что защищать и в какую очередь.

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

В финтехе есть деньги.

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

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

На изображении ниже схема информационных потоков одного из наших продуктов :)


Изображение: сериал DuckTales Walt Disney Television Animation

Также уход от парадигмы, что мы защищаем только информацию, позволил понять еще один тип ценных ресурсов, которым я пренебрегал ранее, но он присутствует у всех, хотя и является довольно неоднозначным взаимоотношения, которые могут быть партнерскими отношениями с поставщиком клиентов/трафика, либо с провайдером услуг связи/сервиса безопасности/инфраструктуры. Конечно, раньше я всегда неявно рассматривал это, но в контексте реализации угрозы в вакууме, из разряда Business Continuity Plan и Disaster Recovery Plan, а здесь оно трансформировалось в сознании во вполне осознанный актив, который стоит идентифицировать и защищать, что расширяет наше покрытие, так как мы начинаем двигаться в этом отношении не только от известных угроз, но и от самого актива, как от объекта потенциально подверженного неизвестным угрозам, но не об этом сейчас.

Если посмотреть ближе, то деньги виднеются со всех сторон:

1. Как минимум, есть все та же хозяйственная деятельность, как и в любой другой компании.
2. Есть продукты, которые связаны с финансовыми операциями и со скоростью их проведения, в которых заложена реальная логика входа и выхода денежных средств, то есть деньги не получится убрать в дальний сейф и давать посмотреть на них только раз в сутки после специальной церемонии с поклонами и полным раздеванием. Их нужно гонять в системах, и чем быстрее, тем, зачастую, лучше для бизнеса.
3. Есть огромная куча различных платежных систем и других инструментов, у каждого из которых свои реализации взаимодействия, ограничения и особенности интеграции.
4. Есть инфраструктура, в которой продукты работают.
5. Есть инженеры, которые делают продукты; инженеры, которые сопровождают продукты; инженеры, сопровождающие инфраструктуру; финансисты, которые имеют доступ к какой-то части финансовых процессов и многие другие.
6. Есть сами процессы, которые идут через разные системы и команды.

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

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

То есть в случае с Интернет-банкингом или крипто-кошельками у вас есть креды/секреты/ключи для доступа к ним (обобщим словом секреты). Секреты это информация, но есть еще процессы, процедуры и церемонии по работе с ними, ну и относительно потенциально узкий круг лиц для работы с ними. Здесь тоже концепция защиты информации не ломается, но когда мы переходим к стадии прохождения платежной логики прямо или косвенно через все вокруг, а также к размазыванию денег по разным продуктам и системам, то ситуация становится куда более tricky :)

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

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

Если этот материал не провалится по полной, то дальше постараюсь более подробно и практически-ориентированно раскрыть основные подходы, инструменты и субъективное видение таких тем, как:

• Мой велосипед на тему моделирования угроз (если будет спрос на него, так как велосипедов и без моего хватает);
• (Не)доверие и безопасность;
• Bug Bounty, как мы это делаем и к чему стремимся;
• Замечания об особенностях русскоязычного рынка ИБ-специалистов после длительного опыта в качестве интервьюера;
• Что должно драйвить безопасность.

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

Всем добра и сбалансированного профессионального подхода!

8 марта мы рассказали о том, что из соображений безопасности разлогинили всех пользователей GitHub.com из-за редкой уязвимости защиты. Мы считаем, что прозрачность ключевой фактор сохранения доверия со стороны пользователей, поэтому решили рассказать об этом баге подробнее. В этом посте мы изложим технические детали данной уязвимости и объясним, как она возникла, как мы на неё отреагировали и какие мы предприняли шаги для того, чтобы подобное не повторилось.

Отчёты пользователей

2 марта 2021 через службу технической поддержки мы получили отчёт пользователя, который войдя на GitHub.com под собственными идентификационными данными, внезапно авторизировался как другой пользователь. Он немедленно вышел из аккаунта, но сообщил о проблеме нам, поскольку она обеспокоила его, и на то были все основания.

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

Исследование недавних изменений в инфраструктуре

Учитывая то, что этот баг был новым поведением, мы сразу же заподозрили, что он связан с недавним изменением в нашей инфраструктуре, и начали поиск решения с анализа изменений. Недавно мы обновили компоненты на уровне системы, занимающемся балансировкой нагрузки и маршрутизацией. Мы выяснили, что устранили проблему с keepalive-сообщениями HTTP, которая, по нашему мнению, могла быть связана с указанной в отчётах проблемой.

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

Исследование недавних изменений в коде

Благодаря тому, что мы начали расследование с недавних изменений в инфраструктуре, нам удалось выяснить, что запросы, приводившие к возврату неправильной сессии, обрабатывались на одной и той же машине и в одном процессе. Мы используем многопроцессную схему с веб-сервером Unicorn Rack, выполняющим наше основное Rails-приложение. обрабатывающее такие задачи, как отображение issues и пул-реквестов.

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

У нас появилась рабочая теория о том, что нечто каким-то образом приводило к утечке состояния между запросами, которые обрабатывались в одном процессе Ruby. Нам нужно было выяснить, как такое может происходить.

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

Безопасность потоков и отчёты об ошибках

Для понимания проблемы с безопасностью потоков необходим контекст. Основное приложение, обрабатывающее большинство браузерных взаимодействий на GitHub.com это приложение Ruby on Rails, известное тем, что оно имело компоненты, написанные без учёта возможности в нескольких потоках (т.е. они были непотокобезопасны). Обычно в прошлом непотокобезопасное поведение могло приводить к неправильному значению во внутренних отчётах об исключениях системы, но при этом пользователи не сталкивались с изменением поведения системы.

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

Изначально мы думали, что это только внутренняя проблема отчётности, и что мы будем наблюдать в логах данные, зафиксированные от не относящегося к делу запроса в фоновом потоке. Несмотря на противоречивость, мы посчитали такое поведение безопасным, поскольку каждый запрос имел собственные данные запроса, а Rails-приложение создавало новый экземпляр объекта-контроллера для каждого запроса. Нам по-прежнему было непонятно, как это могло вызывать проблемы, с которыми мы столкнулись.

Многократно используемый объект

Наша команда совершила прорыв, обнаружив, что HTTP-сервер Unicorn Rack, используемый в нашем Rails-приложении, не создаёт новый и отдельный объект env для каждого запроса. Вместо этого он выделяет единственный Ruby Hash, который очищается (с помощью Hash#clear) между запросами, которые он обрабатывает. Благодаря этому мы поняли, что проблема с потокобезопасностью в логгинге исключений может привести не только к неправильности фиксируемых в исключениях данных, но и к передаче данных запросов на GitHub.com.

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

1. В потоке обработки запросов запускается анонимный запрос (назовём его Request #1). Он регистрирует обратный вызов в текущем контексте для внутренней библиотеки отчётности об исключениях. Обратные вызовы содержат ссылки на текущий объект контроллера Rails, имеющий доступ к единому объекту среды запроса Rack, предоставляемого сервером Unicorn.
2. В фоновом потоке возникает исключение. Сообщение об исключении копирует текущий контекст, чтобы включить его в отчёт. Этот контекст содержит обратные вызовы, зарегистрированные запросом Request #1, в том числе и ссылку на единую среду Rack.
3. В основном потоке запускается новый запрос залогиненного пользователя (Request #2).
4. В фоновом потоке система отчётности об исключениях обрабатывает обратные вызовы контекста. Один из обратных вызовов считывает идентификатор сессии пользователя, но поскольку запрос на момент контекста не имеет авторизации, эти данные ещё не считываются, и, следовательно, запускают новый вызов к системе авторизации через контроллер Rails из запроса Request #1. Этот контроллер пытается выполнить авторизацию и получает куки сессии из общей среды Rack. Так как среда Rack это общий объект для всех запросов, контроллер находит куки сессии запроса Request #2.
5. В основном потоке запрос Request #2 завершается.
6. Запускается ещё один запрос залогиненного пользователя (Request #3). В этот момент Request #3 завершает свой этап авторизации.
7. В фоновом потоке контроллер завершает этап авторизации, записывая куки сессии в cookie jar, находящийся в среде Rack. На данном этапе это cookie jar для Request #3!
8. Пользователь получает ответ на запрос Request #3. Но cookie jar был обновлён данными куки сессии Request #2, то есть пользователь теперь авторизован как пользователь из Request #2.

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

Для возникновения этого бага требовались очень конкретные условия: фоновый поток, общий контекст исключения между основным потоком и фоновым потоком, обратные вызовы в контексте исключения, многократное использование объекта env между запросами и наша система авторизации. Подобная сложность является напоминанием о многих из пунктов, представленных в статье How Complex Systems Fail, и демонстрирует, что для возникновения подобного бага требуется множество различных сбоев.

Предпринимаем действия

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

После выпуска изменения с удалением фонового потока, мы создали патч для Unicorn, удаляющий возможность создания общей среды. Этот патч был выпущен 8 марта и ещё больше усилил изоляцию между запросами, даже на случай возникновения проблем с потокобезопасностью.

Кроме устранения бага мы предприняли действия для определения пользовательских сессий, на которые он повлиял. Мы изучили данные логгинга на предмет паттернов, соответствующих неправильно возвращаемых сессий. Затем мы вручную просмотрели соответствующие паттерну логи, чтобы определить, на самом ли деле сессия была неверно возвращена от одного пользователя другому.

В конце мы решили сделать ещё одно превентивное действие, чтобы гарантировать безопасность данных наших пользователей, и аннулировали все активные сессии пользователей на GitHub.com. Учитывая редкость условий, необходимых для возникновения этого условия гонки, мы знали, что вероятность возникновения бага очень мала. Хотя наш анализ логов, проведённый с 5 по 8 марта, подтвердил, что это была редкая проблема, мы не могли исключить вероятность того, что сессия была неверно возвращена, но никогда не использовалась. Мы не хотели идти на такой риск, учитывая потенциальный ущерб использования даже одной из таких неверно возвращённых сессий.

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

Продолжаем работу

Несмотря на устранение непосредственной угрозы, мы объединили усилия с мейнтейнером Unicorn, чтобы поднять изменения вверх по потоку и чтобы новые запросы выделяли собственные хэши среды. Если Unicorn будет использовать новые хэши для каждой среды, то это устранить возможность того, что один запрос ошибочно завладеет объектом, который может повлиять на следующий запрос. Это дополнительная защита, позволяющая предотвратить превращение подобных багов потокобезопасности в уязвимости защиты для других пользователей Unicorn. Хотим искренне поблагодарить мейнтейнеров Unicorn за сотрудничество и обсуждение данной проблемы.

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

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

Подведём итог

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

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

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