Bug #92972 | Application crash depending on ssh options | ||
---|---|---|---|
Submitted: | 26 Oct 2018 19:59 | Modified: | 11 Mar 2019 22:02 |
Reporter: | Andrew Harrison | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Workbench | Severity: | S3 (Non-critical) |
Version: | 8.0.13 | OS: | Linux (LinuxMint 19 x86_64) |
Assigned to: | CPU Architecture: | Any | |
Tags: | WBBugReporter |
[26 Oct 2018 19:59]
Andrew Harrison
[26 Oct 2018 20:07]
Andrew Harrison
The wb.log and segfault text
Attachment: mysql-bug-data-92972.zip (application/zip, text), 13.84 KiB.
[26 Oct 2018 20:09]
Andrew Harrison
I also have an strace if anyone is interested. I can't sftp it because when I attempt to sftp I just get the following error: ssh_dispatch_run_fatal: Connection to 141.146.1.165 port 2021: DH GEX group out of range Connection closed
[26 Oct 2018 21:30]
MySQL Verification Team
Thank you for the bug report. Please try version 8.0.13. Thanks.
[30 Oct 2018 13:12]
Andrew Harrison
Upgraded to "Version 8.0.13 build 13780177 CE (64-bits) Community" No change, symptoms still exist.
[1 Nov 2018 15:16]
Jonathan L
Output from mysql-workbench showing segmentation violation reg dump and backtrace
Attachment: DUMP5 (application/octet-stream, text), 81.23 KiB.
[1 Nov 2018 15:16]
Jonathan L
Reproduced on Ubuntu 18.04.1 LTS (desktop) with simpler test case Linux white 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Fresh install of Workbench 1b2f77ad8d807cb45d3ef3da5ad421b6 mysql-workbench-community_8.0.13-1ubuntu18.04_amd64.deb RECREATE CRASH Have as ~/.ssh.config the single line text Note that this config file will cause an error "Bad configuration option: text" in standard command line ssh. (Legitimate commands also cause the problem, tried with "IdentitiesOnly No", "IdentitiesOnly Yes" and others. Run with "mysql-workbench > DUMP3 2>&1" 1. Click "MySQL Connections +" to add new connection 2. Select Connection Meethod "Standard TCP/IP over SSH" 3. Leave all others at defaults inc SSH Hostname 127.0.0.1:22 4. In this instance 127.0.0.1 not listening on 22 5. Click "Test Connection" 6. "Please enter password for ..." just click OK 7. Crashes with segmentation fault /lib/x86_64-linux-gnu/libc.so.6(fgets+0x1b)[0x7f8766548b3b] /usr/lib/mysql-workbench/libssh.so.4(+0x1a172)[0x7f8765358172] /usr/lib/mysql-workbench/libssh.so.4(ssh_options_parse_config+0xf2)[0x7f876536930e] MINIMAL CHANGE Repeat with ~/.ssh/config the single line "#IdentitiesOnly no" Repeat as above See dialogue box "Failed to connect". No crash.
[1 Nov 2018 16:19]
Jonathan L
Further testing with MySQL Workbench CE (GPL) 8.0.13 CE build 13780177 on Ubuntu 18.04.1 desktop. SEVERITY Regarding Severity: this renders the software almost UNUSABLE. ANALYSIS The bug appears to be that Workbench not correctly detecting errors when parsing the SSH configuration file. Apparently, any config line which it doesn't know causes the segmentation violation and crash. It doesn't matter if there is a valid SSH server to connect to. With mysql-workbench --log-level=debug3 the file ~/.mysql/log/wb.log contains 15:47:00 [DB3][ SSHCommon]: libssh: ssh_config_parse_file ssh_config_parse_file: Reading configuration data from /home/user/.ssh/config 15:47:00 [DB3][ SSHCommon]: libssh: ssh_config_parse_line ssh_config_parse_line: Unsupported option: ForwardAgent, line: 1 THEN CRASH Any of the following, as a single line in ~/.ssh/config will cause the crash ForwardAgent no test IdentitiesOnly yes IdentitiesOnly no AddressFamily any These make no crash: Port 22 #any comment (empty file) (blank lines) The normal lines after successful read of the config file are 15:49:46 [DB3][ SSHCommon]: libssh: ssh_config_parse_file ssh_config_parse_file: Reading configuration data from /home/user/.ssh/config 15:49:46 [INF][ SSHCommon]: libssh: ssh_connect ssh_connect: libssh 0.7.5 ... 15:49:46 [DB3][ SSHCommon]: libssh: getai getai: host 127.0.0.1 matches an IP address ... It may be that the config lines which users have which cause problems are those which they have added because they are using OpenSSH or perhaps a later/different libssh than MySQL Workbench. WORKAROUNDS Temporarily remove ~/.ssh/config Temporarily remove permission (shamefully still runs!) chmod 0 ~/.ssh/config Edit the config to avoid crashing options (end)
[1 Nov 2018 17:35]
Jonathan L
The bug is that Workbench fails to properly detect an unknown SSH option, and crashes instead of either issuing a warning or error. WORKAROUND Further to workaround, the known options appear to be these: host hostname port user identityfile ciphers compression connecttimeout protocol stricthostkeychecking userknownhostsfile proxycommand gssapiserveridentity gssapidelegatecredentials They were found by examining the binary of the libssh lrwxrwxrwx 1 root root 11 Sep 14 13:15 /usr/lib/mysql-workbench/libssh.so -> libssh.so.4 lrwxrwxrwx 1 root root 15 Sep 14 13:15 /usr/lib/mysql-workbench/libssh.so.4 -> libssh.so.4.4.2 -rw-r--r-- 1 root root 540328 Sep 14 13:15 /usr/lib/mysql-workbench/libssh.so.4.4.2 $ hd /usr/lib/mysql-workbench/libssh.so.4.4.2 | fgrep -6 -i strict 00055700 00 00 80 3f cd cc 4c 3e 00 00 00 00 00 00 00 00 |...?..L>........| 00055710 68 6f 73 74 00 68 6f 73 74 6e 61 6d 65 00 70 6f |host.hostname.po| 00055720 72 74 00 75 73 65 72 00 69 64 65 6e 74 69 74 79 |rt.user.identity| 00055730 66 69 6c 65 00 63 69 70 68 65 72 73 00 63 6f 6d |file.ciphers.com| 00055740 70 72 65 73 73 69 6f 6e 00 63 6f 6e 6e 65 63 74 |pression.connect| 00055750 74 69 6d 65 6f 75 74 00 70 72 6f 74 6f 63 6f 6c |timeout.protocol| 00055760 00 73 74 72 69 63 74 68 6f 73 74 6b 65 79 63 68 |.stricthostkeych| 00055770 65 63 6b 69 6e 67 00 75 73 65 72 6b 6e 6f 77 6e |ecking.userknown| 00055780 68 6f 73 74 73 66 69 6c 65 00 70 72 6f 78 79 63 |hostsfile.proxyc| 00055790 6f 6d 6d 61 6e 64 00 67 73 73 61 70 69 73 65 72 |ommand.gssapiser| 000557a0 76 65 72 69 64 65 6e 74 69 74 79 00 67 73 73 61 |veridentity.gssa| 000557b0 70 69 64 65 6c 65 67 61 74 65 63 72 65 64 65 6e |pidelegatecreden| 000557c0 74 69 61 6c 73 00 79 65 73 00 6e 6f 00 2c 00 00 |tials.yes.no.,..|
[2 Nov 2018 17:09]
Jonathan L
GOOD WORKAROUND Although there is no apparently no configuration option for controlling the reading of the ~/.ssh/config file, MySQL Workbench does have a configuration file which can be used. TO REPRODUCE If there is no file ~/.mysql/workbench/wb_options.xml, run and quit without any actions. If you already have this file, skip this section. $ mysql-workbench MENU: File > Exit This will create the appropriate directories. The file wb_options.xml is created when Workbench exits successfully. CHANGE CONFIG Edit the file, find the XML line with key SSH:pathtosshconfig and edit it. In the following, USERNAME will be whatever the actual username is. Default: <value type="string" key="SSH:pathtosshconfig">/home/USERNAME/.ssh/config</value> Change to <value type="string" key="SSH:pathtosshconfig">/home/USERNAME/.ssh/wbconfig</value> TEST As previously. Start Workbench, click on + (Add connection), select "Standard TCP/IP over SSH", No edits, Click "Test Connection", see password dialogue, no entry, click "OK". See dialogue "Failed to connect", which shows successful workaround. Failure would be a segmentation violation, no dialogue box. It is presumed that the new file ~/.ssh/wbconfig would work with the SSH options which Workbench's libssh supports, but this is untested. EVIDENCE This is strace output at the crash: openat(AT_FDCWD, "/home/jcl/.ssh/config", O_RDONLY) = 15 fstat(15, {st_mode=S_IFREG|0600, st_size=5832, ...}) = 0 read(15, "# .ssh/config\n# convenience of c"..., 4096) = 4096 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x120dfe100} --- This is matching strace output after implementing workaround: openat(AT_FDCWD, "/home/jcl/.ssh/wbconfig", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/home/jcl/.mysql/workbench/log/wb.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 15 lseek(15, 0, SEEK_END) = 1571 This is now a usable workaround.
[7 Nov 2018 20:13]
MySQL Verification Team
https://bugs.mysql.com/bug.php?id=93108 marked as duplicate of this one.
[5 Dec 2018 11:56]
MySQL Verification Team
Thank you for the feedback, observed this issue on Ubuntu 18.04 LTS after following Jonathan's steps from the report. regards, Umesh
[5 Dec 2018 11:56]
MySQL Verification Team
Test details
Attachment: 92972.log (application/octet-stream, text), 85.70 KiB.
[11 Mar 2019 22:02]
Christine Cole
Posted by developer: Fixed as of the upcoming MySQL Workbench 8.0.16 release, and here's the changelog entry: Rather than generating a warning or error when it detected an unknown SSH option in the ~/.ssh/config file, MySQL Workbench became unresponsive. Thank you for the bug report.