30 сентября вышел Windows Server 2016. К сожалению, вместе с положительными новшествами пришли и отрицательные. В Windows Server успешно перенесена ошибка из Windows 10 Anniversary Update, вызывающая падение удалённого сервера при обращении из него к локальному пути \\tsclient через FAR Manager.
С самого первого проявления данной проблемы я пытался обратить на это внимание фирмы Microsoft, но безуспешно. Решения нет до сих пор.
Проблема
В процессе работы мне часто приходится обращаться к удалённым компьютерам через Remote Desktop. Иногда приходится копировать файлы туда/обратно; при этом бывает весьма полезна возможность обратиться к дискам моего компьютера из клиента RDP по пути вида \\tsclient\d. Также нужно упомянуть, что привык пользоваться FAR Manager.
После обновления Windows Anniversary Update, в котором, как я надеялся, компания Microsoft исправит ряд своих ошибок, произошло обратное. При обращении к пути \\tsclient\d через FAR удалённая машина стала падать в синий экран. Конкретно виновным оказался драйвер rdbss.sys.
Проблема повторялась на раз-два-три, и дальнейшие тесты прекрасно проходили на виртуальных машинах с поставленной «с нуля» операционной системой. Виновник был чётко виден при просмотре дампа ядра.
BugCheck 27, {fcb0027c, ffffd5073f279eb8, ffffd5073f279af0, 0} Page c920 not present in the dump file. Type ".hh dbgerr004" for details Probably caused by : rdbss.sys ( rdbss! ?? ::FNODOBFM::`string'+1f09 ) nt!KeBugCheckEx rdbss! ?? ::FNODOBFM::`string'+0x1f09 (в реальности RxSelectAndSwitchPagingFileObject) rdbss!RxCommonClose+0x126 rdbss!RxFsdCommonDispatch+0x55b rdbss!RxFsdDispatch+0x86 rdpdr!DrPeekDispatch+0x203 mup!MupStateMachine+0x1dc mup!MupClose+0x8c FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x1a6 FLTMGR!FltpDispatch+0xb6 nt!IopDeleteFile+0x12d nt!ObpRemoveObjectRoutine+0x78 nt!ObfDereferenceObjectWithTag+0xc6 nt!ObCloseHandleTableEntry+0x28f nt!NtClose+0xcb nt!KiSystemServiceCopyEnd+0x13 0x00007ffa`8c925034
Переписка
Что же, подумал я, обратимся в компанию Microsoft. Поскольку форм отправки сообщений по подобным поводам я не нашёл (а заводить платный support request как-то не хотелось), была создана тема в technet forum. В сообщении я описал последовательность воспроизведения проблемы и приложил анализ дампа Windows от WinDBG.
В результате получил ответ от модератора:
По данным вашего анализа, проблема связана с «rdbss.sys». Это драйвер подсистемы буферизации перенаправленного диска. Поскольку проблема наблюдается на любой машине, я подозреваю, драйвер несовместим с функционалом Windows 10 RDP. Вам лучше подтвердить это у разработчика данного программного обеспечения.
Попытка указать, что разработчиком модуля rdbss.sys в составе Windows 10 является компания Microsoft, не привели к успеху. «Обращайтесь к компании-разработчику; у меня нет возможности это проверять», пишет модератор, сотрудник Microsoft.
Здесь я подумал, что проблема повторяется и для непривилегированного пользователя (действительно), и решил написать в Microsoft Security Report. К отправке подобного сообщения Microsoft относится серьёзно — по электронной почте нужно отправить зашифрованное письмо (S-MIME или OpenPGP с ключом Microsoft), на которое дадут ответ в течении суток.
Действительно, ответ дали:
Видимо, эта проблема FAR Manager, а не Windows 10. Однако это нельзя считать проблемой безопасности, поскольку вы уже имеете доступ к системе и возможность выполнять код на машине.
На вопрос, нормально ли, если непривилегированный пользователь может вызвать BSOD, ответа не было.
Когда появились релизные сборки Window Server 2016, в которой повторилась данная проблема, я отправил ещё одно письмо, обращающее внимание на недопустимость подобного для серверной платформы. Ответ был аналогичным:
Спасибо за дополнительную информацию. К сожалению, это всё ещё похоже на проблему в FAR Manager. Также это могло бы являться DOS-атакой локально аутентифицированного пользователя, но мы не находим это достаточным для обеспечения поддержки в рамках задач безопасности.
Анализ
Ради интереса я посмотрел, проявляется ли эта проблема в других версиях Windows – оказывается, нет. Ни в Windows 10 1511, ни в Windows Server 2016 TP5 она не наблюдалась.
Краткий обзор кода в WinDBG выявил весьма интересную вещь. Функция RxSelectAndSwitchPagingFileObject, которая, собственно, и вызывала Bugcheck 0x27, не сильно изменилась по сравнению с Windows 10 1511. Но в предыдущей версии при обнаружении ошибок они просто игнорировалась, а в новой был явно добавлен вызов KeBugCheckEx. Видимо, разработчики никак не могли исправить какие-то свои баги и решили работать «по бразильской системе» — если что, то система просто упадёт, и тогда удастся найти причины каких-то внутренних (возможно, и не фатальных) ошибок.
Однако в реальности получается странная ситуация — пользователи находят данную ошибку и описывают последовательность её воспроизведения, а техническая поддержка стоит барьером — «это не наша проблема». До разработчиков, подозреваю, информация так и не доходит.
В Windows Server 2016 TP5, кстати, этой функции вообще не было. Однако в релизной версии она появилась и абсолютно также вызывает синий экран, как и в Windows 10 Anniversary. Стоит отметить, что с выхода Windows Anniversary Update было несколько обновлений модуля rdbss.sys, но данную проблему они не решили.
Со стороны FAR Manager ситуация такова, что он активно использует Native API, и для операций с каталогами использует не классические функции модуля kernel32 (FindFirstFile/FindNextFile), а функции модуля ntdll (NtQueryDirectoryFile). Возможно, здесь и получается какая-то неожиданная комбинация параметров/вызовов, которую разработчики rdbss.sys не учли (система падает на NtClose, когда идёт очистка открытого объекта файла).
Надеюсь, данная статья предупредит системных администраторов о новой напасти и позволит избежать неожиданных падений удалённых серверов. Также лелею жалкую надежду, что представители Microsoft, присутствующие на Harbahabr, донесут необходимую информацию до разработчиков rdbss.sys через стену «технической поддержки».
ссылка на оригинал статьи https://habrahabr.ru/post/314882/
Добавить комментарий