Discovery Pattern 'MSSql DB On Windows' Launching Unrelated Process

[aen612]

What happened

The OOB 'MSSql DB On Windows' pattern was handed a 'cmdb_running_process' record with a stale PID. SQL Server had restarted, and Windows had reassigned that PID to a different process. The pattern resolved the PID live, got back the other process, and used it without checking that the executable name matched what it expected.

Step 4 of the pattern, "get version from command line if process exist", builds a command from $process.executablePath. With the wrong process bound, that step launched an unrelated binary on the target host.

The sequence

Pre-pattern data supplied a stored record:

pid=9600
name=sqlservr.exe
command=H:\MSSQL\MSSQL16.MSSQLSERVER\MSSQL\Binn\sqlservr.exe
listening_on=:1433:1434:

Process Detection resolved that PID against the host:

Select * From Win32_Process WHERE (ProcessId = 9600)

A different process came back. The pattern set $process to it anyway:

setAttribute(process,ProcessDTO [executable='<other-agent>.exe',
  executablePath='C:\Program Files\...\<other-agent>.exe', pid='9600', ...])

Step 4's only precondition is $process.executablePath Is Not Empty. That passed, and the pattern ran:

"C:\Program Files\...\<other-agent>.exe" -v

The command timed out after 70 seconds. The pattern logged a tolerated failure and continued.

Result

A process was created on the host, owned by the Discovery service account, with a command line that does not match how that application is normally launched. The command timeout ends the WMI wrapper but not the spawned process, so it stays running until someone removes it.

The MSSQL instance CI also picked up no Version value, since step 4's regex expects Microsoft SQL Server in the output.

Why it is intermittent

On our host the two processes had adjacent PIDs, meaning they start close together during boot. Which one gets which PID varies. The stored record is correct after one boot and wrong for another.

The pattern only has to run in the window between a reboot and the next process probe. The probe itself works fine and corrects the record on its next pass, so most runs are unaffected.

Not specific to this pattern

Any pattern that binds $process from a stored PID and then executes something based on it can do this. 'MSSql DB On Windows' is just where we found it, and the binary that inherited the PID is incidental.

Fix

Process Detection should compare the executable name returned by Win32_Process against the name in the source record before binding $process. Both values are available at that point.

Tightening the discovery schedule narrows the window but does not close it, since a host can reboot at any point in the cycle.
I've submitted a Case with ServiceNow Support. If they fix it, great. If not, I'll update the pattern to verify the returned process and fail if it doesn't match.