WinSvr2016 / DotNet 3.5 / Nessus 139598+138464 / CVE-2020-1476+CVE-2020-1476/ Sequence Question

All:

I've been chasing down some vulnerabilities found by Nessus scans of my NTLite resultant image.

Nessus Plugins 139598 & 138464 keep firing, complaining that the version of "system.web.dll" in [C:\windows\microsoft.net\platform\v2.xxx\] is not patched, and the remediation recommendation from Nessus/Tenable is:

- Apply the October 2020 Cumulative Update for DotNet3.5+4.8
(KB4578969 on WinSvr2016 v1607 (Or on Windows 10 v1809: KB4569750 + KB5004332)

I did manually confirm that my resulting NTLite image has the old DLL version, despite building DotNet3.5+4.8 CU from August or July 2021 (KB4578969)
(And of course, plus the latest SSU+OS CU)

So I'm yet at a loss to explain it, I'm going to run through the application process manually and watch for changes to system.web.dll at each step of the process.

But my question was going to be:
I'm adding DotNet3.5 optional feature via NTLite
Is it possible that NTLite is applying KBs before adding DotNet3.5 optional feature?
(And thus, everything from DotNet3.5 is not receiving the KB updates?)

Seems like a thin theory, I'll delete this post if I find out this problem was user error >:}

----------


Nessus Plugin: 139598
https://www.tenable.com/plugins/nessus/139598
CVE-2020-1476

Nessus Plugin: 138464
CVE-2020-1147
 

Attachments

  • Dotnet3.5_Nessus_Update.png
    Dotnet3.5_Nessus_Update.png
    29.5 KB
A quick status update before C.O.B. (Manual testing in VMWare env finished faster than I expected):

I dont have this problem if I build/patch manually:
-> Add DotNet3.5 Manually (dism/windows server mgr)
-> kb5001402 - SSU - Latest
-> kb5005043 - CU - Latest (The DLLs Nessus wants are patched here)
-> kb4486129 - Install Dotnet48
-> kb5004752 - DotNet48 CU - Latest

So tomorrow I'll test my theory about NTLite by running my WinSvr2016 build process in two-phase/two-stage mode:
1) Open the image, add DotNet3.5 and trim uneeded versions
2) Re-Process the rest of the changes (Minus DotNet3.5 addition)

Thanks all,
~BAS
 
Hi all: A quick update. I've been trying to get you test results on this to determine if I've found a bug in NTLite or not.

I'm now building my WinSvr2016 Image in two phases ( as described above ).

However, the resulting images, built with either of the most recent Svr2106/v1607 cumulative updates (KB5005393 && KB5005043) are performing oddly in a way I've never seen before:

On the first boot after unattended install, they appear to be trying to "roll back" the CU. For sure, I visually see KB5005393 && KB5005043 successfully integrated by NTLite during the build, but when I end up at the Desktop after the OS install, they are missing from "systeminfo.exe" output.

I'll grab you some screenshots from the first boot; very weird.

In the mean time, I'll try to build/resort-back-to CU KB4577015, the last-known working good CU I've used.
(which is more than sufficiently new for this experiment)

1628866664250.png

Then:

1628867470007.png
 
Last edited:
Hi all. Something else in my Preset is causing the problem with CU rollback on first boot.

( Something other than DotNet3.5 feature addition/activation.)

If I run the two-step process:

1) Load the image and add DotNet3.5, save close
2) Strip my preset down to <updates> section only, apply, save, build ISO

Then the resulting image has the latest OS CU successfully installed (however, KB5004752, the latest DotNet4.8 CU still fails)

I'll have to check CBS.log for clues why OS CU KB5005043 is failing.

Right now, I'm going to try it with only/just <RemoveComponents>, <Features> during/on Pass #1, then only/just <updates> during/on Pass #2.

E.g, I doubt <tweaks> would break a CU though, but who knows with this Microsoft crap >:}
 
Last edited:
Found it:

Removing WinNAT will break WinSvr2016 v1607 Cumulative Update.

Remove removing it, everything builds fine.

The hint here was HyperV; and a shot-in-the-dark-guess (HyperV relies on WinNAT for NAT Mode networking)

<RemoveComponents>
<!-- <c>winnat 'Windows NAT Driver'</c> -->

1629125968236.png
 
ntlite dev team:

What do you think about my original sequence-of-events question?:

If NTLite applies CU KBs before adding components, and those components fail to receive updates from the CU, would that be considered a bug or a Caveat/Errata?

Additionally, just for hypothetical discussion: How would that work in the normal world?

For example:
- Install Windows manually
- Install latest CU Update (no newer available on WU)
- Add a component (IIS, DotNet35 etc.)
- Does WU properly detect the presence of components requiring a WU? Does it re-run the WU? I suppose I can test that in a VM.

Because the answer is simple in Linux/BSD: There are no CUs; RPMs are available for update if they are installed, or they are not. Simple.
 
I will proceed with a two-stage process from now on until DotNet3.5 finally dies necessary and bloody death
(Anyone from Rockwell Automation core team out there hearing my prayers?)
 
Back
Top