ssh -oHostKeyAlgorithms=+ssh-dss -oPubkeyAcceptedKeyTypes=+ssh-dss me@165.72.193.193 ends with a segfault bt full: (gdb) run Starting program: /usr/bin/ssh -oHostKeyAlgorithms=+ssh-dss -oPubkeyAcceptedKeyTypes=+ssh-dss me@165.72.193.193 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b01694 in BN_is_negative () from /lib64/libcrypto.so.3 (gdb) bt full #0 0x00007ffff7b01694 in BN_is_negative () from /lib64/libcrypto.so.3 No symbol table info available. #1 0x00007ffff7c2f0e8 in ossl_encode_der_integer () from /lib64/libcrypto.so.3 No symbol table info available. #2 0x00007ffff7c2f263 in ossl_encode_der_dsa_sig () from /lib64/libcrypto.so.3 No symbol table info available. #3 0x00007ffff7b64b96 in i2d_DSA_SIG () from /lib64/libcrypto.so.3 No symbol table info available. #4 0x00005555555bb15a in ssh_dss_verify () No symbol table info available. #5 0x00005555555d095f in input_kex_gen_reply () No symbol table info available. #6 0x00005555555b33aa in ssh_dispatch_run () No symbol table info available. #7 0x00005555555b3469 in ssh_dispatch_run_fatal () No symbol table info available. #8 0x0000555555580474 in ssh_kex2 () No symbol table info available. #9 0x000055555557b62f in ssh_login () No symbol table info available. #10 0x0000555555563254 in main () No symbol table info available.
Whiteboard: (none) => MGA9TOO
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=33858CC: (none) => fri
*** Bug 33858 has been marked as a duplicate of this bug. ***
CC: (none) => dvorkin
Assigning to Marc who has done recent updates to openssh.
Assignee: bugsquad => mageia
I guess we also missed CVE-2023-38408 which lead us to update to 9.3p2 The crash happens inside openssl. Could be related to #33520 or #33650 Since my ssh servers don't use dss, I can't test it right away. Did this happen after the update of the library? Can you downgrade the lib and check if it still happens?
> Did this happen after the update of the library? > Can you downgrade the lib and check if it still happens? In Mageia 8 it worked perfectly, but Mageia 8 was using lin*openssl-1.1, while Mageia 9 is using v3.0. Ubuntu 24.04 is using v 3.0.13, but it supports dss.
Source RPM: openssh => openssh / openssl
Depends on: (none) => 33520, 33650
CC: (none) => nicolas.salguero
@Nico: can you have a look, if this is sth. that is introduced by openssl and if there is a patch available? I guess to reproduce, one will need a server which uses dss. As far as I know, dss is considered insecure, so an upgrade of the server is highly recommened
DHL server 165.72.193.193 is (In reply to Marc Krämer from comment #5) > I guess to reproduce, one will need a server which uses dss DHL server 165.72.193.193 is available for test. Login is not required for that, case the problem occurs at connection setup stage. Now the only way to work with DSS server in Mageia 9 is to use 'dropbear' as the ssh client replacement. If it is too hard to make it work with modern libopenssl, need to let users know about the dropbear solution.
I'll try to dig this a bit more with Cauldron. I guess --enable-dsa-keys needs to be passed to %configure and some patches synced with Fedora.
CC: (none) => jani.valimaa
On mga9 'ssh -Q key' shows ssh-dss support is enabled by default. I synced one patch from Fedora and pushed updated openssh-9.3p1-2.3.mga9 to mga9 core/updates_testing. Please test when it appears to mirrors.
(In reply to Jani Välimaa from comment #8) > On mga9 'ssh -Q key' shows ssh-dss support is enabled by default. I synced > one patch from Fedora and pushed updated openssh-9.3p1-2.3.mga9 to mga9 > core/updates_testing. Please test when it appears to mirrors. SRPMS: openssh-9.3p1-2.3.mga10 RPMS: openssh-9.3p1-2.3.mga10 openssh-clients-9.3p1-2.3.mga10 openssh-server-9.3p1-2.3.mga10 openssh-keycat-9.3p1-2.3.mga10 openssh-askpass-common-9.3p1-2.3.mga10 openssh-askpass-gnome-9.3p1-2.3.mga10
In Cauldron ssh-dss support is not enabled so this is basically mga9 only bug. There should be a separate bug report if weak ssh-dss needs to be enabled in Cauldron.
Whiteboard: MGA9TOO => (none)Version: Cauldron => 9
I'd ask to update to openssh-9.3p2 this also makes clear we fixed cve-2023-38408 CVE-2023-48795 CVE-2023-51384 CVE-2023-51385
(In reply to Marc Krämer from comment #11) > I'd ask to update to openssh-9.3p2 this also makes clear we fixed > cve-2023-38408 > CVE-2023-48795 > CVE-2023-51384 > CVE-2023-51385 Please file a separate bug for CVEs.
(In reply to Jani Välimaa from comment #12) > (In reply to Marc Krämer from comment #11) > > I'd ask to update to openssh-9.3p2 this also makes clear we fixed > > cve-2023-38408 > > CVE-2023-48795 > > CVE-2023-51384 > > CVE-2023-51385 > > Please file a separate bug for CVEs. these are patches which are included in p2 and we have them separated
(In reply to Marc Krämer from comment #13) > (In reply to Jani Välimaa from comment #12) > > (In reply to Marc Krämer from comment #11) > > > I'd ask to update to openssh-9.3p2 this also makes clear we fixed > > > cve-2023-38408 > > > CVE-2023-48795 > > > CVE-2023-51384 > > > CVE-2023-51385 > > > > Please file a separate bug for CVEs. > > these are patches which are included in p2 and we have them separated That is not true: 9.3p2 only fixes CVE-2023-38408. CVE-2023-48795 and CVE-2023-5138[45] are fixed upstream in 9.6p1. Moreover, 9.3p2 does more than just fixing CVE-2023-38408. Here is an extract of the changelog of 9.3p2: """ Potentially-incompatible changes -------------------------------- * ssh-agent(8): the agent will now refuse requests to load PKCS#11 modules issued by remote clients by default. A flag has been added to restore the previous behaviour "-Oallow-remote-pkcs11". Note that ssh-agent(8) depends on the SSH client to identify requests that are remote. The OpenSSH >=8.9 ssh(1) client does this, but forwarding access to an agent socket using other tools may circumvent this restriction. """ A stable version of a Linux distribution implies that fixing a security issue will only fix that issue if possible (i.e. a patch or several patches are available), not adding new features that can be incompatible. For Cauldron, which behaves like a rolling release distribution, updating to the latest version is the normal behaviour. The 4 listed CVEs are already fixed in openssh-9.3p1-2.2.mga9 so, IMHO, there is no need to fix again those CVEs. To know wether or not a CVE is fixed in a stable linux distribution, you cannot only check the version. That is how all stable linux distributions work. Best regards,
ok....
Resolution: (none) => INVALIDStatus: NEW => RESOLVED
REOPENED as we still need to fix the SEGFAULT when connecting to legacy ssh-dss servers.
Resolution: INVALID => (none)Status: RESOLVED => REOPENED
@Nico:
Assignee: mageia => jani.valimaa
CC: (none) => mageiaDepends on: (none) => 32745
Assignee: jani.valimaa => qa-bugs
RH x86_64 installing openssh-askpass-common-9.3p1-2.3.mga9.x86_64.rpm openssh-clients-9.3p1-2.3.mga9.x86_64.rpm openssh-server-9.3p1-2.3.mga9.x86_64.rpm openssh-9.3p1-2.3.mga9.x86_64.rpm openssh-askpass-gnome-9.3p1-2.3.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64 Preparing... ################################################################################################## 1/5: openssh ################################################################################################## 2/5: openssh-clients ################################################################################################## 3/5: openssh-askpass-common ################################################################################################## 4/5: openssh-askpass-gnome ################################################################################################## 5/5: openssh-server ################################################################################################## 1/5: removing openssh-askpass-gnome-9.3p1-2.2.mga9.x86_64 ################################################################################################## 2/5: removing openssh-server-9.3p1-2.2.mga9.x86_64 ################################################################################################## 3/5: removing openssh-askpass-common-9.3p1-2.2.mga9.x86_64 ################################################################################################## 4/5: removing openssh-clients-9.3p1-2.2.mga9.x86_64 ################################################################################################## 5/5: removing openssh-9.3p1-2.2.mga9.x86_64 ################################################################################################## systemctl restart sshd.service systemctl status sshd.service ● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled) Active: active (running) since Fri 2024-12-27 13:27:45 CST; 7s ago Docs: man:sshd(8) man:sshd_config(5) Main PID: 30292 (sshd) Tasks: 1 (limit: 6877) Memory: 1.3M CPU: 44ms CGroup: /system.slice/sshd.service └─30292 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups" dic 27 13:27:45 jgrey.phoenix systemd[1]: Starting sshd.service... dic 27 13:27:45 jgrey.phoenix sshd[30292]: Server listening on 192.168.1.3 port 22. dic 27 13:27:45 jgrey.phoenix systemd[1]: Started sshd.service. Connect to other systems Connect from other system to my system OK for me papoteur we rely on you to confirm the issue reported is fixed
Source RPM: openssh / openssl => openssh
Keywords: (none) => advisory
(In reply to katnatek from comment #18) > > OK for me > > papoteur we rely on you to confirm the issue reported is fixed ssh command from comment0 with updated openssh should give a password prompt instead of segfault. $ ssh -oHostKeyAlgorithms=+ssh-dss -oPubkeyAcceptedKeyTypes=+ssh-dss me@165.72.193.193 (me@165.72.193.193) Password:
MGA9-64 Plasma Wayland on Compaq H000SB. # systemctl restart sshd.service # systemctl -l status sshd.service ● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled) Active: active (running) since Sat 2024-12-28 17:20:15 CET; 29s ago Docs: man:sshd(8) man:sshd_config(5) Main PID: 19011 (sshd) Tasks: 1 (limit: 8806) Memory: 1.3M CPU: 149ms CGroup: /system.slice/sshd.service └─19011 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups" Dec 28 17:20:14 mach3.hviaene.thuis systemd[1]: Starting sshd.service... Dec 28 17:20:15 mach3.hviaene.thuis sshd[19011]: Server listening on 0.0.0.0 port 22. Dec 28 17:20:15 mach3.hviaene.thuis sshd[19011]: Server listening on :: port 22. Dec 28 17:20:15 mach3.hviaene.thuis systemd[1]: Started sshd.service. I can connect successfully to and from my desktop PC; and I can confirm the outcome of the command in comment 19. Pass to more knowledgeable people to jugde this is OK as a test, I will not object the OK.
CC: (none) => herman.viaene
(In reply to Jani Välimaa from comment #19) > (In reply to katnatek from comment #18) > > > > OK for me > > > > papoteur we rely on you to confirm the issue reported is fixed > ssh command from comment0 with updated openssh should give a password prompt > instead of segfault. > > $ ssh -oHostKeyAlgorithms=+ssh-dss -oPubkeyAcceptedKeyTypes=+ssh-dss > me@165.72.193.193 > (me@165.72.193.193) Password: ssh -oHostKeyAlgorithms=+ssh-dss -oPubkeyAcceptedKeyTypes=+ssh-dss me@165.72.193.193 The authenticity of host '165.72.193.193 (165.72.193.193)' can't be established. DSA key fingerprint is SHA256:uijWIkOgaj0TWD6ROI0IPtMn50ef98HdSYma8o/44so. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '165.72.193.193' (DSA) to the list of known hosts. (me@165.72.193.193) Password: OK then
Whiteboard: (none) => MGA9-64-OKCC: (none) => andrewsfarm
Validating.
CC: (none) => sysadmin-bugsKeywords: (none) => validated_update
The advisory file references an openssl package (which was updated a few months ago), but from the bug it looks like it's actually openssh that's been updated for this bug.
CC: (none) => dan
(In reply to Dan Fandrich from comment #23) > The advisory file references an openssl package (which was updated a few > months ago), but from the bug it looks like it's actually openssh that's > been updated for this bug. Fixed
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2024-0241.html
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED