I - Introduction

This document highlights & explains a recent change and update that has been implemented to enable better logging & clarifying detection reasons for vulnerabilities.

This will be of particular interest to customers who do not have all of their core servers connected to the WWW to download patch content directly.

II - What's changing?

The LANDesk patch content team have added additional capabilities to a DLL used in scanning for vulnerabilities.

Since various vulnerabilities may have to check dozens, if not close to 100 affected dependencies / products, it can get complicated at times trying to identify specifically *WHY* a certain patch has been detected. The new logging update will improve upon this significantly, highlighting the specific product GUID(-s) that have triggered the detection, rather than forcing an administrator to check this themselves individually.

Better still, the relevant information is included in the "REASON" field, so is centrally reportable / extractable from the LANDesk database.

II.A - An example highlighting the change

Hitherto, the relevant client-side log file section which listed a vulnerability as being detected would look as follows (in this case, MS14-072 is used to highlight the hit) - the key line is highlighted:

(...)

Thu, 24 Sep 2015 10:28:25 Running detection script

Thu, 24 Sep 2015 10:28:25 created the hlpr instance ok

Thu, 24 Sep 2015 10:28:25 isInstallable=True

Thu, 24 Sep 2015 10:28:25 MS14-072_INTL detected

Thu, 24 Sep 2015 10:28:25 VUL: 'MS14-072_INTL' (ndp40-kb2978125-x86.exe) DETECTED.  Reason 'Patch NDP40-KB2978125-x86.exe was not found.'.  Expected 'Patch NDP40-KB2978125-x86.exe installed'.  Found 'Patch NDP40-KB2978125-x86.exe not installed'.  Patch required 'ndp40-kb2978125-x86.exe'.

 

Thu, 24 Sep 2015 10:28:25    Patch is NOT installed

(...)

The change that has been implemented (and that will be incorporated into the patch content changes this into the following (highlighting the relevant additions in RED):

(...)

Fri, 02 Oct 2015 13:11:33 Running product detection script

Fri, 02 Oct 2015 13:11:33 Running detection script

Fri, 02 Oct 2015 13:11:33 created the hlpr instance ok

Fri, 02 Oct 2015 13:11:33 MS14-072_INTL detected

Fri, 02 Oct 2015 13:11:33 VUL: 'MS14-072_INTL' (ndp40-kb2978125-x86.exe) DETECTED.  Reason 'Product {3C3901C5-3455-3E0A-A214-0B093A5070A6} needs this patch.'.  Expected 'Patch NDP40-KB2978125-x86.exe should be installed'.  Found 'Patch NDP40-KB2978125-x86.exe has not been installed'.  Patch required 'ndp40-kb2978125-x86.exe'.

 

Fri, 02 Oct 2015 13:11:33    Patch is NOT installed

(...)

III - What & Who is affected?

III.A - What versions of LANDesk Management Suite are affected?

The updated DLL is already live & available in patch content for:

- LANDesk Management Suite 9.0 (any service pack level)

- LANDesk Management Suite 9.5 (any service pack level)

- LANDesk Management Suite 9.6 (any service pack level)

... and will be a standard feature for future versions of LANDesk Management Suite going forward. It will be automatically downloaded as part of your patch content update.

III.B - Who is affected?

Technically "everyone" who downloads / makes use of patch content is affected, as this is an update to one of the key patching DLL's.

In practice though, most customers do not need to perform any actions - the situation where actions are required highlighted separately in section IV below.

IV - Do I need to do anything?

If your Core(-s) is/are connected to the WWW & download their own patch content, then you do not need to do anything. If they haven't already, they'll get the updated LANDeskScan.DLL when they next check for updated patch content.

The new version of the DLL will then be automatically downloaded & put into the Core's LDLOGON share, whereupon all clients will automatically self-update with the new DLL when they next execute the vulnerability scanner (vulscan.exe). This will ensure

IV.A - Situations / Customers who ARE affected are...

... anyone who does not download vulnerability / patch-content to their environment from the WWW directly to all of their core servers. This is usually restricted to air-gapped environments, where a single Core is connected to the WWW to download content, and a certain process is followed to then move that content to these "dark" Cores.

Since the "dark core"-process does not usually include checking for updates of binaries / DLL's, this is being highlighted as a necessary step to undertake. Such customers.

Equally, it will affect any customer who (for whatever reasons) rely on copying patch content from one of their own servers, rather than the WWW directly.

IMPORTANT NOTE:

Please be mindful / aware that the updated DLL is version specific. So if there were a situation where the "light" (i.e. - internet-facing) Core were of version 9.0 and you were to serve multiple versions of LANDesk Management Suite with that patch content, you would not be able to use the version 9.0 DLL on a (say) version 9.6 server.

 

We (strongly) recommend that patch content be only copied / moved between "same version" servers.

V - In Conclusion

If there are any questions that have not been answered, please post them in the comments section, and we'll try to respond to them there.