Смущает актуальность BigFix - файлы x64

Question

Смущает актуальность BigFix - файлы x64

Я использую BigFix в корпоративной среде и заметил, что недавний цикл исправлений Microsoft на 2016 год провалился на небольшой группе активов. Я смог обойти эту проблему, создавая нестандартные копии, используя измененную релевантность, однако релевантность, которую я должен был использовать, не всегда была согласованной, хотя большинство файлов были расположены в C:\Windows\Sytem32,

Например: MS16-031 - критерии, которые ищет моя платформа сканирования, основаны на номере версии для Ntdll.dll, Я создаю Custom Fixlet с релевантностью:

((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) < VersionNumberGoesHere

Это прекрасно работало, так как я создал анализ BigFix, который ранее искал Ntdll.dll используя актуальность:

if (exists x64 file "C:\Windows\System32\Ntdll.dll") then ((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) else "Does Not Exist"

Я был в состоянии подтвердить, что релевантность для Custom Fixlet была почти на месте с анализом. По некоторым причинам, это не зеркальное отображение двух, но это очень близко, и список Custom Fixlet содержит все машины, которые отмечены в результатах сканирования, поэтому я доволен этим.

Проблема возникает здесь: для некоторых файлов в C:\Windows\System32Я должен использовать совершенно другой синтаксис, чтобы получить правильную информацию о номере версии, которую я ищу, основываясь на результатах сканирования. То есть я могу использовать метод, перечисленный выше, но информация о версии, которую он предоставит, даже близко не соответствует тому, что ищет сканер. Если бы я использовал вышеуказанный метод, предполагая, что сканер ищет что-то вроде "Версия номер 6.1.7600.16385", результаты, которые я бы увидел, вместо этого читали бы "1.1.11302.0". Это все равно будет какая-то кажущаяся нумерация версий, но совсем не похожая на тип, на который ссылается моя платформа сканирования.

Например: MS16-027 - найти информацию о версии файла для mfds.dll Для анализа мне пришлось использовать:

value "FileVersion" of version block 1 of file "mfds.dll" of system folder

Для Custom Fixlet мне пришлось использовать:

value "FileVersion" of version block 1 of file "mfds.dll" of system folder != VersionNumberGoesHere (OSServicePatch_gdr.LongStringOfNumbers)

Я немного прочитал синтаксис Action Script для BigFix, и мне показалось, что x64 file (command) против file (command) может привести к разным результатам в зависимости от путей для 32-разрядных и 64-разрядных систем, однако я подумал, что это применимо только к файлам, расположенным внутри C:\Program Files а также C:\Program Files (x86)? Разве это не так? Если так, где находится 64-битная версия System32 и почему результаты между этими двумя так сильно различаются?

2

windows directory configuration-management patch-management windows-patching

Источник

Michael H 24 мар '16 в 21:14

1 ответ

Другие вопросы по тегам windows directory configuration-management patch-management windows-patching

jgstew 04 июн '16 в 18:31 2016-06-04 18:31 · Answer 1 · 2016-06-04 18:31

Просто чтобы прояснить, это вопрос актуальности BigFix, а не BigFix ActionScript.

Я скажу, что хотя релевантность BigFix имеет некоторую кривую обучения и иногда затрудняет выявление источника сложности, проблемы, с которыми вы сталкиваетесь, больше связаны со сложностью того, как файлы могут иметь много разных типов версий. информация плюс способ перенаправления Microsoft WindowsOnWindows работает.

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

Актуальность versions of files "mfds.dll" читает одно местоположение, а актуальность values "FileVersion" of version blocks of files "mfds.dll" читает в другом месте.

Посмотреть здесь:

Q: (values "FileVersion" of version blocks of it, (it as string) of versions of it) of files "mfds.dll" of (system folders)
A: 10.0.14342.1000 (rs1_release.160506-1708), 10.0.14342.1000
T: 3.677 ms
I: plural ( string, string )

Я не думаю, что различия, которые вы видите, связаны с различиями между file а также x64 file, но это важно понимать по многим причинам.

Для целей этого вопроса предположим, что речь идет о 64-битном компьютере с Windows, и вы должны предположить, что это относится к Windows Vista или более поздней версии, но может также относиться к 64-битной Windows XP.

Поскольку клиент BigFix представляет собой 32-разрядный процесс, все операции чтения файлов, которые будут выполняться в специальных 64-разрядных местоположениях, фактически перенаправляются окнами в 32-разрядное расположение.

В чем разница между files а также x64 files в значении BigFix? В случае большинства файлов, использование либо files а также x64 files будет на самом деле читать тот же файл. Это потому, что использование x64 files приказывает BigFix прочитать файл с отключенным перенаправлением WindowsOnWindows(WoW), но это перенаправление применяется только к чтению по определенным путям. Одним из примеров является Program Files и другое существо System32, пока что-то вроде C:\Windows\Temp Перенаправление WoW вообще не зависит, поэтому любой файл, читаемый в C:\Windows\Temp работает одинаково независимо.

32-битное расположение: C:\Program Files (x86)
64-битное местоположение: C:\Program Files
32-битное расположение: C:\Windows\SysWOW64
64-битное местоположение: C:\Windows\System32
64-битное местоположение: C:\Windows\sysnative
- специальный поддельный путь, который работает без отключения перенаправления

Мы должны поблагодарить Microsoft за то, что в расположении 64-битной системы указано имя 32, а в расположении 32-битной системы. Это, безусловно, чрезвычайно распространенный источник путаницы.

Используйте это отношение, чтобы увидеть, что на самом деле есть 2 копии mfds.dll в системе.

(name of it, size of it) of files "mfds.dll" of (system folders; system x64 folders)

Эта релевантность читает оба местоположения, потому что (system folders; system x64 folders) говорит BigFix читать ОБА C:\Windows\SysWOW64 папка, а также C:\Windows\System32 папка.

Псих? Смешение? Просто подожди, это становится страннее.

Запустите следующую релевантность в отладчике исправлений: pathnames of files "mfds.dll" of (system folders; system x64 folders)

Q: pathnames of files "mfds.dll" of (system folders; system x64 folders)
A: C:\WINDOWS\system32\mfds.dll
A: C:\WINDOWS\system32\mfds.dll
T: 1.312 ms
I: plural string

Обратите внимание, что имена обоих файлов одинаковы, но это НЕ один и тот же файл!!!

Вот как работает WindowsOnWindows Redirection. Он лжет 32-битному процессу и сообщает, что читает файл из C:\Windows\System32 местоположение, даже если он прочитал его из C:\Windows\SysWOW64 вместо этого в случае использования system folders релевантность, поэтому BigFix правильно сообщает имя пути как C:\WINDOWS\system32\mfds.dll, Тогда в случае system x64 folders BigFix (32-битный процесс) сообщает Windows, что хочет прочитать местоположение C:\Windows\System32 с отключенным перенаправлением, в этом случае он фактически читает файл, расположенный в C:\WINDOWS\system32\mfds.dll и правильно сообщает имя пути как таковое.

Я хотел бы повторить, это не имеет ничего общего с BigFix и все, что связано с реализацией Microsoft 64-битной Windows с 32-битной переадресацией Windows.

Для будущих вопросов BigFix я настоятельно рекомендую очень активные форумы: https://forum.bigfix.com/