Bug 1981308

Summary: socat tries to verify peer common name even if it is not provided when peer is IPv6 address
Product: Red Hat Enterprise Linux 8 Reporter: Vlad S <fau>
Component: socatAssignee: Ondrej Moriš <omoris>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: CentOS StreamCC: bstinson, carl, davide, jwboyer, pasteur
Target Milestone: betaKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-12-19 13:10:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Proposed patch for xio-openssl.c none

Description Vlad S 2021-07-12 11:01:36 UTC
Created attachment 1800753 [details]
Proposed patch for xio-openssl.c

Description of problem:

Hello! I have came across of segfault related to the absence of check for peer name to be provided in the case of IPv6 communication in socat 1.7.4.1 (this was introduced 1.7.4.x branch).

The same check is present for IPv4 addresses, but was missed for v6 protocol.


Version-Release number of selected component (if applicable):
1.7.4.1


How reproducible:
100%, every time.


Steps to Reproduce:
1. Run listener as:
socat -d -d -u -b65536 -L /tmp/randfile1234 -T 300 openssl-listen:0,reuseaddr,pf=ip6,cert=/var/certs/server.pem -
2. Execute sender as:
echo "hello" | ./socat -u -b65536 -T 300 - openssl-connect:[IPv6]:[port],cn=[fqdn-of-the-listener],cert=/var/certs/server.pem,cafile=/var/certs/ca.pem,ipv6-tclass=36
3. Observe SIGSEGV on listening side:

2021/07/09 02:06:39 socat[3299863] E exiting on signal 11


Actual results:

Segfault at stack:

(gdb) bt
#0  0x000055555557ffc3 in xioip6_pton ()
#1  0x0000555555588369 in openssl_handle_peer_certificate ()
#2  0x0000555555588be0 in _xioopen_openssl_listen ()
#3  0x000055555558a305 in xioopen_openssl_listen ()
#4  0x0000555555570408 in xioopen_single ()
#5  0x00005555555705bb in xioopen ()
#6  0x000055555556f23a in socat ()
#7  0x000055555556beca in main ()
(gdb)

Caused by unchecked string passed in line 1780 of xio-openssl.c:

xioip6_pton(peername, &ip6bin);

peername is coming from the command line arguments on the listening side, so it should be like:

openssl-listen:0,reuseaddr,pf=ip6,cert=/cert.pem,cn=[sender], but if it's not passed (at least in case of IPv4/FQDN), it should be noop with peer name never checked and operation let to be continued.

Expected results:

The message is sent successfully. Verbose log line to contain:

2021/07/12 03:25:18 socat[1732687] N trusting certificate, no check of commonName

To indicate that the peername is indeed never checked. 


Additional info:

Attaching the proposal of patch to introduce the check for peername presence same same way it is done for IPv4 and FQDN branches.

Comment 1 Davide Cavalca 2021-07-16 15:20:17 UTC
We've built a socat package with this patch in the Hyperscale SIG and have validated that is solves the issue: https://cbs.centos.org/koji/buildinfo?buildID=33392

The commit adding the patch is at https://git.centos.org/rpms/socat/c/0cada9cffa314e4ce595d801ba0e191d40d70abd?branch=c8s-sig-hyperscale

Comment 2 Ondrej Moriš 2021-07-20 10:04:33 UTC
Thank you for discovering this issue, its correct investigation and even proposing the fix. I'd suggest to reach to socat upstream with the proposed fix (socat) or I can do it myself if you prefer it. Most likely the soonest possible RHEL target for inclusion of this patch is RHEL-8.6.0 or later since RHEL-8.5.0 work is already done and we may not be able to include it there. If I understand correctly there is a workaround possible (at least for some cases) by specifying sender CN on listener side. If we won't be able to fix this in RHEL-8.5.0 we can at least document the workaround.

Comment 3 Vlad S 2021-07-20 10:53:51 UTC
I have reached out to socat upstream and they have acknowledged this bug report, looking for the next communication from them.

Speaking of the workaround, it is possible to use it, but the problem appears in the case of mixed socat versions, e.g. if you have CentOS 7 where only 1.7.3.3 socat and CentOS 8 with 1.7.4.1, they cannot really communicate unless you have IPv6 as common name in your certificate (as 1.7.3.3 simply ignores altnames in the cert). 

As Davide mentioned above, we have another build with the fix in our internal repository, so we should be good. For our particular use case, we would like to start using the patched binary (as long as it is an acceptable fix from the community standpoint).

Comment 5 Ondrej Moriš 2022-12-19 13:10:58 UTC
I am sorry but I am going to close this one. There are currently no plans to release a new version of socat in RHEL-8 unless there are critical flaws to fix. Fortunately, this does not qualify for that bar. Thanks to the reporter the issue was already addressed upstream [1] and is fixed in 1.7.4.4. Eventually, there will be a rebase of socat on RHEL-9 and in Fedora to this or later version. Opening a RHEL-9 bug might speed up that.

[1] https://repo.or.cz/socat.git/blobdiff/e9c055b75092f9939e45e972e490a8fdf267dccb..1477334905be18c08bd6dc77be5a62e36b573de4:/xio-openssl.c