LabVIEW
erl.exe causing vulnerability "Weak SSL/TLS Key Exchange | port 5673/tcp over SSL"
While LabVIEW uses this executable (I think RabbitMQ), that executable is external to NI so they can't really fix it.
They actually can and I’m sure the newest version of SystemLink uses a newer version of RabbitMQ. So upgrading that component could work. Or removing SystemLink from your system.
@rolfk wrote:
They actually can and I’m sure the newest version of SystemLink uses a newer version of RabbitMQ. So upgrading that component could work. Or removing SystemLink from your system.
I don't count that as "NI fixing it" but rather "NI applying a third party patch to address this issue". I suppose it's just semantics.
@billko wrote:I don't count that as "NI fixing it" but rather "NI applying a third party patch to address this issue". I suppose it's just
What is your proposal here? SystemLink uses RabbitMQ that is written in Erlang, but if the RabbitMQ developers even have a bit of sanity left they do not implement HTTP themselves but rather use an already available library, maybe in Erlang too but possibly also a binary dependency such as libcurl. This library for sure won’t implement encryption itself, that would be a sure way to introduce unfixable vulnerabilities. Most likely they use OpenSSL. Each of these dependencies is naturally a little older than the using component. Upgrading such dependencies in dependencies of dependencies for a bug fix release is nothing more than monkey patching. So the only thing is upgrading the entire first dependency with a new version. This is a major development step and pretty much the definition of a new version release, which means upgrading SystemLink (or deinstalling it if you don’t need it) is the most direct fix. Anything else is very unlikely to happen.
Just uninstall SystemLink! I doubt you are using it in any form and flavor. It's unfortunate that the default LabVIEW installer is trying to push all these dependencies down a users throat and I'm sure NI needs to rethink this. SystemLink is a product (with fairly significant license costs if you use it, and those license costs might be justified in a large factory floor where you need some way to manage all the NI hardware from a central place) but most LabVIEW users never ever encounter it other than in such incidents such as a security scan. It should be an optional component for many reasons, such as making the pretty long installation process a bit smaller, not introducing into a system security sensitive components that are never really used, NI definitely not being a specialist in Erlang related tools and components, etc.
The very slight potential that a user will maybe, eventually, after some miracle, start to use a software like SystemLink and pay the associated license cost because it was already installed on his system absolutely doesn't weight up with the potential for conflicts, security vulnerabilities, outdated software components and millions of installation minutes wasted for something that is never used, but sits idling in the background whenever the computer is started up. It should be at least disabled by default until an according tool using it is started up or it is explicitly enabled in the configuration dashboard of SystemLink!
As to the merits of Qualys Security Scan, I have no idea. There are more such tools on the market than I care to learn about, and some of them tend to be more scareware than anything else, so claiming your specific tool is the one that should be used for auditing is always a tricky thing.
As to how to upgrade or get rid of SystemLink there are a few options:
1) upgrading SystemLink to a newer version: https://www.ni.com/en/support/downloads/software-products/download.systemlink.html
2) deinstalling it: Startup NI Package Manager (NIPM) and search for installed SystemLink components. Uninstall them! Some of the packages are only visible if you uncheck the Product only option and enable the Gear Icon>>Show full version numbers and hidden packages in the Installed tab of NIPM.
3) disabling its associated services and background tasks: Go to Windows Services and search for NI System Link related services. Stop them and disable them. This may have rather unexpected effects if you are not careful which services you disable.
And next time when you install LabVIEW, go through the various packages it wants to install and explicitly uncheck all SystemLink related packages.
@rolfk wrote:
@billko wrote:I don't count that as "NI fixing it" but rather "NI applying a third party patch to address this issue". I suppose it's just
What is your proposal here? SystemLink uses RabbitMQ that is written in Erlang, but if the RabbitMQ developers even have a bit of sanity left they do not implement HTTP themselves but rather use an already available library, maybe in Erlang too but possibly also a binary dependency such as libcurl. This library for sure won’t implement encryption itself, that would be a sure way to introduce unfixable vulnerabilities. Most likely they use OpenSSL. Each of these dependencies is naturally a little older than the using component. Upgrading such dependencies in dependencies of dependencies for a bug fix release is nothing more than monkey patching. So the only thing is upgrading the entire first dependency with a new version. This is a major development step and pretty much the definition of a new version release, which means upgrading SystemLink (or deinstalling it if you don’t need it) is the most direct fix. Anything else is very unlikely to happen.
I didn't explain myself very well. I meant it's NI's responsibility to fix the issue, but the issue wasn't caused by anything they did. By mentioning "patch", I led you down a RabbitMQ hole that I did not intend. My comment wasn't intended to cause a discussion about the ease of the fix, although I can see why it did.
