Confuso na relevância do BigFix - arquivos x64

Question

Estou usando o BigFix em um ambiente corporativo e notei que uma nova rodada de patches da Microsoft para 2016 falhou em um pequeno grupo de ativos. Consegui contornar isso criando Fixlets de Cópia Personalizada, usando relevância modificada, mas a relevância que eu tive que usar nem sempre era consistente, mesmo que a maioria dos arquivos estivessem todos localizados em C:\Windows\Sytem32 .

Por exemplo: MS16-031 - Os critérios que minha plataforma de varredura está procurando são baseados no número da versão para Ntdll.dll . Crio um Fixlet Customizado com Relevância:

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

Isso funcionou muito bem, pois eu criei uma análise do BigFix que procurava Ntdll.dll usando relevância:

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"

Consegui confirmar que a relevância do Fixlet personalizado estava praticamente pontual com a Análise. Por algum motivo, não é uma imagem espelhada dos dois, mas é extremamente próxima e a lista do Fixlet personalizado mostra todas as máquinas sinalizadas nos resultados da verificação, por isso estou feliz com isso.

O problema surge aqui: Para alguns arquivos em C:\Windows\System32 , eu tenho que usar uma sintaxe totalmente diferente para obter as informações corretas sobre o número da versão que estou procurando com base nos resultados da varredura. Ou seja, eu posso usar o método listado acima, mas as informações da versão que ele fornecerá não estão nem perto do que o scanner está procurando. Se eu usasse o método acima do método listado, supondo que o scanner esteja procurando por algo como "Número da versão 6.1.7600.16385", os resultados que eu veria, em vez disso, leriam "1.1.11302.0". Ainda seria algum tipo de numeração de versão aparente, mas nada similar ao tipo que minha plataforma de varredura está referenciando.

Por exemplo: MS16-027 - Para localizar as informações sobre a versão do arquivo mfds.dll para a análise que eu tive que usar:

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

Para o Fixlet personalizado, tive que usar:

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

Eu li um pouco sobre a sintaxe do Action Script para o BigFix e pareceu que x64 file (command) vs. file (command) pode levar a resultados diferentes com base no pathing para sistemas de 32 bits e sistemas de 64 bits, no entanto, Pensei que isso só se aplicaria a arquivos localizados em C:\Program Files e C:\Program Files (x86) ? Não é esse o caso? Em caso afirmativo, onde está localizada a versão de 64 bits do System32 e por que os resultados entre os dois são tão diferentes?

    

Answer 1

Só para esclarecer, essa é uma questão sobre a relevância do BigFix, não do BigFix ActionScript.

Eu diria que, embora a relevância do BigFix tenha uma curva de aprendizado e torne a origem da complexidade difícil de entender às vezes, os problemas que você está tendo têm mais a ver com a complexidade de como os arquivos podem ter diferentes tipos de informações de versão mais o modo como o redirecionamento do Windows no Windows funciona.

O motivo simples pelo qual as informações da versão do arquivo podem ser diferentes, dependendo de onde você as leu, é que existem vários locais para colocar as versões dos arquivos, e elas podem ser exatamente iguais ou diferentes. Isso depende do criador do arquivo e de como ele deseja transmitir o significado das informações da versão.

A relevância versions of files "mfds.dll" lê um local, enquanto a relevância values "FileVersion" of version blocks of files "mfds.dll" lê um local diferente.

Veja aqui:

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 )

Eu não acho que as diferenças que você está vendo se devam às diferenças entre file e x64 file , mas é importante entender por vários motivos.

Para os fins desta questão, suponhamos que estamos falando de um computador Windows de 64 bits, e você deve assumir que isso se aplica ao Windows Vista ou posterior, mas também pode se aplicar ao Windows XP de 64 bits.

Como o cliente BigFix é um processo de 32 bits, todas as leituras de arquivos que seriam feitas nos locais especiais de x64 bits são realmente redirecionadas pelo Windows para o local de 32 bits.

Qual é a diferença entre files e x64 files na relevância do BigFix? No caso da maioria dos arquivos, o uso de files e x64 files realmente lerá o mesmo arquivo. Isso ocorre porque o uso de x64 files diz ao BigFix para ler o arquivo com o Redirecionamento do WindowsOnWindows (WoW) desativado, mas esse redirecionamento se aplica apenas a leituras para caminhos específicos. Um exemplo sendo Program Files e outro sendo System32 , enquanto algo como C:\Windows\Temp não é afetado pelo redirecionamento WoW, portanto, qualquer arquivo lido para C:\Windows\Temp funciona da mesma forma, independentemente disso.

• local de 32 bits: C:\Program Files (x86)
• local de 64 bits: C:\Program Files
• local de 32 bits: C:\Windows\SysWOW64
• local de 64 bits: C:\Windows\System32
• local de 64 bits: C:\Windows\sysnative
  • caminho falso especial que funciona sem desabilitar o redirecionamento

A Microsoft agradece pelo fato de a localização do sistema de 64 bits ter 32 no nome, enquanto a localização do sistema de 32 bits tem 64 no nome. Esta é definitivamente uma fonte extremamente comum de confusão.

Use essa relevância para ver que há, na verdade, duas cópias de mfds.dll no sistema.

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

Essa relevância lê os dois locais porque (system folders; system x64 folders) diz ao BigFix para ler AMBAS as pastas C:\Windows\SysWOW64 e C:\Windows\System32 .

Louco? Confuso? Apenas espere, fica mais estranho.

Execute a seguinte relevância no depurador do fixlet: 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

Observe como os nomes de caminho de ambos os arquivos são os mesmos, mas estes NÃO são o mesmo arquivo !!!

É assim que o Redirecionamento do WindowsOnWindows funciona. Ele está no processo de 32 bits e diz que leu o arquivo do C:\Windows\System32 location, mesmo que ele tenha lido C:\Windows\SysWOW64 no caso de usar o system folders relevance, então o BigFix propriamente informa o nome do caminho como C:\WINDOWS\system32\mfds.dll . Em seguida, no caso da relevância system x64 folders , o BigFix (processo de 32 bits) informa ao Windows que gostaria de ler a localização C:\Windows\System32 com o redirecionamento desativado. Nesse caso, ele realmente lê o arquivo localizado em C:\WINDOWS\system32\mfds.dll e corretamente informa o nome do caminho como tal.

Gostaria de reiterar, isso não tem nada a ver com o BigFix e tudo a ver com a implementação do Windows 64bit pela Microsoft com o redirecionamento de 32 bits do Windows.

Para dúvidas futuras do BigFix, recomendo vivamente os fóruns muito ativos: link