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 1665837 - crash when attempting to connect using encrypted client TLS certificate
Summary: crash when attempting to connect using encrypted client TLS certificate
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: gtk-vnc
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Daniel Berrangé
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-14 08:49 UTC by Ján Tomko
Modified: 2023-02-12 22:45 UTC (History)
2 users (show)

Fixed In Version: gtk-vnc-0.9.0-2.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 15:59:10 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
VirtViewer Console, (265.02 KB, image/png)
2020-01-08 09:50 UTC, Martin Krajnak 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-30283 0 None None None 2023-02-12 22:45:47 UTC
Red Hat Product Errata RHBA-2020:1690 0 None None None 2020-04-28 15:59:13 UTC

Description Ján Tomko 2019-01-14 08:49:27 UTC 
Description of problem:
Crash on attempt to connect using an encrypted client TLS certificate

Version-Release number of selected component (if applicable):
gtk-vnc2-0.9.0

How reproducible:
100 %

Steps to Reproduce:
1. Create a VM with VNC graphics that uses TLS. My qemu.conf:
vnc_tls = 1
vnc_tls_x509_cert_dir = "/etc/pki/libvirt-vnc"
vnc_tls_x509_verify = 1

2. Use a password protected client key:
Supply the --password argument to certtool in the following step:
https://wiki.libvirt.org/page/TLSCreateClientCerts

3. Copy the files to /etc/pki/libvirt-vnc for libvirt's use:
# ls -1 /etc/pki/libvirt-vnc/
ca-cert.pem
client-cert.pem
client-key.pem
server-cert.pem
server-key.pem
And link them to the locations expected by virt-viewer:
https://wiki.libvirt.org/page/VNCTLSSetup#Virt_Viewer_.28virt-viewer.29
# ls -lR /etc/pki/CA /etc/pki/libvirt
/etc/pki/CA:
total 0
lrwxrwxrwx. 1 root root 26 Jan 10 13:40 cacert.pem -> ../libvirt-vnc/ca-cert.pem

/etc/pki/libvirt:
total 0
lrwxrwxrwx. 1 root root 30 Jan 11 10:43 clientcert.pem -> ../libvirt-vnc/client-cert.pem
drwxr-xr-x. 2 root root 27 Jan 11 10:44 private

/etc/pki/libvirt/private:
total 0
lrwxrwxrwx. 1 root root 32 Jan 11 10:44 clientkey.pem -> ../../libvirt-vnc/client-key.pem

4. Start the domain
5. remote-viewer vnc+tls://$HOST:5900

Actual results:
==1154== Invalid read of size 4
==1154==    at 0x60870FB: gnutls_bye (record.c:288)
==1154==    by 0x4A46B73: vnc_connection_close (vncconnection.c:5120)
==1154==    by 0x4A4E6CA: vnc_connection_coroutine (vncconnection.c:5650)
==1154==    by 0x4A51BCE: coroutine_trampoline (coroutine_ucontext.c:55)
==1154==    by 0x5BD81FF: ??? (in /usr/lib64/libc-2.28.so)
==1154==    by 0x175DB277: ???
==1154==  Address 0x1847fcf0 is 384 bytes inside a block of size 6,496 free'd
==1154==    at 0x4839A0C: free (vg_replace_malloc.c:540)
==1154==    by 0x4A4B019: vnc_connection_start_tls (vncconnection.c:4466)
==1154==    by 0x4A4CBE8: vnc_connection_perform_auth_vencrypt (vncconnection.c:4708)
==1154==    by 0x4A4CBE8: vnc_connection_perform_auth (vncconnection.c:4818)
==1154==    by 0x4A4CBE8: vnc_connection_initialize (vncconnection.c:5415)
==1154==    by 0x4A4E50F: vnc_connection_coroutine (vncconnection.c:5639)
==1154==    by 0x4A51BCE: coroutine_trampoline (coroutine_ucontext.c:55)
==1154==    by 0x5BD81FF: ??? (in /usr/lib64/libc-2.28.so)
==1154==    by 0x175DB277: ???
==1154==  Block was alloc'd at
==1154==    at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==1154==    by 0x60B6FDE: gnutls_init (state.c:465)
==1154==    by 0x4A4AB28: vnc_connection_start_tls (vncconnection.c:4434)
==1154==    by 0x4A4CBE8: vnc_connection_perform_auth_vencrypt (vncconnection.c:4708)
==1154==    by 0x4A4CBE8: vnc_connection_perform_auth (vncconnection.c:4818)
==1154==    by 0x4A4CBE8: vnc_connection_initialize (vncconnection.c:5415)
==1154==    by 0x4A4E50F: vnc_connection_coroutine (vncconnection.c:5639)
==1154==    by 0x4A51BCE: coroutine_trampoline (coroutine_ucontext.c:55)
==1154==    by 0x5BD81FF: ??? (in /usr/lib64/libc-2.28.so)
==1154==    by 0x175DB277: ???

Expected results:
No crash.

Additional info:
Fixed upstream by:
commit e62d010777eecda47829e9da54bad3387f4d6231
Author:     Ján Tomko <jtomko>
CommitDate: 2019-01-12 17:42:53 +0000

    vnc_connection_start_tls: add deinit label

commit 7879ae9c747b4e95bb3850c4e67ca57d3ded82e3
Author:     Ján Tomko <jtomko>
CommitDate: 2019-01-12 17:44:29 +0000

    vnc_connection_start_tls: set tls_session to NULL after deinit
git describe: v0.9.0-18-g7879ae9
Comment 3 Martin Krajnak 2020-01-02 14:12:16 UTC 
Hi Jan, I was just trying to verify this, as i don't have that much experiences with this,
I followed the guidelines https://wiki.libvirt.org/page/TLSSetup (hopefully without flaws)
on top of that I applied instruction from your reproducer. 

I can get the working connection, my host machine is rhel 8.2 with 8.2 guest as well. 
However I am only getting the black screen when I am connecting to the vm which is runnig 
without problems, I can ssh to it and the most important thing there is no crash of remote viewer.

Log:

$remote-viewer -v vnc+tls://192.168.122.127:5900
Guest (null) has a vnc display
Opening connection to display at vnc+tls://192.168.122.127:5900


I was wondering if you can think of a reason causing the black screen, I will try  to poke around more
to be sure I can't crash it.
Comment 4 Ján Tomko 2020-01-02 16:02:01 UTC 
Did you supply the password option to certtool when generating the client key?

When getting info about the key file, certtool should ask for the password:

# certtool -k --infile /etc/pki/libvirt/private/clientkey.pem
Encrypted structure detected...
PKCS #8 information:
        Cipher: AES-128-CBC
        Schema: PBES2-AES128-CBC (2.16.840.1.101.3.4.1.2)
        Salt: df883a227c0985ae137674ffe1799424749ad7e9c7
        Salt size: 21
        Iteration count: 5150

Enter password:


Note that remote-viewer should not be able to connect, since encrypted client keys
are AFAIK unsupported. This bug is about remote-viewer not crashing when encoutering
such files. With --gtk-vnc-debug, I'm getting the following message when attempting
to connect (RPM built from git master - commit 8de814d2c ):

src/vncconnection.c Cannot load certificate & key Decryption has failed.

With Fedora 30's gtk-vnc-0.9.0-5.fc30, remote-viewer crashes.
Comment 5 Tomas Pelka 2020-01-07 13:33:46 UTC 
(In reply to Ján Tomko from comment #4)
> Did you supply the password option to certtool when generating the client
> key?
> 
> When getting info about the key file, certtool should ask for the password:
> 
> # certtool -k --infile /etc/pki/libvirt/private/clientkey.pem
> Encrypted structure detected...
> PKCS #8 information:
>         Cipher: AES-128-CBC
>         Schema: PBES2-AES128-CBC (2.16.840.1.101.3.4.1.2)
>         Salt: df883a227c0985ae137674ffe1799424749ad7e9c7
>         Salt size: 21
>         Iteration count: 5150
> 
> Enter password:
> 
> 
> Note that remote-viewer should not be able to connect, since encrypted
> client keys
> are AFAIK unsupported. This bug is about remote-viewer not crashing when
> encoutering
> such files. With --gtk-vnc-debug, I'm getting the following message when
> attempting
> to connect (RPM built from git master - commit 8de814d2c ):
> 
> src/vncconnection.c Cannot load certificate & key Decryption has failed.
> 
> With Fedora 30's gtk-vnc-0.9.0-5.fc30, remote-viewer crashes.
Comment 6 Martin Krajnak 2020-01-08 09:38:45 UTC 
Hello Jan, yes, in my case: 
[root@localhost private]# certtool -k --infile /etc/pki/libvirt/private/clientkey.pem
Encrypted structure detected...
PKCS #8 information:
	Cipher: AES-128-CBC
	Schema: PBES2-AES128-CBC (2.16.840.1.101.3.4.1.2)
	Salt: a64e7f8b7865a20e5fec3f1cc648d0b4c00446
	Salt size: 19
	Iteration count: 5123

Enter password: 


So the results are following:

1. When I start vm with VirtViewer, change connection to VNC I am seeing a message in console:
Viewer is disconnected (see screenshot)

2. When I use vnc-viewer:
$ remote-viewer -v vnc+tls://192.168.122.127:5900
Guest (null) has a vnc display
Opening connection to display at vnc+tls://192.168.122.127:5900

after a while I got this:
Guest x11 display has disconnected, shutting down


3. I've also rebuilt the srpm and tried gvncviewer utility, but since it's meant to be simple I'ts not working with vnc+tls at all,
otherwise it's the same, blank screen. 

So I have no crashes on my side, would you consider it fixed or is there anything more I can try ?
Comment 7 Martin Krajnak 2020-01-08 09:50:35 UTC 
Created attachment 1650622 [details]
VirtViewer Console,
Comment 8 Ján Tomko 2020-01-14 11:10:59 UTC 
(In reply to Martin Krajnak from comment #6)
> So I have no crashes on my side, would you consider it fixed or is there
> anything more I can try ?

Looks good to me!
Comment 9 Tomas Pelka 2020-01-14 11:15:57 UTC 
(In reply to Ján Tomko from comment #8)
> (In reply to Martin Krajnak from comment #6)
> > So I have no crashes on my side, would you consider it fixed or is there
> > anything more I can try ?
> 
> Looks good to me!

Thanks Jan, flipping to VERIFIED on behalf of Martin.
Comment 12 errata-xmlrpc 2020-04-28 15:59:10 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1690
Note You need to log in before you can comment on or make changes to this bug.