Remote exploit in OpenSSH < 3.3

[Verwijderd]

Op donderdag 27 juni 2002 00:46 schreef 2P het volgende:
Ik kwam op slashdot een post van Patrick Volkerding (Slackware maintainer). Deze post verklaart waarom OpenSSH nog geen upgrade heeft gehad in -stable, current.
Leek mij wel nuttig om hier even te melden
[..]

Mooi, dan gooi ik zo die 3.3 zut er ook maar weer af

/edit typo's

[deadinspace]

Op woensdag 26 juni 2002 20:44 schreef 0siris het volgende:
na aardig wat dep. gezeik heb ik nu op 2 verschillende machines achtereenvolgens:

Dependancy gezeik?
Gewoon

code:

deb http://security.debian.org $DIST/updates main contrib non-free

in je sources.list zetten, waarbij $DIST eentje uit potato, woody, stable of testing is. Regelmatig apt-get update; apt-get upgrade doen en je blijft up-to-date met de security updates.
Voor Unstable (Sid) zul je genoegen moeten nemen met de Testing security updates.

code:

sshd version OpenSSH_3.3 Debian 1:3.3p1-0.0potato2
sshd version OpenSSH_3.3 Debian 1:3.3p1-0.0woody4

zijn deze nieuw zat?

Als je privsep aan hebt staan kun je daarmee niet geroot worden als het goed is ja.
Het is trouwens nog steeds aan te raden om bovenstaande te doen, want de security.debian.org heeft voor potato al versie 3.4p1-0.0potato1, die als het goed is de definitieve fix bevat.
Woody-met-security-updates heeft wel nog 3.3p1-0.0woody4 (Het Debian security team heeft altijd Stable als prioriteit).

Op woensdag 26 juni 2002 20:49 schreef dystopia het volgende:
Ja. 3.3 met UsePrivilegeSeparation yes is secure.

Nouja, secure... Nog steeds vulnerable (op een aantal platformen). Maar dankzij privsep kun je slechts als user 'sshd' (of whatever) inbreken ipv als als root. Significant verschil maar niet 100% secure.

Op woensdag 26 juni 2002 20:58 schreef 0siris het volgende:
Maareh...werkt die (al dan nog niet zekere) bug ook als je een nogal strict /etc/hosts.deny|allow hebt? Ik bedoel: kan iemand die ik NIET in mijn /etc/hosts.allow heb staan, eventueel toch nog met zijn 1337 h4x0r skI11z binnenkomen?

Dat weet ik niet zeker.
sshd moet zelf (via libwrap.so) checken of iemand die connect erin mag van de tcp-wrappers.
Of die tcp-wrappers helpen hangt er dus vanaf of de exploit zit vóórdat de tcp-wrappers gecheckt worden, of erna.
Ik gok dat de exploit erna zit, wat in zou houden dat je deze exploit niet kunt misbruiken als je in hosts.deny staat, maar zeker weten doe ik dat niet.

Beter is - op kernel nivo - firewallen (met bijvoorbeeld ipchains of iptables in GNU/Linux). Als je in de firewall staat komen je packets namelijk überhaupt nooit aan bij sshd.

Op woensdag 26 juni 2002 22:13 schreef stuartje het volgende:
Ik ga het zeker niet manueel doen want ik gebruik Debian en anders gaat dat conflicten geven met apt-get

Nou, security dinges in sources.list zetten en upgraden dan. In het geval van Potato ben je dan klaar, in het geval van Woody moet je in ieder geval controleren of privsep aan staat.
In het geval van Sid zul je de security updates van Testing moeten gebruiken.

[Verwijderd]

Euhj waarom wordt hier nog allemaal gepraat over 3.3?

Versie 3.4pl1 is namelijk al uit . Dus die instaleren

[pinball]

Updated OpenSSH package for Slackware 8.1:
ftp://ftp.slackware.com/pub/slackware/slackware-8.1/patches/packages/openssh-3.4p1-i386-1.tgz Updated OpenSSH package for Slackware 8.0:
ftp://ftp.slackware.com/pub/slackware/slackware-8.0/patches/packages/openssh.tgz

Misschien heeft PV zich bedacht :-)

Slackware 8.1:
bfd503d88144c62906deef4a1280f583 openssh-3.4p1-i386-1.tgz
Slackware 8.0:
a88c387e5261dd9ac90b113e85d054ed openssh.tgz

(btw: er is er ook een voor 7.1)

[Verwijderd]

Op donderdag 27 juni 2002 01:51 schreef deadinspace het volgende:

Woody-met-security-updates heeft wel nog 3.3p1-0.0woody4 (Het Debian security team heeft altijd Stable als prioriteit).

Ja met PAM vuln. Tja Stable heeft prioriteit en Testing wordt het meest gedraait.

Nouja, secure... Nog steeds vulnerable (op een aantal platformen). Maar dankzij privsep kun je slechts als user 'sshd' (of whatever) inbreken ipv als als root. Significant verschil maar niet 100% secure.

100% secure is een uitspraak. 100% secure heb je wanneer je nog niet wanneer je je bak in een kluis opbergt, immers, men kan de kluis openbreken!

Het is met PAM uit scriptkiddie-proof (en daar gaat het allereerst om want de meeste crackers verwijderen niet eens data, dat valt veel teveel op). Ik heb zelf tijden lang guest/guest access opengehouden op mijn bak incl. PAM limieten, chroot, etc. etc. bakje is nooit geroot; commands werden zeer regelmatig gechecked. En in die chroot was ik nog best lief voor meneer guest. Maar goed, je hebt gelijk: beter upgraden naar 3.4.

Beter is - op kernel nivo - firewallen (met bijvoorbeeld ipchains of iptables in GNU/Linux). Als je in de firewall staat komen je packets namelijk überhaupt nooit aan bij sshd.
[..]

Met spoofing misschien wel maar tijdelijk is deze oplossing wel goed. En Snort natuurlijk draaien

[igmar]

SuSE is (in dit geval) echt niet een expert, dat is het OpenSSH team en ISS. Dat ten eerste.

De bug zit in de S/Key support. Niet meer en niet minder. Aangezien dat op zowat alle systemen uitstaat noem ik dit een storm in een glas water.

Ten tweede zeggen ze dat er een 2de hole is ontdekt in PAM (en Theo zegt in die post dat er nog meer is geaudit en dat noem jij nutteloos? Ik vind het kwalijk. Crackers gaan die code echtwel auditen en misbruiken).

Ik twijfel hier zeer sterk aan. OpenBSD gebruikt BSD Auth, geen PAM. Ze hebben ook nooit PAM gebruikt, dus vanwaar de audit ??

Dus default is SuSE niet vuln. Als je PAM hebt enabled (zoals ik) ben je wel vuln.

Dat is speculatie ten top. Het begon met : Alleen 64 bits UNIX is vulnerable, toen zowel 32 + 64, toen was het een root exploit op ALLE unixes, en toen de aap uit de mouw kwam bleek het om S/Key te gaan. Dat die code buggy was was een jaar geleden al bekend.

Vind ik dus niet. Theo zegt dat hij afgelopen week heeft geaudit. Dus toen hij iedereen adviseerde up te graden naar 3.3 wist hij al dat 3.4 uitkwam en dat daar meer bugs in werden gefixed. Dus 3.3 was een quick fix. Want zoals nu al is gebleken ben je wel vuln. voor een andere remote compromise wanneer je PAM hebt enabled. Er zit dus naar alle waarschijnlijkheid wel een remote exploit in OpenSSH / Linux.

Eerst zien en dan geloven. Privilege seperation is ook niet alles, zeker gezien het feit dat root uit een jail kan 'ontsnappen'

Ik vertrouw meer op grsecurity op een systeem, dat houdt iig de scriptkiddies tegen.

[Verwijderd]

Op donderdag 27 juni 2002 10:16 schreef igmar het volgende:

Dat is speculatie ten top. Het begon met : Alleen 64 bits UNIX is vulnerable, toen zowel 32 + 64, toen was het een root exploit op ALLE unixes, en toen de aap uit de mouw kwam bleek het om S/Key te gaan. Dat die code buggy was was een jaar geleden al bekend.
[..]

Maak een verschil tussen Apache, en OpenSSH asjeblieft
Apache: eerst 64bit, en daarna (ook) 32 bit systemen
OpenSSH: Root exploit op alles, blijkt een S/Key probleempje

[Verwijderd]

Overigens heeft Patrick Volkerding een nieuwe package uitgebracht voor OpenSSH-3.4p1 voor Slackware. Te downloaden op de bekende locaties

[xzenor]

ehm okee
dus als ik het goed begrijp is dit:

# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no

omzetten naar dit:

# Uncomment to disable s/key passwords
ChallengeResponseAuthentication no

gewoon voldoende?????
Wordt daar die hele heisa over gehouden??????

en dat PAM verhaal?
FreeBSD gebruikt PAM, maar kan je dat uit zetten? of wordt het wachten op een update ofzo?
(aangezien ik FreeBSD gebruik...)

[Verwijderd]

Als je twijfelt zou ik gewoon lekker de nieuwe versie installeren, daar is de exploit (met of zonder PAM) opgelost.

[Verwijderd]

Op vrijdag 28 juni 2002 00:31 schreef possamai het volgende:
(aangezien ik FreeBSD gebruik...)

Al de antwoorden staan hier: http://www.openssh.com/txt/preauth.adv
Succes verder!

[xzenor]

ik wacht tot freebsd de ingebouwde openssh gefixt heeft....
dan maar effe op andere manieren connecten. op dit moment staat ssh in iedergeval dicht voor de buitenwereld

[xzenor]

Op vrijdag 28 juni 2002 00:39 schreef dystopia het volgende:

[..]

Al de antwoorden staan hier: http://www.openssh.com/txt/preauth.adv
Succes verder!

Kijk dat is een practische link!
Thnx!

[Verwijderd]

Op donderdag 27 juni 2002 10:16 schreef igmar het volgende:

De bug zit in de S/Key support. Niet meer en niet minder. Aangezien dat op zowat alle systemen uitstaat noem ik dit een storm in een glas water.

De feature wordt door mensen met een clue anders wel gebruikt. Bijv. voor FTP is de S/Key feature bijzonder handy. Als Theo had gezegd: zet allemaal maar ChallengeResponseAuthentication uit wisten kiddies meteen wat ze moesten exploiten en waren er wsch. heel wat meer bakken geroot als dat in deze situatie het geval is, aangezien er een hoop bakken niet remote vuln. waren toen de advisory uitkwam omdat deze admins netjes naar Theo hebben geluisterd en geupdate hebben naar 3.3. En dat is gewoon goed geregeld.

Affected are at least systems supporting s/key over SSH protocol version 2 (OpenBSD, FreeBSD and NetBSD as well as other systems supporting s/key with SSH).

Met recente versie van OpenSSH allemaal vulnerable.

Ik twijfel hier zeer sterk aan. OpenBSD gebruikt BSD Auth, geen PAM. Ze hebben ook nooit PAM gebruikt, dus vanwaar de audit ??

OpenBSD gebruikt inderdaad (IMHO helaas) geen PAM. Waarom ze dat auditen is omdat OpenSSH ook op andere OSen gebruikt wordt dan OpenBSD alleen, en ze een zo veilig mogelijk product willen afleveren.

Dat is speculatie ten top. Het begon met : Alleen 64 bits UNIX is vulnerable, toen zowel 32 + 64, toen was het een root exploit op ALLE unixes, en toen de aap uit de mouw kwam bleek het om S/Key te gaan.

wat bedoel je hiermee? Het is niet alleen S/Key het is ook iig PAM en misschien nog wel meer. PrivSep is iig een extra laagje security voor in de toekomst. Dus upgraden naar 3.4 waar de bugs gefixed zijn en waar je secure met PrivSep kunt vertoeven.

Dat die code buggy was was een jaar geleden al bekend.

Bron? Betwijfel ik toch. Anders had het OpenSSH team er wel naar gekeken. Code wordt ook meerdere keren geaudit door meerdere mensen, dat ook weer om uiteenlopende redenen gebeurd.

Eerst zien en dan geloven. Privilege seperation is ook niet alles, zeker gezien het feit dat root uit een jail kan 'ontsnappen'

Dat verschilt per chroot. Bovendien houdt het iig kiddies met een exploit die op 'hit & run' manier internet danwel individuele bakken scannen wel tegen.

Ik vertrouw meer op grsecurity op een systeem, dat houdt iig de scriptkiddies tegen.

Een chroot ook. Overigens heeft GrSecurity een aantal opties die het ontsnappen uit een chroot bemoeilijkt. Ook kun je een tool als Systrace gebruiken op een OpenBSD bak. En dan heb je nog Stephanie kernel patch voor OpenBSD, die code is echter buggy.

[x-force]

Op donderdag 27 juni 2002 01:51 schreef deadinspace het volgende:

code:

deb http://security.debian.org $DIST/updates main contrib non-free

dit heb ik in mn sources.list

code:

deb http://http.us.debian.org/debian stable main contrib non-free

maar moet ik jouw regel nou toevoegen of mijn regel vervangen?

- edit -
je moest de regel toevoegen ....
maar hij heeft sshd niet geupdate !!

[sorry voor de newbie vraag]

[deadinspace]

Op donderdag 04 juli 2002 20:18 schreef x-force het volgende:
dit heb ik in mn sources.list

code:

deb http://http.us.debian.org/debian stable main contrib non-free

Deze regel is voor 'gewoon' Debian Stable. Je kunt hem eventueel vervangen door

code:

deb http://www.debian.nl/debian stable main contrib

Om van de (snellere) nederlandse mirror gebruik te maken.

code:

deb http://security.debian.org $DIST/updates main contrib non-free

Deze regel is voor de security updates bovenop je gewone distro, waarbij je $DIST vervangt door stable, testing, potato of woody.

maar hij heeft sshd niet geupdate !!

Heb je '$DIST' wel vervangen door 'stable' (in jouw geval)?
Heb je apt-get update; apt-get upgrade gedaan?

[x-force]

ja want hij heeft wel apache, apache-common en pppd vernieuwd.

Maar kan het dus zo zijn dat ik al de goede heb???

[deadinspace]

Wat zegt dpkg -l ssh?

[igmar]

Maak een verschil tussen Apache, en OpenSSH asjeblieft
Apache: eerst 64bit, en daarna (ook) 32 bit systemen
OpenSSH: Root exploit op alles, blijkt een S/Key probleempje

D'r is geen hond die S/Key gebruikt, zeker niet op het Linux platform.

De PAM 'bug' blijkt een overflow in de response check. KbdInteractive kun je gerust uitzetten, tenzij je specifieke PAM modules gebruikt (pam_smxs ofzo).

Het is ook erg afhankelijk van de PAM versie, als er al sprake is van een probleem dan alleen bij specifieke versies.

[igmar]

De feature wordt door mensen met een clue anders wel gebruikt. Bijv. voor FTP is de S/Key feature bijzonder handy.

Mee eens. Ik zou persoonlijk foor FTP SSL gaan, maar da's persoonlijk. Gelukkig gebruik ik RB1 tokens, geen S/KEY.

Als Theo had gezegd: zet allemaal maar ChallengeResponseAuthentication uit wisten kiddies meteen wat ze moesten exploiten en waren er wsch. heel wat meer bakken geroot als dat in deze situatie het geval is,

ChallengeResponse staat in alle sshd_config 's die ik gezien heb uit. Kan wezen dat sommige distribs dit aanzetten, maar dan snap ik de motivering daartoe totaal niet.

aangezien er een hoop bakken niet remote vuln. waren toen de advisory uitkwam omdat deze admins netjes naar Theo hebben geluisterd en geupdate hebben naar 3.3. En dat is gewoon goed geregeld.

Affected are at least systems supporting s/key over SSH protocol version 2 (OpenBSD, FreeBSD and NetBSD as well as other systems supporting s/key with SSH).

Met recente versie van OpenSSH allemaal vulnerable.

Op OpenBSD staat het standaard aan.. De overige BSD's weet ik het van.

OpenBSD gebruikt inderdaad (IMHO helaas) geen PAM. Waarom ze dat auditen is omdat OpenSSH ook op andere OSen gebruikt wordt dan OpenBSD alleen, en ze een zo veilig mogelijk product willen afleveren.

Wat ik dan erg vreemd weet is dat er geen posting is geweest op de PAM mailinglist, en ook de Andrew er niet van op de hoogte is.

wat bedoel je hiermee? Het is niet alleen S/Key het is ook iig PAM en misschien nog wel meer. PrivSep is iig een extra laagje security voor in de toekomst. Dus upgraden naar 3.4 waar de bugs gefixed zijn en waar je secure met PrivSep kunt vertoeven.

Dat het hele verhaal weer eens dik wordt opgeblazen. Daarmee wil ik niet zeggen dat je niet moet upgraden, maar wel dat verhalen met enige regelmaat worden opgeblazen.

Bron? Betwijfel ik toch. Anders had het OpenSSH team er wel naar gekeken. Code wordt ook meerdere keren geaudit door meerdere mensen, dat ook weer om uiteenlopende redenen gebeurd.

De S/KEY code is / was afgeleid van de originele BSD code. BSDi (commerciele fork), en die code bugte als de hel. Het bedrijf waar ik toen stage liep had daarom die code geheel opnieuw geschreven. De huidige code is inderdaad geaudit (zoals met alle OpenBSD code gebeurd), maar niks is waterdicht helaas.

Dat verschilt per chroot. Bovendien houdt het iig kiddies met een exploit die op 'hit & run' manier internet danwel individuele bakken scannen wel tegen.
[..]

Een chroot ook. Overigens heeft GrSecurity een aantal opties die het ontsnappen uit een chroot bemoeilijkt. Ook kun je een tool als Systrace gebruiken op een OpenBSD bak. En dan heb je nog Stephanie kernel patch voor OpenBSD, die code is echter buggy.

Mee eens. Een chroot is echter net de oplossing voor al je securityproblemen, het kan echter goed bijdragen aan het aanzienlijk vermoeilijken van een exploit.

[Verwijderd]

Op zaterdag 06 juli 2002 15:30 schreef igmar het volgende:

Op OpenBSD staat het standaard aan.. De overige BSD's weet ik het van.

Had Theo dan moeten zeggen: standaard is alleen OpenBSD lek. Dan verraad hij toch ook teveel?

Wat ik dan erg vreemd weet is dat er geen posting is geweest op de PAM mailinglist, en ook de Andrew er niet van op de hoogte is.

Dat is wel vreemd ja. Maar ja, de bug zit 'm ook niet in PAM.

Dat het hele verhaal weer eens dik wordt opgeblazen. Daarmee wil ik niet zeggen dat je niet moet upgraden, maar wel dat verhalen met enige regelmaat worden opgeblazen.

Hmm. Het opblazen heeft als effectdat mensen snelgaan updaten. Als Theo specifieker was geweest hadden crackers exploits kunnen coden terwijl er nog geen fix was; lijkt me ook geen prettige situatie. Nu is iedereen netjes op de hoogte. Bovendien: standaard uit != secure. Er zullen dus heus lekke bakken zijn geweest onder FreeBSD bijvoorbeeld ook al staat het standaard uit.

Ik gebruk btw wel PAM in mijn OpenSSH voor: pam_chroot, pam_opie, pam_ldap. Geweldig. Maar ja, op deze manier is het weer wat jammerlijk allemaal

[x-force]

Op zaterdag 06 juli 2002 04:14 schreef deadinspace het volgende:
Wat zegt dpkg -l ssh?

nou ik heb ssh-nonfree

code:

debian:~# dpkg -l ssh-nonfree 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name            Version      Description
+++-===================-===================-======================================================
ii  ssh-nonfree    1.2.27-6.2       a secure replacement for rlogin, rsh, and rcp (NON-FRE

dus praat ik nu helemaal poep dat de bug alleen in de open versie zit? (dus ik geen update hoef te draaien)

[QuarK]

Op zondag 07 juli 2002 21:00 schreef x-force het volgende:

[..]

nou ik heb ssh-nonfree

code:

debian:~# dpkg -l ssh-nonfree 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name            Version      Description
+++-===================-===================-======================================================
ii  ssh-nonfree    1.2.27-6.2       a secure replacement for rlogin, rsh, and rcp (NON-FRE

dus praat ik nu helemaal poep dat de bug alleen in de open versie zit? (dus ik geen update hoef te draaien)

Dit is niet openssh, maar die ssh versie van ssh.com (als ik me niet vergis). Is dus niet kwetsbaar.