TC accesses ctldl.windowsupdate.com for no apparent reason

[minosi]

When launching a just downloaded Libre Office installer package (http://donate.libreof
fice.org/home/dl/win-x86/4.2 .6/en-US/LibreO ffice_4.2.6-secfix_Win_x86.msi) I get a
Symatec
Firewall warning:

"TOTALCMD64.EXE is attempting to access the network"

Name: TOTALCMD64.EXE
Version: Not Available
File Path: C:\service\apps\totalcmd\TOTALCMD64.EXE

Connection Origin: local initiated
Protocol: TCP
Local Address: 9.158.167.238
Local Port: 64474
Remote Name: ctldl.windowsupdate.com
Remote Address: 23.215.61.35
Remote Port: 80 (HTTP - World Wide Web)

The LO installer executable is stil launched in the background, independently of the
alert displayed.

The concern:
1) why is TC going out to microsoftupdate.com ?
2) if it is the actuall Libre Office Installer doing so, why is it able to
"impersonate" TC ?

I do trust TC to access the Internet (FTP mainly) so, normally, I would tend to
allow such flows.
However I do not consider acceptable for other applications to silently tunnel their
internet
bound traffic through TC.

Please advise if this is an expected behavior, a bug or, a possibly compromised TC
executable on
my system.

TC version: 8.51a (x64)
OS: Windows 7 x64, SP1 (latest patch set)
User privilege: Admin, TC launched "normally", without admin privileges

[minosi]

EDIT: removed, text not relevant

[ghisler(Author)]

ctldl.windowsupdate.com is not accessed by TC, but by the Windows EXE/DLL loader when an executable file is digitally signed. This is done by Windows to check whether a certificate has been revoked (e.g. because the private key was stolen).

[minosi]

Hmm,
/me would call that a Windows security design bug. A system component like mentioned should not piggy-back on another process for its internet access ...

But as it does not seem break anything when blocked, so a non-issue.

Confirmed as no actual threat => Thanks for the peace of mind!

[Horst.Epp]

Hmm,
/me would call that a Windows security design bug. A system component like mentioned should not piggy-back on another process for its internet access ...
...

And how do you think should Windows check certificates without any external communication ?
Its not a bug but a major security feature.

[minosi]

And how do you think should Windows check certificates without any external communication ?
Its not a bug but a major security feature.

The issue I see is windows piggy-backing on the TC security context. Not the check itself.

To make this clearer - apparently a Windows component *impersonates* TC thus bypassing the normal security boundary.

I can understand that TC probably calls a DLL and the DLL is then executed in TC's process context. The DLL then becomes "part" of TC as far as rest of the system is concerned.

However, as the certificate check seems an automated *Windows* feature it is in my view a bad design of how the function is behaving in the DLL.


Good design would be:
"TC (or DLL running in TC context) makes a system call "check this certificate" and then gets a response back from system "certificate OK/certificate revoked/etc".
Notice that in that case TC itself is NOT required to have internet access allowed.

As far as I understood, in current design you have 2 options:
1) prevent TC context from internet access thus blocking the certificate check
2) allow TC access to internet, increasing the attack surface (e.g. now mallware can piggy-back on TC etc., etc.)


Neither of those is a good option. However my real concern was *why* TC is opening a connection with some Microsoft site. Only options comimg to mind was MS corporate spyware or similar ...

Now solved by keeping TC blocked (as TC itself does not need http access). So all happy.