For tracking purposes (this problem is fixed in 1.3.6+).
This is the 1st of 4 bugs in the tls_verify_crl() function. It's a direct nullptr dereference: variable initialized to NULL, then dereferenced. I fixed it on my side, then I noticed that it had been fixed upstream in 1.3.6. From the 1.3.5 -> 1.3.6 branches diff:
My colleagues hit this crash in the summer of 2018 when dealing with TLS CRLs using CentOS 7's ProFTPD 1.3.5e package against OpenSSL 1.0.2*, and then I was tasked to debug the issue.
I quickly reported the issues privately, but ProFTPD's TLS CRL handling remains broken on all branches more than a year later... I'm aware that TLS CRLs are highly unpopular, and that only system administrators are supposed to define them, but clearly, low-profile responsible disclosure didn't work here :)
Public reports, and CVE ID assignments (for which I'll use this issue as reference), piling onto the recent higher risk issue #846 (CVE-2019-18217) and older vulnerabilities should help the downstream propagation of all fixes, at least if any downstream provides security support for ProFTPD.
The text was updated successfully, but these errors were encountered:
For tracking purposes (this problem is fixed in 1.3.6+).
This is the 1st of 4 bugs in the tls_verify_crl() function. It's a direct nullptr dereference: variable initialized to NULL, then dereferenced. I fixed it on my side, then I noticed that it had been fixed upstream in 1.3.6. From the 1.3.5 -> 1.3.6 branches diff:
I'd have expected this kind of issues to be caught by static analysis.
Additionally, on my side, I used the following change:
FWIW, 4 years ago, stunnel got rid of custom CRL handling code and started relying on OpenSSL's built-in handling instead. That was between 5.23 and 5.24, compare src/verify.c from https://www.usenix.org.uk/mirrors/stunnel/archive/5.x/stunnel-5.23.tar.gz and https://www.usenix.org.uk/mirrors/stunnel/archive/5.x/stunnel-5.24.tar.gz .
My colleagues hit this crash in the summer of 2018 when dealing with TLS CRLs using CentOS 7's ProFTPD 1.3.5e package against OpenSSL 1.0.2*, and then I was tasked to debug the issue.
I quickly reported the issues privately, but ProFTPD's TLS CRL handling remains broken on all branches more than a year later... I'm aware that TLS CRLs are highly unpopular, and that only system administrators are supposed to define them, but clearly, low-profile responsible disclosure didn't work here :)
Public reports, and CVE ID assignments (for which I'll use this issue as reference), piling onto the recent higher risk issue #846 (CVE-2019-18217) and older vulnerabilities should help the downstream propagation of all fixes, at least if any downstream provides security support for ProFTPD.
The text was updated successfully, but these errors were encountered: