Windows version conditions do not apply for Windows 10

[DeKe42]

Some artifacts have conditions in the form of os_major_version >= X AND os_minor_version >= Y.
This fails starting with Windows 10, which can have version 10.0. A condition like os_major_version >= 6 AND os_minor_version >= 1 will fail here although the artifact applies.

One example is

artifacts/data/windows.yaml

Line 1335 in 015b375

conditions: [os_major_version >= 6 AND os_minor_version >= 1]

I can think of multiple solutions to this:

• More complicated conditions like (os_major_version >= 6 AND os_minor_version >= 1) OR os_major version >= 7
• A semantic version compare, something like os_version >= "6.1"

[joachimmetz]

@DeKe42 thanks for the report. I'll consult with @grrrrrrrrr how GRR implements this. Moving to versions like "6.1" looks like a better approach. Alternative is to drop the version all together.

[joachimmetz]

Affected artifact definitions:

windows.yaml
WindowsActiveDesktop, WindowsAMCacheHveFile, WinAppXRT, WindowsEnvironmentVariableAppxProcess, WindowsEventLogApplication, WindowsEventLogSecurity, WindowsEventLogSystem, WindowsXMLEventLogApplication, WindowsXMLEventLogSecurity, WindowsXMLEventLogSystem, WindowsXMLEventLogTerminalServices, WindowsOpenSaveMRU, WindowsOpenSavePidlMRU, WindowsRecentFileCacheBCF, WindowsRunGrpConv, WindowsSetupApiLogs,

wmi.yaml
WMIDrivers, WMIHotFixes, WMIInstalledSoftware, WMILoginUsers, WMIPhysicalMemory, WMIProcessList,

[joachimmetz]

GRR CheckCondition applies an object filter to the knowledge base:
https://github.com/google/grr/blob/68a45fd446704285af25403d8dde4d3630524165/grr/core/grr_response_core/lib/artifact_utils.py#L222

[joachimmetz]

GRR knowledge base gets filled with a separate value for os_major_version and os_minor_version. For Linux via provides but not for Windows?

Looks like SetCoreGRRKnowledgeBaseValues is used to set os_major_version:
https://github.com/google/grr/blob/68a45fd446704285af25403d8dde4d3630524165/grr/server/grr_response_server/artifact.py#L80

Values in client_obj are set by FromCurrentSystem:
https://github.com/google/grr/blob/68a45fd446704285af25403d8dde4d3630524165/grr/core/grr_response_core/lib/rdfvalues/client.py#L991

[coperni]

I'm keen on taking this issue on. Going for the latter solution with semantic versioning seems the cleanest approach. Assuming my changes get approved I will make a follow-up PR here to adjust some of these definitions.

@joachimmetz any concerns with the semantic versioning approach? I know this has been sitting in the back burner and your thoughts may have changed.

[joachimmetz]

what do you specifically mean with the "semantic versioning approach" in this context. as in treating the version as string? A semantic version compare, something like os_version >= "6.1"

I'm wondering what value the version information adds. Maybe we can it all together.

[coperni]

I am referring to the second solution proposed by @DeKe42, the "semantic version compare" e.g. os_version >= "X.T". As it stands today artifact collection in grr is still broken (on Windows 10+) for these artifacts.

I don't believe adding os_version will add any additional value to the ForesenicArtifact repository as a whole if we leave os_major_version and os_minor_version in tact. This is more of a remedy patch for the grr codebases CheckCondition logic.

What are you specifically referring to when you say can it all together? The issue #274? The proposed solution of adding os_version as a condition item? Or the affected condition statements for the aforementioned artifacts?

[joachimmetz]

What are you specifically referring to when you say can it all together?

I mean removing it. What is the value it adds? Let me check with the GRR folks but this might be a left over from early days.

[joachimmetz]

Removed conditions #515

Rationale: os_major_version and os_minor_version use the kernel version. Artifact definitions are typically product level specific not kernel level.