Хакер #305. Многошаговые SQL-инъекции
Стали известны первые подробности о проблеме TLBleed, из-за которой разработчики OpenBSD решили отказаться от поддержки технологии Hyper-Threading в процессорах Intel. Напомню, что подобный доклад об этой проблеме будет представлен в августе 2018 года, на конференции Black Hat. А пока с обнаружившими проблему специалистами пообщались журналисты издания The Register.
Авторами доклада выступают исследователи из Амстердамского свободного университета. Они рассказывают, что обнаружили способ обхода защиты буфера ассоциативной трансляции (Translation lookaside buffer, TLB). Баг позволяет извлекать криптографические ключи и другие важные данные из других запущенных программ, причем коэффициент успешности атаки равняется минимум 98%. Точный результат зависит от используемого процессора: процент успешных атак при использовании Intel Skylake Core i7-6700K равен 99,8%, при использовании серверных процессоров Intel Broadwell Xeon E5-2620 v4 — 98,2%, а процессоры Coffeelake дают 98,8%.
Исследователи рассказали, что их атака позволяет извлекать из сторонних программ 256-битные криптографические ключи, используемые для подписания данных, во время выполнения операции подписи с помощью имплементации libgcrypt Curve 25519 EdDSA. На подбор одного ключа (с использованием машинного обучения и брутфорса) в среднем требуется лишь 17 секунд.
Нужно отметить, что проблема TLBleed не связана со спекулятивным исполнением команд, то есть не имеет отношения к нашумевшим процессорным уязвимостям Meltdown и Spectre. В данном случае брешь связана со слабыми местами технологии Hyper-Threading и тем, как процессоры кэшируют данные.
Как нетрудно понять из названия, TLBleed атакует буфер ассоциативной трансляции (Translation lookaside buffer, TLB), то есть специализированный кэш процессора, используемый для ускорения трансляции адреса виртуальной памяти в адрес физической памяти. От ранее известных side-channel атак на кэш TLBleed отличает тот факт, что уже существующая защита от side-channel атак на кэш памяти не гарантирует защиты от слежки за TLB.
По сути, для работы TLBleed эксплуатирует собственную имплементацию Intel для идеи одновременной многопоточности (Simultaneous Multi-Threading, SMT), также известную под маркетинговым названием Hyper-Threading. После включения Hyper-Threading один физический процессор и одно физическое ядро определяются операционной системой как два отдельных процессора и два логических ядра. В итоге процессор может работать с несколькими потоками одновременно (как правило, их количество равно двум). При этом ресурсы и инфраструктура ядра остаются для потоков общими, включая и TLB.
За счет использования общих ресурсов, программы, запущенные на одном ядре, могут «шпионить» за потоками друг друга. То есть открывается возможность для исполнения так называемых атак по времени (timing attack), — разновидности side-channel атак, в ходе которой преступник пытается скомпрометировать систему с помощью анализа времени, затрачиваемого на исполнение тех или иных криптографических алгоритмов. Так, один поток может извлекать информацию из другого, следя за таймингом обращений к конкретным ресурсам и сравнивая эти данные с тем, как должно работать атакуемое приложение (основываясь на его исходных кодах). Искусственный интеллект, отслеживая изменения в TLB, помогает определить, когда целевая программа исполняет важные операции.
Обнаружившие проблему TLBleed эксперты пишут, что на деле все не так плохо, как может казаться. В частности, одним из условий осуществления такой атаки является наличие в системе уже работающей малвари или вредоносного пользователя. Кроме того, по данным специалистов, пока уязвимость не эксплуатируют какие-либо злоумышленники, и вряд ли станут, ведь существует множество боле простых способов извлечения информации с компьютеров и других устройств, тогда как эксплуатацию TLBleed нельзя назвать тривиальной задачей.
«Без паники, хотя атака очень крутая, TLBleed – это не новая Spectre», — заявил один из авторов исследования журналистам The Register.
Интересно, что инженеры компании Intel уже сообщили о том, что не собираются выпускать каких-либо специальных патчей для устранения TLBleed. В компании полагают, что существующих контрмер, направленных против side-channel атак, вполне достаточно для защиты от TLBleed, если разработчики будут писать код правильно. В результате проблеме даже не был присвоен собственный идентификатор CVE, и компания отказать выплачивать вознаграждение по программе bug bounty, когда отчет об уязвимости был направлен Intel через платформу HackerOne.
Исследователи из Амстердамского свободного университета сообщили представителям The Register, что они не согласны с такой точкой зрения. Они подчеркивают, что идеальный софт, написанный как решение, устойчивое перед любыми side-channel атаками, встречается крайне редко, и бороться с проблемой TLBleed с помощью хороших кодерских практик, это вряд ли хорошая идея.
