Megjelent az OpenSSH 9.2, a SSH 2.0 \u00e9s SFTP protokollokkal val\u00f3 munk\u00e1ra szolg\u00e1l\u00f3 kliens \u00e9s szerver ny\u00edlt forr\u00e1sk\u00f3d\u00fa megval\u00f3s\u00edt\u00e1sa. Az \u00faj verzi\u00f3ban megsz\u00fcntett\u00e9k azt a sebezhet\u0151s\u00e9get, amely kett\u0151s mem\u00f3riafelszabad\u00edt\u00e1shoz vezetett az autentik\u00e1ci\u00f3 el\u0151tti szakaszban. A sebezhet\u0151s\u00e9g csak az OpenSSH 9.1 kiad\u00e1st \u00e9rinti, kor\u00e1bbi verzi\u00f3kban a probl\u00e9ma nem jelentkezik. <\/p>\n
A sebezhet\u0151s\u00e9g megjelen\u00e9s\u00e9hez elegend\u0151 a SSH-kliens banner\u00e9nek megv\u00e1ltoztat\u00e1sa «SSH-2.0-FuTTYSH_9.1p1»-ra, hogy el\u00e9rj\u00fck az «SSH_BUG_CURVE25519PAD» \u00e9s «SSH_OLD_DHGEX» z\u00e1szl\u00f3k be\u00e1ll\u00edt\u00e1s\u00e1t, amelyek a SSH-kliens verzi\u00f3j\u00e1t\u00f3l f\u00fcggenek. Ezeknek a z\u00e1szl\u00f3knak a be\u00e1ll\u00edt\u00e1sa ut\u00e1n a «options.kex_algorithms» puffert egyszerre k\u00e9tszer szabad\u00edtj\u00e1k fel - el\u0151sz\u00f6r a do_ssh2_kex() f\u00fcggv\u00e9ny v\u00e9grehajt\u00e1sakor, amely a compat_kex_proposal() -t h\u00edvja, majd a do_authentication2() sor\u00e1n, amely l\u00e1ncba k\u00f6ti az input_userauth_request(), mm_getpwnamallow(), copy_set_server_options(), assemble_algorithms() \u00e9s kex_assemble_names() f\u00fcggv\u00e9nyeket. <\/p>\n
A sebezhet\u0151s\u00e9ghez kapcsol\u00f3d\u00f3 m\u0171k\u00f6d\u0151 exploit l\u00e9trehoz\u00e1sa val\u00f3sz\u00edn\u0171tlen, mivel a kihaszn\u00e1l\u00e1s folyamata t\u00fal bonyolult - a modern mem\u00f3riaeloszt\u00e1si k\u00f6nyvt\u00e1rak v\u00e9delmet ny\u00fajtanak a dupla felszabad\u00edt\u00e1s ellen, \u00e9s a pre-auth folyamat, amelyben a hiba jelen van, cs\u00f6kkentett jogosults\u00e1gokkal fut egy izol\u00e1lt sandbox k\u00f6rnyezetben. <\/p>\n
A megjel\u00f6lt sebezhet\u0151s\u00e9gen k\u00edv\u00fcl az \u00faj kiad\u00e1sban tov\u00e1bbi k\u00e9t biztons\u00e1gi probl\u00e9m\u00e1t is megsz\u00fcntettek: <\/p>\n
\n
Hiba l\u00e9p fel a «PermitRemoteOpen» be\u00e1ll\u00edt\u00e1s\u00e1nak feldolgoz\u00e1sa sor\u00e1n, amely az els\u0151 argumentum figyelmen k\u00edv\u00fcl hagy\u00e1s\u00e1hoz vezet, ha az elt\u00e9r «any» \u00e9s «none» \u00e9rt\u00e9kekt\u0151l. A probl\u00e9ma az OpenSSH 8.7 vagy \u00fajabb verzi\u00f3kban jelentkezik, \u00e9s az egyetlen jogosults\u00e1g megad\u00e1sa eset\u00e9n a vizsg\u00e1lat kihagy\u00e1s\u00e1hoz vezet.\n
A t\u00e1mad\u00f3, aki ir\u00e1ny\u00edtja a DNS-szervert, amelyet a nevekkel val\u00f3 azonos\u00edt\u00e1shoz haszn\u00e1lnak, el\u00e9rheti, hogy speci\u00e1lis karakterek (p\u00e9ld\u00e1ul «*») ker\u00fcljenek a known_hosts f\u00e1jlokba, ha a konfigur\u00e1ci\u00f3ban a CanonicalizeHostname \u00e9s a CanonicalizePermittedCNAMEs opci\u00f3k be vannak kapcsolva, \u00e9s a rendszerszint\u0171 felold\u00f3 nem ellen\u0151rzi a DNS-szerver v\u00e1laszainak helyess\u00e9g\u00e9t. A t\u00e1mad\u00e1st val\u00f3sz\u00edn\u0171tlennek tekintik, mivel a visszaadott neveknek meg kell felelni\u00fck a CanonicalizePermittedCNAMEs \u00e1ltal megadott felt\u00e9teleknek. <\/ul>\n
Egy\u00e9b v\u00e1ltoz\u00e1sok: <\/p>\n
\n
Az ssh_config f\u00e1jlhoz hozz\u00e1adt\u00e1k az EnableEscapeCommandline be\u00e1ll\u00edt\u00e1st, amely a kliens oldali «~C» escape sorozatok feldolgoz\u00e1s\u00e1nak enged\u00e9lyez\u00e9s\u00e9t szab\u00e1lyozza, amely parancssort biztos\u00edt. Alap\u00e9rtelmezetten a «~C» feldolgoz\u00e1sa most le van tiltva a szigor\u00fabb sandbox izol\u00e1ci\u00f3 \u00e9rdek\u00e9ben, ami potenci\u00e1lisan probl\u00e9m\u00e1kat okozhat a rendszerek m\u0171k\u00f6d\u00e9s\u00e9ben, ahol a «~C» port\u00e1tir\u00e1ny\u00edt\u00e1sra haszn\u00e1lj\u00e1k.\n
Az sshd_config f\u00e1jlba az sshd-hez hozz\u00e1adva lett a ChannelTimeout direkt\u00edva, amely a csatorna inaktivit\u00e1si id\u0151t\u00fall\u00e9p\u00e9s\u00e9t hat\u00e1rozza meg (azok a csatorn\u00e1k, ahol a direkt\u00edv\u00e1ban megadott id\u0151 alatt nem \u00e9szlelnek forgalmat, automatikusan bez\u00e1r\u00f3dnak). K\u00fcl\u00f6nb\u00f6z\u0151 id\u0151t\u00fall\u00e9p\u00e9sek adhat\u00f3k meg a munkamenetre, X11-re, \u00fcgyn\u00f6kre \u00e9s forgalom \u00e1tir\u00e1ny\u00edt\u00e1s\u00e1ra.\n
Az sshd_config f\u00e1jlba az sshd-hez hozz\u00e1adva lett az UnusedConnectionTimeout direkt\u00edva, amely lehet\u0151v\u00e9 teszi az idle klienskapcsolatok id\u0151t\u00fall\u00e9p\u00e9s\u00e9nek be\u00e1ll\u00edt\u00e1s\u00e1t, ha azok egy bizonyos ideig nem tartalmaznak akt\u00edv csatorn\u00e1kat.\n
Az sshd-hez hozz\u00e1adt\u00e1k a «-V» opci\u00f3t a verzi\u00f3 megjelen\u00edt\u00e9s\u00e9re, hasonl\u00f3an a ssh klienshez tartoz\u00f3 opci\u00f3hoz.\n
Az «ssh -G» kimenet\u00e9hez hozz\u00e1adt\u00e1k a «Host» sort, amely az argumentum n\u00e9v\u00e9rt\u00e9k\u00e9t t\u00fckr\u00f6zi.\n
Az scp \u00e9s sftp rendszerekhez hozz\u00e1adva lett az «-X» opci\u00f3, amely lehet\u0151v\u00e9 teszi az SFTP protokoll param\u00e9tereinek, p\u00e9ld\u00e1ul a m\u00e1sol\u00e1si pufferm\u00e9ret \u00e9s a f\u00fcgg\u0151ben l\u00e9v\u0151 lek\u00e9rdez\u00e9sek sz\u00e1m\u00e1nak kezel\u00e9s\u00e9t.\n
Az ssh-keyscan mostant\u00f3l lehet\u0151v\u00e9 teszi a teljes CIDR c\u00edmk\u00e9szletek beolvas\u00e1s\u00e1t, p\u00e9ld\u00e1ul «ssh-keyscan 192.168.0.0\/24». <\/ul>\n