Но в размещении микроконтроллерной статьи НЛО автору отказало
Если работа по переводу уже проделана, может есть возможность выложить материал на другой площадке (https://telegra.ph/ или что для этого случая будет удобным), а тут в комментариях просто оставить ссылку?
Думаю, что не только я буду за это благодарен ;)
А то, что написанная ещё во времена Windows NT функция NtQuerySystemInformation(SystemHandleInformation,...) имела (и имеет) некоторый вполне ограниченный внутренний буфер. Я не нашел нигде точного указания его размера, но, очевидно, что он не был рассчитан на миллион дескрипторов. В итоге функция возвращает их «сколько может», а значит среди них может оказаться, а может и не оказаться искомый.
Мне кажется, что суть проблемы не в каком-то ограниченном внутреннем буфере. Если внимательно посмотреть на SYSTEM_HANDLE_TABLE_ENTRY_INFO, то можно обнаружить, что HandleValue имеет тип USHORT, который имеет размер всего 2-а байта (поле не может быть больше 0xFFFF).
Интересный подход, но все же интересно насколько инструкции LLVM IR одинаково легковесны относительно друг друга. Грубо говоря: 1000 инкрементов регистра процессора и 1000 обращений к оперативной памяти совсем не эквиваленты.
Изначально была идея взять указатель на функцию-член класса, преобразовать её к функции вида void (callback)(void ptr, void* param_ptr, uint32_t param); и вызывать передавая в качестве первого указателя указатель на объект.
На момент написания статьи (25.09.2018) 15 версия серии патчей находится в ветке linux-next, соответствует всем озвученным требованиям Линуса и готова к merge-window ядра 4.20 / 5.0.
При написании кода программист может чувствовать себя стесненным – ведь у него в распоряжении ограниченное количество ключевых слов, функций и библиотек.
Сужу по себе: обычно чего-то не хватает в языке/библиотеке, если использовал какой-то прием, недоступный на текущий момент. То есть стесненным начинаешь себя чувствовать, когда обладаешь навыками практического использования нескольких инструментов.
Однако, письменный текст дает полную свободу самовыражения, которой язык программирования обычно не допускает.
Интересно, а люди, свободно владеющие 2-3-4-… естественными языками не чувствуют подобного стесненния при необходимости писать на каком-то одном языке?
Плюс: есть еще и рамки издания, для которого пишется этот текст. Хотя это частично пересекается с рассмотренным вопросом целевой аудитории (написание текста для широкой аудитории ставит рамки уровня этой аудитории).
Проблема скорее всего в том, что встроенная команда mklink использует Win32-функцию CreateHardLink. Ее реализация открывает существующий файл с правом FILE_WRITE_ATTRIBUTES ( == 0x100 ) — декомпиляция файла версии 10.0.18204.1001:
Однако для вызова NtSetInformationFile с аргументом FileLinkInformation (то есть для создания hardlink'а нативными функциями) файл можно открыть вообще с любыми правами (=0), чем пользуется PoC (Hardlink.cpp@91):
Непонятно что это может поломать при штатной работе.
Я бы попробовал оставить права на запись только пользователю SYSTEM. Но нужно будет это откатывать после фикса, когда MS станет имперсонироваться перед операцией в этой директории.
Ну скорее использовали существующие наработки))
Если работа по переводу уже проделана, может есть возможность выложить материал на другой площадке (https://telegra.ph/ или что для этого случая будет удобным), а тут в комментариях просто оставить ссылку?
Думаю, что не только я буду за это благодарен ;)
В дополнение к сказанному в статье: интересный опыт перехода на новый стандарт (именно исключения из деструкторов) с использованием статического анализа (clang-tidy).
Мне кажется, что суть проблемы не в каком-то ограниченном внутреннем буфере. Если внимательно посмотреть на SYSTEM_HANDLE_TABLE_ENTRY_INFO, то можно обнаружить, что HandleValue имеет тип USHORT, который имеет размер всего 2-а байта (поле не может быть больше 0xFFFF).
А в новой структуре SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX это поле (HandleValue) уже имеет тип ULONG_PTR.
Windows Defender Application Guard?
Интересный подход, но все же интересно насколько инструкции LLVM IR одинаково легковесны относительно друг друга. Грубо говоря: 1000 инкрементов регистра процессора и 1000 обращений к оперативной памяти совсем не эквиваленты.
Маршрутизация не подходит?
Quake 2 это не DOS, да и в ролике про ДОС, вроде, ничего не упоминали. Какая-то странная солянка, может они сами не знают, что хотят сделать.
P.S. по поводу успеха classic — консолей: думаю там шильдик нинтендо на коробке обеспечил хороший процент продаж.
В C++ есть указатели на не статические функции классов/структур: https://ideone.com/XiIW9b
Но они не эквивалентны простому адресу начала метода (в примере это видно хотя бы по sizeof). Например так: https://itanium-cxx-abi.github.io/cxx-abi/abi.html#member-pointers
У вызовов методов может быть отдельное соглашение о передаче параметров — https://en.wikipedia.org/wiki/X86_calling_conventions#thiscall
Как STACKLEAK улучшает безопасность ядра Linux
Поздравляю с результатами! Это шаги в правильном направлении.
Даже звучит это как-то не продуктивно
Сужу по себе: обычно чего-то не хватает в языке/библиотеке, если использовал какой-то прием, недоступный на текущий момент. То есть стесненным начинаешь себя чувствовать, когда обладаешь навыками практического использования нескольких инструментов.
Интересно, а люди, свободно владеющие 2-3-4-… естественными языками не чувствуют подобного стесненния при необходимости писать на каком-то одном языке?
Плюс: есть еще и рамки издания, для которого пишется этот текст. Хотя это частично пересекается с рассмотренным вопросом целевой аудитории (написание текста для широкой аудитории ставит рамки уровня этой аудитории).
Патч выглядит грамотно. Используете их системой патчей?
Проблема скорее всего в том, что встроенная команда mklink использует Win32-функцию CreateHardLink. Ее реализация открывает существующий файл с правом FILE_WRITE_ATTRIBUTES ( == 0x100 ) — декомпиляция файла версии 10.0.18204.1001:
Однако для вызова NtSetInformationFile с аргументом FileLinkInformation (то есть для создания hardlink'а нативными функциями) файл можно открыть вообще с любыми правами (=0), чем пользуется PoC (Hardlink.cpp@91):
Запуск задачи никуда не убрали:
.
Печать XPS-принтером инициируется програмно (ALPC-TaskSched-LPE.cpp@120):
Да, админы могут повыситься до SYSTEM документированными средствами. Но если в нее пишет только сервис без имперсонации, то все остальные — враги :)
Непонятно что это может поломать при штатной работе.
Я бы попробовал оставить права на запись только пользователю SYSTEM. Но нужно будет это откатывать после фикса, когда MS станет имперсонироваться перед операцией в этой директории.