waqur: (Default)
Интересный ресурс по отслеживанию онлайн-активности российской пропаганды в Твиттере — хэштэги, ключевые слова, домены и URLы, раскруткой которых они заняты в настоящий момент:

http://dashboard.securingdemocracy.org/
waqur: (Default)
Раньше было так: либо смартфон имеет поддержку CDMA, либо под него есть прошивки уровня LineageOS/CyanogenMod.

Мотивация для этого взаимного исключения была примерно такова: если в смартфоне есть поддержка стандарта связи CDMA, значит это чистокровный китаец (не международная версия), с соответствующей вилкой на зарядном устройстве, с инструкцией на китайском языке и т.д. Соответственно на международном рынке эта модель не продаётся, её нет на региональных сайтах вендора и под неё вендор не считает нужным публиковать исходники ядра (в Китае пипл и так схавает). Пример: HTC 609d. Такой телефон можно купить в местных магазинах или в ЦОА Интертелекома, но локализация будет любительской, а over-the-air обновления работать не будут.

Если же мы хотим поставить на телефон толковую прошивку уровня LineageOS/CyanogenMod (с функцией Privacy Guard, без встроенного vendor spyware, с нормальной локализацией, с нормально работающими обновлениями, с периодом поддержки 5+ лет и т.д.), тогда следует учитывать, что создать такую прошивку невозможно без наличия исходных кодов для всех драйверов встроенных в телефон устройств, а значит — эта модель должна продаваться на международном рынке, а значит с поддержкой CDMA в таком телефоне всё будет плохо.

Недавно наконец-то появились телефоны (Xiaomi), которые сочетают в себе эти два очень полезных свойства (поддержку CDMA и открытые исходники ядра). Не все модели Xiaomi открыты, но по одному такому устройству в каждом ценовом классе есть. Ну а вопрос с CDMA решается так: Xiaomi для каждой модели своих телефонов выпускает по две версии — международную и китайскую. Они отличаются только сигнальным сопроцессором (который всегда поддерживает GSM/UMTS/LTE, но не всегда CDMA/EVDO), а прикладной процессор и его прошивка — едины.

not-a-bug

2017-07-02 04:41 pm
waqur: (Default)
systemd при разборе конфиг-файлов для сервисов, которые должны стартовать от имени пользователя с пониженным уровнем привилегий, внезапно воспринимает любое имя пользователя, начинающееся с цифры, как "root". Таким образом, сервис тихонько стартует с максимальными правами в системе, и если окажется удалённо взломанным через remote code execution, то вы узнаете об этом лишь постфактум, когда уже будет "поздно пить Боржоми".

Изначальный замысел авторов systemd был в том, чтобы в этом контексте допускать UIDы наряду с именами пользователей. Замысел неправильный — стандарт POSIX не запрещает имена пользователей, начинающиеся с цифры, в том числе — состоящие из одних лишь цифр (IEEE Std 1003.1-2001, пункт 3.426). Например, можно создать пользователя с именем 1234 и UIDом 4321.

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

Пока шла дискуссия о том, один баг это или два (первый — необходимость выдачи внятного сообщения об ошибке вместо тихой элевации до прав рута, второй — необходимость поддержки имён пользователей, начинающихся с цифры), внезапно появился Поттеринг и закрыл этот баг как not-a-bug. Лолшто?
https://github.com/systemd/systemd/issues/6237

systemd is a symptom of the memetic cancer that has probably irredeemably destroyed UNIX in the Linux ecosystem — травят FreeBSD'шники:
https://twitter.com/matthewjweaver/status/881307929349160960

Ещё: https://twitter.com/Xof/status/881305418080804864
https://twitter.com/SwiftOnSecurity/status/881936783482777600
waqur: (Default)
Игру Dishonored 2 таки взломали, красавчики :)

Защищена с помощью Denuvo, выпущена ещё в ноябре прошлого года, Game of the Year в нескольких номинациях, один из лидеров продаж в Steam, дорогая ($60), до сих пор взломать никому не удавалось. Как и многие другие игры последних лет, защищённые с помощью Denuvo, это был крепкий орешек, ведь в основе технологии защиты Denuvo лежит VMProtect.

Однако новая группа под названием SteamPunks (да-да, это дебютный их релиз на крэкерской сцене) всех сделала с особым цинизмом — выпустила не просто патч или лоадер, а целый генератор ключей. :D Никогда не думал, что Dishonored 2 взломают таким способом — скорее, были предположения, что кто-то выпустит хитрый лоадер режима ядра, который захватывает хост в гипервизор и виртуализирует инструкцию CPUID вместе с перехватом доступа к серийному номеру жёсткого диска и MAC-адресу сетевой карты, которые дают вклад в HWID. Ну а далее все будут сидеть на едином ключе, как в старые добрые времена Windows 98 :)

Но кейген? "SteamPunks absolutely delivered" — пишут англоязычные сайты, и они чертовски правы. Неужто Стимпанки подобрали приватную часть мастер-ключа? Наверное, это как-то связано с дефектами генератора псевдослучайных чисел, которым был сгенерирован мастер-ключ. Мало энтропии в засевочном числе или что-то подобное. Более 15 назад похожая история была с ASProtect (см. стр 89/83 этой книги).

Бывает ещё такой случай, когда крэк основан на связке патча и кейгена. Это когда программа использует асимметричную криптографию для проверки лицензий, но её авторы не потрудились обеспечить защиту от пропатчивания публичного ключа. Соответственно самым простым решением для крэкеров является выпуск новой пары ключей и замена публичного ключа в программе патчем для EXEшника, а на основе приватного — изготовление кейгена. Явно не наш случай, защита от наглого пропатчивания публичного ключа есть. Хотя бывают вариации этого подхода, когда вместо патча применяется лоадер с WriteProcessMemory; или код для динамического пропатчивания публичного ключа в секции данных EXEшника внедряется в какую-то второстепенную DLLку в комплекте с игрой.

Во всём этом невозможно так сходу разобраться, потому что к радости разработчиков Dishonored 2 и крэкеров из конкурирующих групп, кейген защищён от реверс-инжиниринга. VMProtect'ом, разумеется. Чем же ещё. LOL.
waqur: (Default)
Как известно, криптовалюта Bitcoin в её текущей реализации имеет проблему: малый размер блока. По этой причине некоторые транзакции выполняются слишком долго или требуют черезчур высокой комиссии.

Предлагаемых решения два — Bitcoin Unlimited (просто увеличить размер блока) и SegWit (преобразовать одноранговую p2p-сеть в иерархическую). Оба потребуют изменений в исходном коде ПО Bitcoin, и, в принципе, оба являются ответвлениями (форками) от классического Bitcoin.

Скажу прямо — SegWit мне откровенно не нравится. Внедрение этой технологии может привести к тому, что в сети появятся более привилегированные узлы, которые будут осуществлять цензуру — эти транзакции мы пропускаем, эти не пропускаем. Критерии могут быть произвольные, например — идентификация клиентов по паспорту, по кредитной карте или по банковскому счёту; установка специфического клиентского ПО (например с рекламой или шпионскими функциями); повышенные комиссии; какие-то залоги или страховые фонды или прочие глупости. Причём эти глупости могут меняться на ходу по желанию весьма ограниченного круга лиц. Какая ирония, в Bitcoin будет свой центробанк! Против чего боролись, на то и напоролись.

Я исхожу из того, что кто бы не пытался контролировать Bitcoin (крупный частный бизнес или гэбня), контроль в Bitcoin'е — это плохо. Bitcoin — это вообще-то история не про контроль. Кто нуждается в том, чтобы его контролировали, у кого есть такая собачья тоска по палке — всегда могут просто открыть счёт в банке.

Пахнет это всё примерно как телеметрия в Windows 10, или как цензура приложений в AppStore, или преобразование децентрализованной p2p-архитектуры Skype в централизованную клиент-серверную, или как политика реальных имён в Facebook. Пахнет, скажем прямо, Родиной.


Как бы там ни было — дата ответвления SegWit UASF (BIP-148) недавно была назначена его сторонниками на 1 августа этого года. А именно: софтфорк SegWit (изначально предполагавший, что самые консервативые пользователи Bitcoin'а без SegWit и с малым размером блока так и останутся на более высоком уровне двухуровневой иерархии, и продолжат самостоятельно подтверждать свои и чужие транзации) как бы незаметно (ловкость рук и никакого мошенничества) превратился в UASF (User-Activated Soft Fork), который таких консерваторов отсекает от блокчейна. Как по мне, UASF = hardfork, что технологически ничуть не лучше конкурирующего хардфорка Unlimited.

https://bitnovosti.com/2017/06/11/uasf-and-skin-game/

Итак, да начнётся битва. Сколько ж можно тянуть, ё-моё! Учитывая нынешнюю капитализацию Bitcoin'а, Bitcoin SegWit vs Bitcoin Unlimited будет гораздо более жёстким противостоянием, чем Ethereum vs Ethereum Classic — есть за что побороться. Вопреки ожиданиям некоторых полезных идиотов (или намеренной дезинформации со стороны заинтересованных лиц), разветвления биткоина на несколько криптовалют не избежать. Как и курсовых потерь. Но я подойду к разветвлению с нулевым балансом.
waqur: (Default)
ArsTechnica пишет об интересном случае маскировки C&C (command and control) сервера вредоносного ПО (такого как вирусы-вымогатели). Обычно для таких вещей хакеры используют чужие взломанные серверы, и в конечном итоге попадаются, но в этот раз всё интереснее.

Сервер подключён к несимметричному спутниковому интернету (дешёвая односторонняя связь, только downlink) и прослушивает одновременно все частоты диапазона KuBand с помощью PCI-E платы со специальными драйверами для Linux. Такой себе односторонний promiscuous mode на спутнике. Раньше это называлось "спутниковая рыбалка". Провайдер спутникового интернета отображает на этот линк все IP-адреса из выделенного ему диапазона (и чтоб было совсем дёшево, не применяет VPN). Клиентская часть вредоноса шлёт зашифрованный пакет с полезной нагрузкой, предназначенный C&C серверу, на случайный IP-адрес из диапазона, и, насколько я понимаю, на случайный UDP-порт. Далее пакет (например содержащий приватную часть RSA-ключа экземпляра вируса-шифровальщика, зашифрованную публичным RSA-ключом C&C-сервера) вылавливается C&C-сервером из общего потока в порядке рыбалки. Обратная связь не требуется.

https://arstechnica.com/security/2015/09/how-highly-advanced-hackers-abused-satellites-to-stay-under-the-radar/

Где физически находится C&C-сервер в пределах покрытия спутника (круга радиусом 1000 километров) — правоохранители не могут выяснить до сих пор. Очевидно, не нужно иметь назначенный IP-адрес из этого диапазона (или даже быть клиентом оператора спутникового интернета), чтобы исполнять такие вещи.

Flatpak

2017-06-03 10:35 am
waqur: (Default)
Flatpak — платформа дистрибуции настольных приложений для Linux.

Фичи:
* установка приложений в обход основного репозитория дистрибутива
* единая платформа для всех дистрибутивов
* приложение распространяется с зависимыми динамическими библиотеками, т.е. не зависит от динамических библиотек основной системы (которые могут быть несовместимы с приложением, или внезапно стать таковыми в результате обновления системы)
* можно устанавливать одновременно несколько версий одного приложения
* платформа использует контейнерные технологии ядра Linux для создания песочниц приложений (bind mounts, namespaces, seccomp)

http://flatpak.org/
waqur: (Default)
Весь мой UNIX experience делится на две части: до того, как я впервые установил терминальный мультиплексор tmux, и после этого.

Первоначальная мотивация к инсталляции программы заключается в том, чтобы обрыв ssh-подключений к серверу не приводил к закрытию подключённых к виртуальному терминалу процессов в результате доставки им сигнала SIGHUP. Затем к хорошим вещам привыкаешь быстро: можно оставить на ночь на сервере любую долго выполняющуюся задачу (инсталляцию, компиляцию, обновление, ...); можно экономить мобильный трафик и время, не передавая ssh-клиенту весь тот мусор, который выдаётся на экран во время выполнения таких задач; можно держать постоянно открытые окна для мониторинга состояния сервера (top, iftop); можно легко и удобно менять клиентские устройства, не прерывая серверный контекст; можно даже видеть один и тот же экран и суммировать клавиатурный ввод при подключении с нескольких устройств.

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

~/.tmux.conf:
set -g status-fg white
set -g status-bg red
set -g prefix C-a
unbind C-b
bind C-a send-prefix
set -g base-index 1


~/.bash_profile:
if [ $TERM = "xterm" ]; then
 ( (tmux has-session -t remote && tmux attach-session -t remote) || \
   (tmux new-session -s remote) ) && exit 0
 echo "tmux failed to start"
fi
if [ $TERM = "screen" ]; then
 clear
 cat /etc/motd
fi


А далее запомнить только три комбинации:
"Ctrl+A цифра" переключает окна
"Ctrl+A C" создаёт новое окно
"Ctrl+A D" отсоединяет от сервера (без потери контекста на сервере)

Большего мне не понадобилось и через пять лет после начала использования программы. Может, я использую 1% возможностей tmux, но этого вполне достаточно, чтобы повысить удобство удалённого администрирования в разы.
waqur: (Default)
По-моему, это был лучший перформанс на Евровидении этого года (увы, вне конкурса):

waqur: (Default)
На днях в прошивке Intel Management Engine нашёлся баг, который позволяет обойти аутентификацию в их корпоративных решениях для удалённого управления серверами и рабочими станциями. Короче говоря, можно удалённо рулить сервером или ноутбуком без предоставления пароля/ключа, если в публичный интернет открыты TCP-порты 16992/16993.

Intel ME известен корпоративным пользователям под большим набором маркетинговых имён (AMT, ISM, SBT, IPMI, vPro) и представляет собой выделенный 32-битный сопроцессор, позволяющий, к примеру, удалённо войти в BIOS или удалённо пробросить ISO-образ с последующей переустановкой операционной системы. С аппаратной точки зрения, Intel ME является посредником между сетевым интерфейсом и процессором, и к тому же имеет прямой доступ ко всей оперативной памяти системы: https://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub

Подозрения о том, что Intel ME — это бэкдор для NSA и других аналогичных организаций, существуют давно. Для каждого из этих подозрений существует правдоподобное оправдание от Intel, и теория заговора.

1) Intel ME присутствует даже в чипсетах сугубо клиентских материнских плат и ноутбуков, и даже там он постоянно включён, и отключить его никак нельзя (в системе с неактивным Intel ME сработает watchdog timer чипсета через 30 минут после загрузки, или около того). Plausible deniability от Intel сводится к технологии Intel Anti-Theft, и к управлению вентиляторами. Conspiracy theory сводится к тому, что даже на клиентских системах есть пароли и AES-ключи, которые можно собирать из оперативной памяти. Или от процессора, который выполняет AES-NI инструкции, и, в принципе, знает ключи.

2) Встроенное программное обеспечение для Intel ME хранится в флеш-памяти в сжатом и зашифрованном виде, а выделенный для Intel ME регион в ОЗУ — прозрачно шифруется самим сопроцессором (хотя и программно недоступен для центрального процессора), так что даже охлаждение планок памяти жидким азотом и чтение на другой системе не позволит заглянуть внутрь. Plausible deniability от Intel сводится к наличию DRM-технологий (Protected Audio/Video Path) на этой платформе, а также к тому, что она может быть содержать программную реализацию TPM (Trusted Platform Module). Conspiracy theory сводится к тому, что код, собирающий всякие интересные артефакты из ОЗУ, должен быть защищён от любопытных глаз исследователей.

3) Intel ME имеет доступ к фреймбуферу (видит и может менять то, что отображается пользователю на экране). Для этой функции ему порой нужна поддержка со стороны ОС (если видеокарта не встроенная, а дискретная). Plausible deniability от Intel: Active Management Technology (удалённое управление), а также Protected Transaction Display (ввод PIN-кода для интернет-банка мышиными кликами по рандомизированной экранной PIN-клавиатуре, так чтобы хостовый CPU и вирусы, выполняющиеся на нём, не знали цифр, которые отображаются на экране). Также нужно для DRM (показывать дешифрованное видео прямо на экран, в обход CPU). Conspiracy theory: подглядывание за пользователем.

4) Intel ME и сетевой контроллер остаются включёнными даже тогда, когда основной процессор выключен (режим питания soft-off). Plausible deniability от Intel сводится к технологии Wake-on-LAN. Conspiracy theory сводится к тому, что пока компьютер "как бы выключен", этот сопроцессор может спокойно передавать "куда следует" секретики, собранные за день.

5) Intel ME включается в разрыв между сетевым контроллером и процессором. Plausible deniability от Intel сводится к технологии System Defense (низкоуровневой неотключаемый файерволл для дебилов, которые снесут или отключат файерволл в ОС и нахватаются вирусов), а также всё к тому же AMT и vPro. Также существует технология Intel EEE (Energy Efficient Ethernet), которая позволяет, например, открыть слушающий TCP сокет и отправить CPU спать до появления первого клиентского подключения. Conspiracy theory сводится к тому, что таким способом собранные данные можно сливать не "в наглую" (например, передавая трафик на неизвестный IP-адрес, который кто-то запишет wireshark'ом или tcpdump'ом и устроит скандал) а похитрее (например, в виде колебаний задержек при отправке исходящих пакетов, которые можно измерить на оборудовании вашего интернет-провайдера). При этом, можно предположить, что колебания задержек входящих пакетов на исходящих TCP-сессиях могут быть использованы для встречной передачи команд контроллеру Intel ME.

Подытожим:

1) Я не до такой степени параноик, чтобы менять встроенную прошивку на coreboot, рискуя превратить материнскую плату в бесполезный кусок текстолита; к тому же я не уверен, что это как-то поможет. Однако я не пользуюсь встроенными сетевыми контроллерами от Intel с 2015 года, чего и вам советую. Выбирайте дискретную сетевую карту поэкзотичнее, прошивка Intel ME — это примерно 2 мегабайта, а ведь там ещё должен поместиться весь этот SSL, VNC-сервер, DRM, файерволл и предполагаемый шпионский хлам (а также урезанная версия Java). Да и попытка пообщаться с сетевой картой требует перепрограммирования регистров её контроллера и контроллера DMA, что не останется незамеченным для CPU. Ну разве когда CPU в режиме soft-off, но тогда и сетевая карта в soft-off.

2) Сам факт нахождения первых уязвимостей в Intel ME позволяет предположить, что кто-то всерьёз заинтересовался этим вопросом, возможно расшифровал прошивку Intel ME. Способы есть. Вполне естественно, что люди интересуются, ведь если кто-то заложил в платформу такие вкусняшки — не пропадать же им втуне. Да и в конечном итоге неважно, написан ли соответствующий софт или нет; важно лишь, что железо позволяет.

Обсуждение на Hacker News:
https://news.ycombinator.com/item?id=14241241
waqur: (Default)




По-моему, они прекрасны. В них есть что-то от Evanescence, или Nightwish, в то же время — с этническими мотивами.

Поразительно, что им приходится продюсировать себя самим. Это неформат на радио? А что формат? "Время и стекло"?
waqur: (Default)
В последнее время всё чаще попадаются сайты, свёрстанные с использованием специальных шрифтов для Mac OS. Не до конца понимаю, чем альтернативно ориентированных дизайнеров не устраивают стандартные шрифты в их операционной системе (по слухам, на маках вроде сломан TrueType hinting, из-за чего системный шрифт выглядит в браузере как будто набранный полужирным стилем, но только если мелкий кегль и только на крупнозернистых экранах).

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



В идеале, было бы установить расширение для Firefox, которое подоменно блокирует загрузку и использование сайтом любых шрифтов, кроме системных. Т.е. делает с несистемными шрифтами то же самое, что делает с javascript'ом аддон YesScript. Никто не знает такого?
waqur: (Default)
Как проникнуть в защищённую сеть организации, которая изолирована от интернета?

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

Но вот незадача: в последних версиях Windows по умолчанию отключено автоматическое выполнение файла autorun.inf с флешек, да и с чего вы взяли, что у них там в конторе вообще Windows?

Те, кто имел дело с самоделкинской платой Arduino Leonardo, знают, что она умеет эмулировать любое USB-устройство. Например, флешку. Или клавиатуру (разумеется, без клавиш — такую, которая сразу после подачи питания начинает что-то виртуально "набирать", например WinKey+R, "cmd", Enter, "format C:", Enter, Y, Enter). Или USB-хаб, куда виртуально подключены флешка и клавиатура. Так что подавление выполнения файла autorun.inf не поможет.

Но как же быть с Mac OS и Linux? Ну, например, можно попытаться включить Num Lock через PowerShell (о чём винда уведомит клавиатуру), и если не получилось — то это, наверное, не Windows. А если не получилось через setleds(1) — тогда это, наверное, не Linux.

https://www.elie.net/blog/security/what-are-malicious-usb-keys-and-how-to-create-a-realistic-one
waqur: (Default)
Программа для генерации больших растровых изображений, локально подобных малому исходному изображению:

https://github.com/mxgmn/WaveFunctionCollapse

Ключевые идеи:
– распределение паттернов в квадратных блоках исходного изображения совпадает с распределением паттернов в таких же квадратных блоках результирующего изображения (достаточно большого размера)
– такие распределения становятся гораздо более точными, если учесть инвариантность самых маленьких плиток относительно вращений и отражений (диэдральная группа D4)
– алгоритм постоянно стремится минимизировать Шэнноновскую энтропию (авторы называют это "коллапс волновой функции"
waqur: (Default)
Из личной практики, может ещё кому-то будет полезно :)

Если ZeroNet установить в папку с пробелом в имени, тогда он, зараза, часть сайтов открывает (в основном простые статические), а часть — нет, причём зависает на них в режиме вечной синхронизации (без выдачи каких-либо осмысленных сообщений об ошибках). Просто перенести его в папку без пробелов недостаточно, надо всё начинать с чистого листа.

https://zeronet.io/
https://news.ycombinator.com/item?id=14041077
waqur: (Default)
Поначалу подход к декомпиляции ассемблерного листинга в сишный код сводился к двум основным идеям:
– построение графа потока управления, а далее применение pattern matching в непрерывных блоках кода (так работает плагин HexRays к дизассемблеру IDA, и работает порой откровенно плохо, куда-то теряя существенные куски кода — наверное, когда не может подобрать подходящие паттерны)
– попытка "подобрать" исходный код, из которого бы порождался наперёд заданный бинарный код, путём вызова компилятора и перенаправления дальнейшего подбора в в нужную сторону, в зависимости от сопоставления выхлопа компилятора и заранее заданного бинарного кода (теоретический подход, рассматриваемый в нескольких диссерах по декомпиляции, на практике работает плохо из-за того, что во-первых, нужно точно угадать версию компилятора; во-вторых, из-за того, что такие блуждания неустойчивы с точки зрения обратной связи, и могут быстро зайти "не в те дебри"; в-третьих, компиляторы имеют тенденцию к переименованию регистров и разным другим перестановкам даже при множественной инвокации на одном и том же исходном коде — так что простым сравнением бинарного выхлопа не обойтись).

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

Ну а промежуточный код LLVM-IR — это уже практически код на C. Остаётся только сформировать деревья выражений там, где были однократно используемые временные переменные.

Учитывая недавние теоретические успехи в реконструкции if-else-for-while-структур из графа потока управления, позволяющие всегда обойтись без goto, результаты работы FCD выглядят весьма неплохо, даже на фоне коммерческого HexRays.
waqur: (Default)
Одна вещь, которую я никогда не понимал в контексте теории борьбы с эксплоитами, основанными на stack corruption в коде, написанном на C/C++ и других небезопасных языках — это почему не используется расщепление стека надвое:

1. Доверенный стек: там обязательно должны быть адреса возврата из функций, параметры вызываемых функций; а также там могут быть локальные переменные, на которые не берётся указатель.

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

Не хватает регистров? Но мы ведь уже давно пишем не для 8-битных микроконтроллеров: в процессорной архитектуре x86-64 вдвое больше регистров, чем в x86, а ещё они вдвое шире. "Второй RSP" отлично поместился бы в каком-нибудь R13. Доверенный стек может быть исполняемым, недоверенный — всегда нет. Это бы решило проблемы несовместимости DEP (Data Execution Prevention) с GCC Nested Functions и всякими прочими closures из других языков. Очевидно, что глобальная оптимизация (которая называется в разных компиляторах по-разному: LTO, LTCG, IPO) могла бы существенно сократить количество случаев, когда нужен недоверенный стек.

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

Вместо этого индустрия вот уже лет десять или двадцать полагается на благие пожелания в вольной художественной форме, такие как MISRA C, или городит какие-то ASLR (которые не всегда работают), W^X, DEP, разные попытки противодействия ROP (например G-free и CFG), принудительные автоматические обновления, Rust и прочие глупости, которые проблему в общем-то и не решают, а так, царапают по поверхности.

SAM 1.3

2017-02-01 09:21 pm
waqur: (Default)
В Windows 10, начиная с Anniversary Update (10.1608), фирма Microsoft для чего-то поменяла способ шифрования хэшей в хайвах SAM.

Когда-то очень давно (во времена NT 3.51 и NT 4.0), пароли пользователей просто хэшировались алгоритмами MD4 и LMHash и в таком виде писались в хайв реестра под названием SAM.

В Service Pack 3 к NT 4.0 появилось нововведение под названием SYSKEY. Теперь хэши не просто хранились в SAM, а ещё и шифровались ключом под названием PEK. PEK генерировался случайно при установке Windows и тоже сохранялся в SAM-хайве, но не в открытом виде, а в зашифрованном. Шифрование PEK'а и хэшей происходило с помощью криптоалгоритма RC4, проверка валидности PEK'а делалась с помощью комбинации RC4 и MD5. Для расшифровки PEK нужен был ключик из хайва SYSTEM. Его в открытых источниках обычно называют SYSKEY, а Microsoft его именует Boot Key. Он хранится немного витиеватым способом (по частям в именах классов разных ключей реестра, связанных с подсистемой LSA), но извлекается без особых проблем. В общем, security through obscurity.

RC4-шифрование хэшей и PEK'ов по технологии SYSKEY просуществовало в неизменном виде во всех последующих версиях Windows (2000, XP, 2003 Server, Vista, 7, 2008 Server, 8, 8.1, 2012 Server, 10 RTM, 2016 Server), аж пока в Windows 10 Anniversary Update не произошли изменения.

Что бы вы думали? Они внедрили PBKDF2 вместо MD4, чтобы затруднить подбор паролей полным перебором на видеокартах? Перенесли вычисление Boot Key в TPM? В безопасный анклав Intel SGX? В Yubikey? Реализовали какую-то безумную систему проверки пароля с использованием zero knowledge proof, основанную на новейших достижениях криптографической мысли, таких как zk-SNARKs?

Фиг там, это же Microsoft. Они просто заменили RC4 на AES, а MD5 на SHA256 в своей security-through-obscurity схеме шифрования PEK'ов и хэшей (ну и попутно подняли версию формата данных 1.2 с 1.3, что сломало работу всяких утилиток для сброса пароля в винде, тысячи их). Разумеется, MD4 при всём при этом остался вечно живой, как Ленин.

Выглядит как формальная подготовка к какой-то правительственной сертификации. Убрать с начальственных глаз имена криптоалгоритмов и хэш-алгоритмов, к которым можно придолбаться с чисто формальной точки зрения. Ну спасибо, конечно, про RC4 мы давно догадывались, хотя в данном конкретном случае случае (SYSKEY — PEK — хэши паролей из SAM) что AES, что RC4, что XOR-наложение гаммы из линейного конгруэнтного ГПСЧ обеспечивают абсолютно идентичный уровень безопасности.

August 2017

S M T W T F S
  1 2345
6789101112
13141516171819
20212223242526
2728293031  

Синдикация

RSS Atom

Автор стиля

Развернуть

No cut tags
Page generated 2017-08-17 07:35 am
Powered by Dreamwidth Studios