OPNsense Forum
Archive => 22.1 Legacy Series => Topic started by: almodovaris on March 01, 2022, 07:22:55 pm
-
cyrus-sasl is vulnerable. Run pkg audit -F
-
Or use the built-in health audit and post it everywhere because nobody knows about it. ;)
Cheers,
Franco
-
I also noticed the vuln in the security audit.
However, the really interesting questions are:-
* Is OPNsense vulnerable in its default configuration?
* Are there any mitigation measures?
* Is access to the web UI needed or are there also other attack vectors?
Any feedback is much appreciated.
-
Ok, here is what you do when you see a report light up:
Look up the packages that use the vulnerable package:
# pkg info -r cyrus-sasl
cyrus-sasl-2.1.27_2:
squid-4.15
openldap24-client-2.4.59_4
cyrus-sasl-gssapi-2.1.27_2
Now go to the link provided:
https://vuxml.FreeBSD.org/freebsd/a80c6273-988c-11ec-83ac-080027415d17.html
Pretty useless... go to the next one:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19906
A lot of unhelpful info... leading to:
https://github.com/cyrusimap/cyrus-sasl/issues/587
This sort of circles around sasl_bind functionality, for example in PHP that would be:
https://www.php.net/manual/en/function.ldap-sasl-bind.php
Let's scan the code for sasl use:
# opnsense-code core
# cd /usr/core
# git grep -i sasl
(no matches)
I can't vouch for third party code included here including squid (see above), but it's a relatively safe bet that when we do not configure SASL use from core that the vulnerable code is never used by us, even indirectly.
I know some are using LDAP server components and the whole OpenLDAP infrastructure also includes SASL in case you want to use it but as long as you do not configure it nothing can happen. Same as with core.
Mileage varies for plugins looking at os-postfix, os-freeradius and os-web-proxy-sso trying to configure sasl under certain setups.
Cheers,
Franco
-
Any update on the fix?
-
> Any update on the fix?
Please stop trolling and start reading. This is ridiculous.
Cheers,
Franco
-
Please stop trolling and start reading. This is ridiculous.
Cheers,
Franco, I am not trolling. :( This is a response that I would typically see in pfsense. I legit do not see a resolution in your previous post, I see you posted some information on diagnosing, but no fix. I did a google search and found that 2.1.28 was updated 2.23.22 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262133 But I do not see an update for opnsense or how to get this fix.
-
Franco, I am not trolling. :( This is a response that I would typically see in pfsense. I legit do not see a resolution in your previous post, I see you posted some information on diagnosing, but no fix. I did a google search and found that 2.1.28 was updated 2.23.22 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262133 But I do not see an update for opnsense or how to get this fix.
"I can't vouch for third party code included here including squid (see above), but it's a relatively safe bet that when we do not configure SASL use from core that the vulnerable code is never used by us, even indirectly." - This seems pretty self-explanatory to me.
-
pkg info -r cyrus-sasl
cyrus-sasl-2.1.27_2:
squid-4.15
openldap24-client-2.4.59_4
cyrus-sasl-gssapi-2.1.27_2
Squid not installed, ldap removed today (no requirement after tests) so is it safe to remove, if so what command to use?
-
Franco, so what you are saying is that it is installed by something other than the core firewall. Got it. That still does not resolve the issue of opnsense health saying there it is vulnerable. Nor help figure what is causing the problem. I appreciate your attention, please understand I am an end user not a opnsense programmer.
it's a relatively safe bet that when we do not configure SASL use from core that the vulnerable code is never used by us, even indirectly.
"Indirectly" would seem to indicate plugins in the opnsense repo? Are these verified compatible somehow with new release versions and made sure they are not vulnerable? The only issue I noticed after upgrading is that os-dyndns was marked as misconfigured so I reinstalled that, then I saw that it is marked as legacy now, so I will work on switching to os-ddclient. I also am not using squid.
-
A couple of things:
1. When this security issue was registered with FreeBSD's database 22.1.2 was completed for 24 hours and fully tested, about 4 hours before actual release of it. Timing sucks sometimes.
2. In the history of this project fixes almost always appeared in the next release, which is going to be 22.1.3. Exceptions apply when FreeBSD ports are not updated or when there simply was no fix for it yet. It happens too.
3. Free security analysis above. I tried to explain what is going on. I can't support a full ecosystem security audit beyond core with limited community time. I don't have direct access to all source code in the ports tree (the mention of squid source code in particular was meant for that).
4. You can update from the ports tree manually. It just needs the new version in the ports tree from FreeBSD and us. That can take up to several days. This can also ruin a planned release cycle beforehand. Happened before too.
None of these infos are new if you extract the actual issue presented in cyrus-sasl. I'm just saying it doesn't help explaining this once every two weeks. The security audit is nice, but it's not meant to create endless questions when it in fact is there to answer more questions than you would get elsewhere.
I apologise for being blunt on the matter. I feel obligated to respond to questions, but answering it all the time in this level of detail is hardly maintainable and a large number of threads with these points already exist.
Cheers,
Franco
-
Understandable, as a preemptive measure and to be respectful of your time: when the security/health checks are complete and issues were found, a link could be presented that takes end users to an opnsense webpage with information suitable to end users with general diagnosis procedures as you have presented, that could be updated with any pertinent or ongoing information. Again I appreciate your assistance.
-
There is a link but in this case it was a bit lazily prepared...
https://vuxml.freebsd.org/freebsd/a80c6273-988c-11ec-83ac-080027415d17.html
There is another link in it with slightly more info. Etc. etc.
I think that the difficulty to gather more information on this is the same for everyone. :)
Note that the database being used is maintained via a FreeBSD port and we can't extend this information ourselves and timely updates on their end even if we submit something is not a given. A lot of volunteers over there.
Cheers,
Franco
-
Took the time to also update cyrus-sasl with the 22.1.2_1 hotfix that was just released.
Cheers,
Franco
-
Can confirm working as expected with the latest release.
Thank you for all your work and support!