RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1981308 - socat tries to verify peer common name even if it is not provided when peer is IPv6 address
Summary: socat tries to verify peer common name even if it is not provided when peer i...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: socat
Version: CentOS Stream
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: beta
: ---
Assignee: Ondrej Moriš
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-07-12 11:01 UTC by Vlad S
Modified: 2022-12-19 13:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-12-19 13:10:58 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+


Attachments (Terms of Use)
Proposed patch for xio-openssl.c (1.04 KB, patch)
2021-07-12 11:01 UTC, Vlad S
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker CRYPTO-9048 0 None None None 2022-12-13 07:35:45 UTC

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


Note You need to log in before you can comment on or make changes to this bug.