[openssh] Nieuwe ssh exploits *UPDATEN!!*

[sphere]

http://groups.google.com/...2maa0%40ifi.uio.no&rnum=3

moet nu naar college, zal kijken of ik straks meer info kan vinden.

[Infern0]

Om deze zogenaamde exploit te voorkomen lijkt het met zoiezo handig om PermitRootLogon uit te zetten. Dit is al standaard zo bij *BSD systemen.

[blaataaps]

sshd is in ieder geval al gepatched, wat er precies aan de hand is, is mij nog niet geheel duidelijk
http://www.freebsd.org/cg...r1=1.1.1.6&r2=1.1.1.7&f=h
http://www.freebsd.org/cg...iff?r1=1.1.1.6&r2=1.1.1.7

[ Voor 20% gewijzigd door blaataaps op 16-09-2003 15:02 ]

[serkoon]

Beter nog: patchen!

http://www.freebsd.org/cg....1.1.6&r2=1.1.1.7&f=h&f=u

[Verwijderd]

maar goed, wat lost die patch op dan.
kan niet opmaken hoe die paar regels een mogelijke exploit voorkomen

[BoAC]

Verwijderd schreef op 16 september 2003 @ 15:48:
maar goed, wat lost die patch op dan.
kan niet opmaken hoe die paar regels een mogelijke exploit voorkomen

Dat de nieuwe buffer grootte niet boven 0xa00000 uit komt wat waarschijnlijk geheugen is waar niet geschreven mag worden

Trouwens geldt dit ook voor mijn linuxbak? (Gentoo)

[ Voor 8% gewijzigd door BoAC op 16-09-2003 15:52 ]

[Arnout]

Verwijderd schreef op 16 September 2003 @ 15:48:
maar goed, wat lost die patch op dan.
kan niet opmaken hoe die paar regels een mogelijke exploit voorkomen

Lijkt me wel... ze passen de check op de grootte van de buffer aan.

[Bigs]

Wat een oplossingen staan er in die thread zeg.. SSH limiten naar known-hosts, SSH in een VPN plaatsen. Dat is voor de meeste SSH-servers volgens mij geen optie (denk aan hosting-bedrijven etc).

[sphere]

code:

iptables -A INPUT -i ppp0 -p tcp -s www.xxx.yyy.zzz --dport ssh -j ACCEPT
iptables -A INPUT --protocol tcp --dport ssh -j DROP

Als je bovenstaande meuk aan je firewall script toevoegt, dan kan je dus hosts specifiek toegang geven en de rest droppen. Hoewel dit misschien niet voor iedereen handig is, kan het voor sommigen een tijdelijke oplossing zijn totdat de package bouwers van de verschillende distros sshd hebben gebakken. Debian woody heeft hem iig nog niet.

EDIT: Hier is een deb voor een geupdate sshd, ik heb hem zelf niet getest. Install at your own risk. Ik ken de gozer wel die hem gebrouwen heeft, maar daar heb jij natuurlijk niets aan.

http://home.o2w.net/~ivo/....woody.1.0.fixed_i386.deb

[ Voor 22% gewijzigd door sphere op 16-09-2003 16:14 ]

[sphere]

quote: http://lists.netsys.com/p...003-September/010146.html

Straight from the horses mouth, this is a snippet of an email conversation I
just had with Theo Deraadt:

--------------
Theo,

Is there a patch available to patch the off-by-one that has been reported in
OpenSSH ? As it is being actively exploited in the wild, I would like to
patch my servers ASAP (as you can probably imagine).

Thankyou for taking the time to read - and hopefully respond to - this email.

Kind regards,

Carl
---------------

A flamefest ensued, but his answer was:

Bugger off, wait like the rest of the planet.

-------------

After more flaming abuse, I received this from him:

I have been spending the last 10 days making openbsd releases for
about 14-15 hours a day for people to use
We've been spending hours and hours making openssh release
We are dealing with an, as far as we know, unexploitable hole
(affects some systems, but not openbsd it is pretty clear) issue
for all of you who run other system
we've been dealing with this frantically
to make something that the internet relies on as good
as good as it possibly can be
no sleep for 30 hours
and you expect me to treat you special?

AND YOU EXPECT ME TO TREAT YOU SPECIAL?

AND YOU THINK THAT PASTING THAT TO SOME IRC CHANNEL MAKES YOU LOOK
RIGHT?

and you think that you pasting it to some icb channel makes me feel
worth less, when every single hp and cisco switch containing this code
is likely vulnerable, and i don't like that, and want to make the
world a better place even if it kills me due to stress and lack of
sleep because i think that a better world is a better place to live
my life?


The main point is that " every single hp and cisco switch containing this code
is likely vulnerable". Oh dear, this could get nasty.. batten down the
hatches...

Poor Theo, he needs his rest.

Carl.

Carl.

Rennuh Theo Arme man zal wel slaap hebben.

[igmar]

sphere2 schreef op 16 september 2003 @ 13:37:
http://groups.google.com/...2maa0%40ifi.uio.no&rnum=3

moet nu naar college, zal kijken of ik straks meer info kan vinden.

Het betreft een remote-root hole in sshd < 3.7, vooropgesteld dat je geen privilege seperation draaid.
De exploit is al beschikbaar, dus ASAP patches.

De patch aan buffer.c werkt NIET op 3.4 / 3.5 releases, dit help elegant je sshd om zeep.

[smoking2000]

Debian stable heeft de nieuwe versie al, unstable/testing in de loop van vanavond volgens Collin Watson (Debian Maintainer)...

dus:
apt-get update; apt-get upgrade

[_JGC_]

Pas op met de woody-proposed-updates mirror die sommigen ook wel gebruiken...

In woody-proposed-updates zit een update voor de keyserver, welke versie 1:3.4p1-1.woody.1 draagt. Deze update draagt de versie 1:3.4p1-1.1, welke dus niet geinstalleerd zal worden in dat geval. Let er dus even op bij het upgraden dat ie daadwerkelijk ssh vervangt.

[Tony Vroon]

Gentoo heeft 'm zojuist toegevoegd:

*openssh-3.7_p1 (16 Sep 2003)

16 Sep 2003; Mike Frysinger <[e-mail]> :
Version bump to fix #28873 ... selinux needs to be caught up though .
Marked stable due to nature of release (security).

[Verwijderd]

igmar schreef op 16 September 2003 @ 17:47:
[...]


Het betreft een remote-root hole in sshd < 3.7, vooropgesteld dat je geen privilege seperation draaid.
De exploit is al beschikbaar, dus ASAP patches.

Hoewel het zeer aannemelijk is dat privilege separation een root compromise voorkomt wordt op full-disclosure toch geclaimd dat privilege separation wel degelijk aanstond op de gehackte servers.

Er zijn berichten dat er exploitcode in het wild is, maar (gelukkig) is de code nog niet te vinden op de gebruikelijke sites.

Verder heb ik in de patch geen verschillen kunnen ontdekken. Ok er wordt een nieuwe unsigned int newlen aangemaakt, maar de struct member alloc was ook al een unsigned int (gedefineerd in buffer.h). Nou ben ik geen C goeroe, dus als iemand wel ziet wat er aan de hand is dan hoor ik het graag.

[Arno]

Zit je nu safe als je UsePrivilegeSeparation aan hebt staan en PermitRootLogin uit

[BoAC]

Tony Vroon schreef op 16 September 2003 @ 19:12:
Gentoo heeft 'm zojuist toegevoegd:

*openssh-3.7_p1 (16 Sep 2003)

16 Sep 2003; Mike Frysinger <[e-mail]> :
Version bump to fix #28873 ... selinux needs to be caught up though .
Marked stable due to nature of release (security).

Ah Ben nu aan het syncen Toch wel handig Gentoo

[Verwijderd]

Verwijderd schreef op 16 September 2003 @ 20:39:
Verder heb ik in de patch geen verschillen kunnen ontdekken. Ok er wordt een nieuwe unsigned int newlen aangemaakt, maar de struct member alloc was ook al een unsigned int (gedefineerd in buffer.h). Nou ben ik geen C goeroe, dus als iemand wel ziet wat er aan de hand is dan hoor ik het graag.

Ik kan toch redelijk goed C coden, maar ik zie ook geen issue, tenminste, niet vanuit de scope in de patch... Ik snap er dan ook geen hout van... .

[edit]
Najah, kijk, als die allocation fout gaat, dan wordt buffer->alloc dus niet geupdate, waarschijnlijk zit daar de issue. Maar ik weet niet wat fatal() doet, 't lijkt me dat die het programma of in elk geval de buffer uitschakelt... . Nogmaals, ik snap de patch nog niet... .

[ Voor 21% gewijzigd door Verwijderd op 16-09-2003 21:06 ]

[Verwijderd]

Dit zegt CERT erover:
If it is possible to exploit this vulnerability in a manner that would allow the execution of arbitrary code then an attacker may be able to so with the privileges of the user running the sshd process, usually root. The impact may be limited on systems using the privilege separation feature available in OpenSSH for some systems.

http://www.kb.cert.org/vuls/id/333628

Geen garanties dus dat je met privilege separation echt veilig bent. Better be safe than sorry, dus patchen lijkt mij een veiliger idee.

[Verwijderd]

Verwijderd schreef op 16 september 2003 @ 21:04:
[...]


Ik kan toch redelijk goed C coden, maar ik zie ook geen issue, tenminste, niet vanuit de scope in de patch... Ik snap er dan ook geen hout van... .

Dan ben je dus niet de enige. Ik kwam er ook al niet uit.

CERT heeft het erover dat er mogelijk teveel gealloceerd geheugen op de heap wordt vrijgegeven:

This vulnerability appears to occur due to some buffer management errors. Specifically, this is an issue with freeing the appropriate memory size on the heap. In certain case the memory cleared is too large and might cause heap corruption.

Ik heb er vanmiddag al met een paar andere mensen kort naar zitten kijken, maar niemand zag het probleem. Hoewel er kleine verschillen in de code zitten is het netto resultaat volgens mij hetzelfde.

[edit]
Welke buffer allocation bedoel je? Die xrealloc? Voor de rest wordt or namelijk geen buffer allocation gedaan. buffer->alloc is een struct variabele.

Zie ook voor meer overzicht:
http://www.freebsd.org/cg...type=text/x-cvsweb-markup
http://www.freebsd.org/cg...type=text/x-cvsweb-markup

[ Voor 20% gewijzigd door Verwijderd op 16-09-2003 21:26 ]

[igmar]

Verwijderd schreef op 16 September 2003 @ 21:04:
Ik kan toch redelijk goed C coden, maar ik zie ook geen issue, tenminste, niet vanuit de scope in de patch... Ik snap er dan ook geen hout van... .

Volgens bronnen zou dit een of-by-one error zijn. De patch fixed iig geen off-by-one error.

[edit]
Najah, kijk, als die allocation fout gaat, dan wordt buffer->alloc dus niet geupdate, waarschijnlijk zit daar de issue. Maar ik weet niet wat fatal() doet, 't lijkt me dat die het programma of in elk geval de buffer uitschakelt... . Nogmaals, ik snap de patch nog niet... .

fatal() zet een message in de logfiles en roept dan wat cleanup routines aan, en beindigd dan het proces. Bovenstaande is de enige logische verklaring die in kon vinden, maar echt snappen doe ik het niet.

[Verwijderd]

Verwijderd schreef op 16 September 2003 @ 21:08:
Welke buffer allocation bedoel je? Die xrealloc? Voor de rest wordt or namelijk geen buffer allocation gedaan. buffer->alloc is een struct variabele.

Nee, de nieuwe waarde in buf->alloc. Die bevat (aangezien buf een pointer is, ga ik er vanuit dat buf in andere delen ook wordt gebruikt) de waarde van de nieuwe size, zelfs als de size te groot is en de routine dus wordt afgebroken in fatal().

[igmar]

Verwijderd schreef op 16 September 2003 @ 21:08:
Dan ben je dus niet de enige. Ik kwam er ook al niet uit.

CERT heeft het erover dat er mogelijk teveel gealloceerd geheugen op de heap wordt vrijgegeven:

Waarschijnlijk zit het zo : buffer->alloc word al geupdate voordat de realloc() wordt gedaan. fatal() doet een aantal cleanups, waaronder de buffers. In dit geval kan er teveel geheugen worden vrijgegeven, omdat buffer->alloc niet overeenkomt met de werkelijke waarde.

This vulnerability appears to occur due to some buffer management errors. Specifically, this is an issue with freeing the appropriate memory size on the heap. In certain case the memory cleared is too large and might cause heap corruption.

Ik heb er vanmiddag al met een paar andere mensen kort naar zitten kijken, maar niemand zag het probleem. Hoewel er kleine verschillen in de code zitten is het netto resultaat volgens mij hetzelfde.

Het enige verschil zit in de het codepath waar de lenges worden geupdate. Ik zie alleen problemen indien de tegenhanger van die alloc alleen naar de lengte kijkt.

[serkoon]

Inderdaad. De buffergrootte wordt bepaalt waarna al dan niet een realloc wordt gedaan (op basis van het feit dat de nieuwe buffergrootte groter is dan 0xa0000 of niet).

Daarna wordt het opgeschoond, waarbij de 'vergrote' buffergrootte wordt gebruikt, ookal is dit helemaal niet gealloceerd (omdat het dus groter was dan 0xa0000). Dit zou dus een off-by-X op kunnen leveren, en dat zou in theorie exploitable kunnen zijn.

[Verwijderd]

Ik heb uit goede bron vernomen dat Privilege Seperation en PermitRootLogin settings hier geen vat op hebben, de sshd blijft sowieso vulnerable. Dit is de nieuwe killer sinds x2 LOL (voor mensen bekend met "l33t 0day" ) Theo zal de frontpage van z'n website weer moeten veranderen... Komt ervan als heel je theorie baseert op het stoppen van ÉÉN enkel soort vulnerability (nl buffer overflows) en een groot deel van de rest over het hoofd ziet.

[serkoon]

Verwijderd schreef op 16 september 2003 @ 22:50:
Ik heb uit goede bron vernomen dat Privilege Seperation en PermitRootLogin settings hier geen vat op hebben, de sshd blijft sowieso vulnerable. Dit is de nieuwe killer sinds x2 LOL (voor mensen bekend met "l33t 0day" ) Theo zal de frontpage van z'n website weer moeten veranderen... Komt ervan als heel je theorie baseert op het stoppen van ÉÉN enkel soort vulnerability (nl buffer overflows) en een groot deel van de rest over het hoofd ziet.

Dat is vooralsnog een rumor. En idd, ookal heb je privsep, dat wil nog niet zeggen dat er geen root te krijgen is. x2 is trouwens niet al te 0-day tegenwoordig

Zullen we eerst maar eens afwachten of de GOBBLES-aapjes met een exploit komen voor OpenBSD? Dan zal het OpenBSD-project vanzelf de counter op de site ophogen. Om daar Theo persoonlijk voor aansprakelijk te stellen is een beetje flauw, imo. Theo heeft dan misschien wel een grote bek, maar om nou elke keer dat er een bug wordt gevonden hem persoonlijk daar op aan te vallen.. Wees blij dat er iig mensen zijn die pro-actief wat aan security proberen te doen (ookal zou ik een sshd door Dan Bernstein meer vertrouwen dan OpenSSH)..

[Wilke]

Bij deze een iets opvallender topictitel

[sphere]

Wilke schreef op 17 september 2003 @ 00:28:
Bij deze een iets opvallender topictitel

Tsk, heb ik me braaf gehouden aan de regels en een beschaafde titel gekozen, prak jij er ff neonverlichting in

[Platypussy]

SuSE heeft de patch ook al klaar liggen, en kan dus met YaST2 worden toegepast

[Jordi]

Exploitable of niet, hier alweer 6 apt-get update && apt-get upgrades en make worlds erop zitten (moest toch nog updaten... this seemed a good time )

[Bigs]

Ik heb mijn FreeBSD ook maar upgedate Kleine moeite dankzij FreeBSD's Security Advisories.

Overigens melden hun ook het volgende:

III. Impact

A remote attacker can cause OpenSSH to crash. The bug is not believed
to be exploitable for code execution on FreeBSD.

[Wilke]

sphere2 schreef op 17 September 2003 @ 00:37:
[...]

Tsk, heb ik me braaf gehouden aan de regels en een beschaafde titel gekozen, prak jij er ff neonverlichting in

Goed hoor

Maar nu we weten dat het echt een nieuwe, en belangrijke exploit is, mag dat/is dat nodig.

Neon? Gelukkig kan er AFAIK geen HTML in topictitels. Javascript zal ook wel tegenvallen

Trouwens, Gentoo en Debian hebben al een update inmiddels

En oh ja: alle tnet servers zijn al lang geupdate hoor Goed bezig Kees

[ Voor 8% gewijzigd door Wilke op 17-09-2003 01:13 ]

[Leon]

Even de Bugtraq postings op een rijtje :

Mandrake
Slackware
Immunix?
Debian
Debian 2
FreeBSD
RedHat
Engarde Secure Linux?
Trustix

Originele posting op openssh.com: hier

edit:

Ik vraag me trouwens wel af of er echt een exploit voor zou zijn, er zijn geruchten. Maar daar heb je niet zo veel aan behalve dat ze paniek zaaien.

[ Voor 26% gewijzigd door Leon op 17-09-2003 18:11 ]

[Verwijderd]

Woei, net nieuwe server geinstalleerd, kan je meteen gaan patchen

[Verwijderd]

Verwijderd schreef op 16 september 2003 @ 22:50:
Ik heb uit goede bron vernomen dat Privilege Seperation en PermitRootLogin settings hier geen vat op hebben, de sshd blijft sowieso vulnerable. Dit is de nieuwe killer sinds x2 LOL (voor mensen bekend met "l33t 0day" ) Theo zal de frontpage van z'n website weer moeten veranderen... Komt ervan als heel je theorie baseert op het stoppen van ÉÉN enkel soort vulnerability (nl buffer overflows) en een groot deel van de rest over het hoofd ziet.

Blaat...

Jij zult nooit het codings niveau van Theo De Raadt in je hele leventje evenaren,
dus ik begrijp niet helemaal waarom jij hem afkraakt?

Voorlopig schijnt deze bug helemaal niet exploitable te zijn op het BSD platform dus hij hoeft de index van www.openbsd.org helemaal niet te veranderen...

En dat commentaar over "Komt ervan als heel je theorie baseert op het stoppen van ÉÉN enkel soort vulnerability" slaat ook al helemaal nergens op.

De theorie achter OpenBSD is correcte code, en niet het ellimineren van 1 soort vuln. Het ellimineren van de onveilige functies is een onderdeel van hun security.

Overal zitten off-by-one's, stackoverflows, formatstrings, dubblefree's in...
En OpenBSD is daar geen uitzondering op...

[CyBeR]

Meanwhile, weet iemand een test hiervoor? Ik heb net m'n sshd weer aan de gang gekregen (hij vindt het niet leuk als /dev/null een html documentje is ), en er een update van debian (unstable) overheen gegooid, maar ik heb dus geen idee of die gepatched is..

Dus als iemand me kan vertellen hoe ik dat kan testen, zou'k fijn vinden (of als je toevallig zeker weet dat de powerpc tree gepatched is, ook goed)

[Lentje]

Hmm, zag dit gister al op slashdot, vond het toen alleen nog een beetje vaag.

Ik heb nu apt-get install ssh gedaan waarbij hij ssh heeft geupgrade. (debian)

Weet iemand of de exploit nu weg is?

[it0]

als het 3.7-p1 was well

[Verwijderd]

Onthoud wel dat Debian een backport heeft gedaan van de securityfix, dus lager dan 3.7.p1 betekent niet automatisch dat je vulnerable bent. Kijk even in de Debian advisory naar welke versie ze updaten.

http://www.debian.org/security/2003/dsa-382

[ Voor 14% gewijzigd door Verwijderd op 17-09-2003 09:12 ]

[Erkens]

Leon schreef op 17 september 2003 @ 01:15:
Even de Bugtraq postings op een rijtje :

Slackware

hmm

Updated package for Slackware 8.1:
ftp://ftp.slackware.com/p.../openssh-3.7p1-i386-1.tgz

die url is niet te bereiken, ook met de mirror's kan ik die file niet vinden?

edit:

nu was die wel te downen
gepatched iig

[ Voor 7% gewijzigd door Erkens op 17-09-2003 17:13 ]

[RvdH]

SSH-2.0-OpenSSH_3.7.1p1
Is deze versie veilig?
Zo ja, dan is die te downloaden vanaf ftp://mirror.widexs.nl/pub/OpenSSH/portable/ .

[ Voor 48% gewijzigd door RvdH op 17-09-2003 09:30 ]

[DDX]

huh heb je net 3.7 installed op tig machines
komt er een 3.7.1 uit

ARGH

uit release notes :

OpenSSH 3.7 fixed one of these bugs.

OpenSSH 3.7.1 fixes more similar bugs.

[ Voor 42% gewijzigd door DDX op 17-09-2003 09:50 ]

[Eärendil]

Er is weer een nieuwe versie: 3.7.1p1

Dit heeft openssh.org er over te zeggen:

code:

20030917
 - (djm) OpenBSD Sync
   - [e-mail] 2003/09/16 21:02:40
     [buffer.c channels.c version.h]
     more malloc/fatal fixes; ok millert/deraadt; ghudson at MIT.EDU
 - (djm) Crank RPM spec versions
 - (djm) Release 3.7.1p1

20030916
 - (dtucker) [acconfig.h configure.ac defines.h session.c] Bug #252: Retrieve
   PATH (or SUPATH) and UMASK from /etc/default/login on platforms that have it
   (eg Solaris, Reliant Unix).  Patch from Robert.Dahlem at siemens.com.  
   ok djm@
 - (bal) OpenBSD Sync
   - [e-mail] 2003/09/16 03:03:47
     [buffer.c]
     do not expand buffer before attempting to reallocate it; markus ok
 - (djm) Crank spec versions
 - (djm) Banish (safe) sprintf from auth-pam.c. Patch from bal
 - (tim) [configure.ac] Fix portability issues.
 - (djm) Release 3.7p1

Gentoo heeft al een update

[el_salvador]

ook leuk, wil je gaan updaten, schijf brak... stukje dmesg voor de liefhebbers:

code:

hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=146127, sector=146064
end_request: I/O error, dev 03:01 (hda), sector 146064
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of
 [19281 19990 0x0 SD]
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=146127, sector=146064
end_request: I/O error, dev 03:01 (hda), sector 146064
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of
 [19281 19288 0x0 SD]
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=146127, sector=146064
end_request: I/O error, dev 03:01 (hda), sector 146064
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of 
[19281 19282 0x0 SD]
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=146127, sector=146064
end_request: I/O error, dev 03:01 (hda), sector 146064
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data of
 [19281 19283 0x0 SD]

ik probeer dus een rpm te installen, maar (verrassing) hij knalt eruit met i/o errors. ik besef natuurlijk ook wel dat die schijf is overleden, maar is er in de tussentijd nog een workaround oid? nieuwe hda is in bestelling

[ Voor 2% gewijzigd door el_salvador op 17-09-2003 10:21 . Reden: layout ont-verneukt ]

[RvdH]

Rebooten, en hopen dat ie weer accessible is

[Lentje]

Oke bedankt.

Heb voor de zekerheid maar de debian package die in de security posts stond aangegeven als de versie met de bugfix geinstalleerd.

[sphere]

ATTENTIE: NA DE EERSTE EXPLOIT IN DE STARTPOST, WAS ER EEN TWEEDE EN NU OOK EEN DERDE! STUG BLIJVEN UPDATEN

-------klik-------

[aKra]

code:

SSH-2.0-3.2.5 SSH Secure Shell (non-commercial)

Is toch niet vulnerable?

[ Voor 4% gewijzigd door aKra op 17-09-2003 18:41 ]

[Verwijderd]

sphere2 schreef op 17 September 2003 @ 18:28:
ATTENTIE: NA DE EERSTE EXPLOIT IN DE STARTPOST, WAS ER EEN TWEEDE EN NU OOK EEN DERDE! STUG BLIJVEN UPDATEN

Schat, een exploit is dat er code is die er misbruik van maakt... Dit is gewoon een bug, geen exploit. .

[CyBeR]

aKra schreef op 17 september 2003 @ 18:30:

code:

SSH-2.0-3.2.5 SSH Secure Shell (non-commercial)

Is toch niet vulnerable?

de niet-open ssh heeft weer een hele zooi andere exploitable bugs

[aKra]

CyBeR schreef op 17 september 2003 @ 18:43:
[...]


de niet-open ssh heeft weer een hele zooi andere exploitable bugs

Ja, dat zal best, maar elke daemon heeft wel wat... Tot nu toe komen ze alleen echt uit voor OpenSSH .

Wat ik erger vind, als ik OpenSSH installeer kan ik geen SSH connectie openen, op elk account is het password verkeer

[T-Blizzard]

emerge rsync
emerge world

[ Voor 31% gewijzigd door T-Blizzard op 17-09-2003 18:48 ]

[CyBeR]

aKra schreef op 17 September 2003 @ 18:47:
[...]


Ja, dat zal best, maar elke daemon heeft wel wat... Tot nu toe komen ze alleen echt uit voor OpenSSH .

Wat ik erger vind, als ik OpenSSH installeer kan ik geen SSH connectie openen, op elk account is het password verkeer

PAM support meecompilen, pruts0r

[aKra]

PAM support meecompilen in OpenSSH...... Beetje dom als ze dat er niet standaard bij pleuren zeg...

(Wat zijn nou eigenlijk de extra's van OpenSSH tegenover SSH?)

[ Voor 25% gewijzigd door aKra op 17-09-2003 18:52 ]

[imdos]

(Wat zijn nou eigenlijk de extra's van OpenSSH tegenover SSH?)

Meer bugs

En het is een open protocol en dus door iedereen te bezichtigen

[Verwijderd]

helemaal offtopic.. maar op /. is tien minuten geleden het volgende gepubliceerd:

"On the footsteps of openssh, Sendmail 8.12.10 has just been released due to a buffer overflow in address parsing. Sendmail states this is potentially remotely exploitable. No updates on the Sendmail site yet, but the FTP site has the release notes."

[ Voor 5% gewijzigd door Verwijderd op 17-09-2003 20:21 ]

[Mior]

Ik kreeg net een mailtje van het Slackware Security Team:

[slackware-security] OpenSSH updated again (SSA:2003-260-01)

Upgraded OpenSSH 3.7.1p1 packages are available for Slackware
8.1, 9.0 and -current. These fix additional buffer management
errors that were not corrected in the recent 3.7p1 release.
The possibility exists that these errors could allow a remote
exploit, so we recommend all sites running OpenSSH upgrade to
the new OpenSSH package immediately.

Weer updaten

edit: aw, was al gepost zie ik.

[ Voor 4% gewijzigd door Mior op 17-09-2003 21:22 ]

[aKra]

imdos schreef op 17 September 2003 @ 19:35:
[...]


Meer bugs

En het is een open protocol en dus door iedereen te bezichtigen

Maar niet sneller of iets dergelijks?

Phantom schreef op 17 september 2003 @ 21:10:
Ik kreeg net een mailtje van het Slackware Security Team:


[...]


Weer updaten

edit: aw, was al gepost zie ik.

root@osiris:~/sendmail-8.12.10# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 osiris.getfragged.nl ESMTP Sendmail 8.12.10/8.12.6; Wed, 17 Sep 2003 21:25:22 +0200
quit
221 2.0.0 osiris.getfragged.nl closing connection
Connection closed by hoer.
root@osiris:~/sendmail-8.12.10#

Hier al gefixed

[ Voor 56% gewijzigd door aKra op 17-09-2003 21:26 ]

[Mior]

Mijn post ging over openssh hoor, niet over sendmail

[Erkens]

Phantom schreef op 17 September 2003 @ 22:20:
Mijn post ging over openssh hoor, niet over sendmail

ehm, betekend dat dat ik weer opnieuw openssh moet patchen

[Mior]

Als je versie 3.7.1p1 nog niet hebt wel ja.

[CyBeR]

Erkens schreef op 17 September 2003 @ 22:23:
[...]

ehm, betekend dat dat ik weer opnieuw openssh moet patchen

dat betekent dat akra de verkeerde quote

[Jaap-Jan]

Op router (Debian 3.0 "Woody") heb ik apt-get update && apt-get upgrade gedraaid, versie 3.6.1p1-1, maar hij wil niet automatisch updaten naar 3.4p1-1.woody.2, dan maar ff handmatig downloaden en installeren. Waarom is men overgestapt naar .woody.* en is het niet gewoon i.p.v. -1 -2 geworden?

Nu ja, de zooi is weer gepatcht geüpdate.

[ Voor 6% gewijzigd door Jaap-Jan op 17-09-2003 22:26 ]

[Erkens]

Phantom schreef op 17 September 2003 @ 22:24:
Als je versie 3.7.1p1 nog niet hebt wel ja.

nee ok, ik dacht dat die patch dus niet goed was
maar mijn slackware bakken zijn dus wel gepatched (en gelijk maar even van de gelegenheid gebruik gemaakt om PermitRootLogon uit te zetten )

[HunterPro]

Ehm heren...

According to an OpenSSH [1] Security Advisory [0], 2nd revision, all versions of OpenSSH's sshd(8) prior to version 3.7.1 contain buffer management errors. The discovery of additional similar errors by Solar Designer show that version 3.7.1 is affected, too.

bron

met andere woorden: er zit nóg een gat in?

[ Voor 3% gewijzigd door HunterPro op 17-09-2003 23:45 ]

[Verwijderd]

Erkens schreef op 17 September 2003 @ 22:26:
[...]

nee ok, ik dacht dat die patch dus niet goed was
maar mijn slackware bakken zijn dus wel gepatched (en gelijk maar even van de gelegenheid gebruik gemaakt om PermitRootLogon uit te zetten )

Sorry dat ik het zeg, maar iemand die slackware "bakken" heeft, mag toch wel van te voren over dit soort dingen nadenken en zo veel mogelijk aan veiligheid doen.

[Kippenijzer]

Wel cute, om zeker te zijn dat er niets misgaat telnet via het interne netwerk op de colo enablen, daarover inloggen via de andere bak, ssh uit, ssh updaten, weer ssh inloggen, telnet weer uitzetten en weer blocken en dan voor de andere server zelfde process omgedraaid.... Lekker omslachtig... Leve slackware, dat wel, maar jah, da's niet de scope van dit topic ;P

[DDX]

HunterPro schreef op 17 September 2003 @ 23:39:
Ehm heren...


[...]

bron

met andere woorden: er zit nóg een gat in?

tjeesz

3.7.2 soon... ?

nee gaat echt lekker...

[Leon]

Kun je niet gewoon naar een computer die geupdate moet worden, ssh'en. ssh updaten, en dan sshd restarten

afaik verwijderd linux bestanden pas als ze niet meer gebruikt worden door een actief programma.

[ Voor 9% gewijzigd door Leon op 18-09-2003 00:42 ]

[DDX]

Leon schreef op 18 September 2003 @ 00:42:
Kun je niet gewoon naar een computer die geupdate moet worden, ssh'en. ssh updaten, en dan sshd restarten

afaik verwijderd linux bestanden pas als ze niet meer gebruikt worden.

tuurlijk gaat 99% van de keren goed
maar ja de keer dat het mis gaat...
mag je weer naar de colo...

[FCA]

Ziet eruit alsof ik weer kan gaan updaten ja.
Ik heb de src.rpm van Redhat bekeken, en er zat nog een extra patch in, die appliede...
patch op http://fca.shacknet.nu/fi...-3.6.1p2-owl-realloc.diff te bekijken.

Deze patch appliede op openssh 3.7.1_p1, dat is dus de nieuwste "officiële" versie.

Advisory voor bugs in 3.7.1p1:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0682

[ Voor 33% gewijzigd door FCA op 18-09-2003 01:32 ]

[Infern0]

Je kunt toch gewoon ssh herstarten zonder de huidige ssh te stoppen.
#kill -HUP `cat /var/run/sshd.pid`
probeer nieuwe connectie te maken met server, werkt het, dan is alles ok en dien je de huidige ssh sessie af te sluiten. Dit werkt hier onder OpenBSD en FreeBSD oerfect.

[DDX]

rlensen schreef op 18 September 2003 @ 01:49:
Je kunt toch gewoon ssh herstarten zonder de huidige ssh te stoppen.
#kill -HUP `cat /var/run/sshd.pid`
probeer nieuwe connectie te maken met server, werkt het, dan is alles ok en dien je de huidige ssh sessie af te sluiten. Dit werkt hier onder OpenBSD en FreeBSD oerfect.

ja dat werkt hier ook prima
vandaag die 99%
tis 1 keer mis gegaan bij mij, was toen op dat moment even een link wegveel oid
iig was mijn connectie met server toen dood
gelukkig draaide op die bak ook telnet

[BoAC]

DDX schreef op 18 September 2003 @ 07:48:
...
gelukkig draaide op die bak ook telnet

Wat is dan het nut van ssh
Herstart van sshd tijdens een ssh-sessie ging hier ook perfect dus ..

[DDX]

BoAC schreef op 18 september 2003 @ 09:40:
[...]

Wat is dan het nut van ssh
Herstart van sshd tijdens een ssh-sessie ging hier ook perfect dus ..

eh dat je secure kan connecten
maar met telnet server draaien is opzich toch niks mis ?

[Mior]

DDX schreef op 18 September 2003 @ 09:58:
maar met telnet server draaien is opzich toch niks mis ?

Behalve dan dat je wachtwoorden enzo un-encrypted over de lijn vliegen

[DDX]

Phantom schreef op 18 september 2003 @ 10:01:
[...]

Behalve dan dat je wachtwoorden enzo un-encrypted over de lijn vliegen

nooit gehoord van telnet doen via machine in zelfde subnet ?
ok laatste stukje is un-encrypted...

[Erkens]

Verwijderd schreef op 18 September 2003 @ 00:15:
[...]



Sorry dat ik het zeg, maar iemand die slackware "bakken" heeft, mag toch wel van te voren over dit soort dingen nadenken en zo veel mogelijk aan veiligheid doen.

ehm, is slackware dan veel onveiliger dan andere distro's?
Dat je juist BIJ slackware om veiligheid moet denken
Daarnaast zijn dit gewoon mijn servertjes thuis aan een chello lijntje. En de gemiddelde scriptkiddie die langskomt kan er niets mee
Overigens logde ik gewoon altijd in als root als dat nodig was, een wachtwoord is een wachtwoord, of die nu van een user root is of van een ander. Maar dat is hier totaal offtopic, het ging hier om ssh die gepatched moest worden. En dat heb ik gewoon gedaan, ik zie je probleem niet?

[_-= Erikje =-_]

dus na inloggen over telnet direct je passwd's veranderen via ssh natuurlijk

[Mior]

Dat neemt nog niet weg dat telnet un-encrypted is.

Als je alleen lokaal je server wilt beheren is het nog wel verantwoord, maar als je via het internet op je server wilt is telnet eigenlijk geen optie meer.

Erkens schreef op 18 September 2003 @ 10:06:
Overigens logde ik gewoon altijd in als root als dat nodig was, een wachtwoord is een wachtwoord, of die nu van een user root is of van een ander.

Ooit van 'brute force cracking' gehoord? User 'root' is een acccount die _altijd_ op een linux server bestaat. Een cracker weet dus waar hij moet beginnen. Als je root login uitzet, en inlogt via een username wordt dat al een stuk moeilijker.

[ Voor 58% gewijzigd door Mior op 18-09-2003 10:13 ]

[Verwijderd]

Gewoon zorgen dat je sshd ook ff op een ander poortje spawned.. dan de huidige kill HUP'en.. heb je nog steeds verbinding, mooi zo. indien niet, dan ff connecten op die andere en sshd opnieuw draaien.. like taking candy from a beebee

edit: ohja hehe zorg wel dat het poortje waar je die tijdelijke sshd laat draaien niet gefirewalled is.. staat anders zo lullig

[ Voor 24% gewijzigd door Verwijderd op 18-09-2003 10:14 ]

[Erkens]

Phantom schreef op 18 september 2003 @ 10:07:
Ooit van 'brute force cracking' gehoord? User 'root' is een acccount die _altijd_ op een linux server bestaat. Een cracker weet dus waar hij moet beginnen. Als je root login uitzet, en inlogt via een username wordt dat al een stuk moeilijker.

brute force
laat me niet lachen, dat duurt jaren met een chello lijn zeker met mijn passwords (die regelmatig veranderen)

[ Voor 7% gewijzigd door Erkens op 18-09-2003 10:50 ]

[Mior]

Tja

_{(Security Through Obscurity)}

[Erkens]

Phantom schreef op 18 September 2003 @ 11:15:
Tja

_{(Security Through Obscurity)}

mja, ik heb die settings toch veranderd nu?
alleen de usabillity is nu enorm gedaald.
Ik patch normaal gesproken vrijwel altijd, firewall blokt alles behalve een paar portmappings etc.
maar ik wil nu niet verder offtopic te gaan, als je verder wilt discussieren hierover open je een nieuw topic en wijs je me ernaar toe
_{(aangezien ik eik niet in NOS mag komen van moto-moi )}

[Bor]

Leon schreef op 17 september 2003 @ 01:15:

edit:

Ik vraag me trouwens wel af of er echt een exploit voor zou zijn, er zijn geruchten. Maar daar heb je niet zo veel aan behalve dat ze paniek zaaien.

De eploit is er, en ik hoorde dat ie vanavond nog beschikbaar wordt voor het grote publiek. Hou packetstorm in de gaten.

[DDX]

Phantom schreef op 18 September 2003 @ 10:07:
Ooit van 'brute force cracking' gehoord? User 'root' is een acccount die _altijd_ op een linux server bestaat. Een cracker weet dus waar hij moet beginnen. Als je root login uitzet, en inlogt via een username wordt dat al een stuk moeilijker.

offtopic:
heet jouw root account dan nog root ?
(hier wel trouwens, maar admin user op windows heet geen admin meer)

[Mior]

DDX schreef op 18 September 2003 @ 11:30:
heet jouw root account dan nog root ?

Ja.

root mag toch niet direct inloggen remote, en als een cracker eenmaal ingelogd is heeft het renamen van de root account toch geen enkel nut.

Maar volgens mij raken we een beetje offtopic

[_JGC_]

DDX schreef op 18 September 2003 @ 11:30:
[...]

offtopic:
heet jouw root account dan nog root ?
(hier wel trouwens, maar admin user op windows heet geen admin meer)

Ik zou het maar niet in mn hoofd halen om dat te veranderen

* _JGC_ denkt terug aan die tijd dat ie "slay" draaide op een RH machine waarbij root gerenamed was naar iets anders... studroot in dat geval.

$ slay studentje
slaying all processes for user studroot
connection closed by remote host

* _JGC_ hollen naar serverhok

[Verwijderd]

Erkens schreef op 18 september 2003 @ 10:06:
[...]

ehm, is slackware dan veel onveiliger dan andere distro's?
Dat je juist BIJ slackware om veiligheid moet denken

Veiligheid is iets dat in handen van de admin ligt. Een RedHat/Mandrake machine in handen van een goede sysadmin is veiliger dan een Debian/Slackware machine in handen van een mindere sysadmin.
SSH heeft standaard root-logins aan staan. Niks mis mee in een trusted environment natuurlijk, maar een extra laagje beveiliging is nooit weg

Daarnaast zijn dit gewoon mijn servertjes thuis aan een chello lijntje. En de gemiddelde scriptkiddie die langskomt kan er niets mee

Zodra jij services draait, die voor de buitenwereld benaderbaar zijn en deze services niet onder een unpriviliged account draaien binnen een chroot-jail, kun je de uitspraak niet doen.

Overigens logde ik gewoon altijd in als root als dat nodig was, een wachtwoord is een wachtwoord, of die nu van een user root is of van een ander. Maar dat is hier totaal offtopic, het ging hier om ssh die gepatched moest worden. En dat heb ik gewoon gedaan, ik zie je probleem niet?

Goh, wat zou het verschil toch zijn als iemand binnenkomt via ssh en je mag niet als root inloggen? (even een exploit daargelaten) Als ze als user erkens binnenkomen, kan men je ~ verwijderen, maar moet men nog altijd root-rechten zien te verkrijgen en die zitten weer achter een wachtwoord Daarnaast zorg je ervoor dat alleen een bepaalde groep mag su-en naar root en je maakt het weer wat veiliger.

Maar goed, is allemaal redelijk offtopic

[Bananenplant]

hmmmmz..... nog steeds geen update voor debian testing...

* Bananenplant begint zich zorgen te maken met 3.6.1p2-3

[Verwijderd]

En dat is je goed recht ucchan, want 3.6.1p2-3 is vulnerable...
Ik draai debian sid, en heb net geupdate naar 3.6.1p2-8.
Good luck, en hou tripwire in de gaten :-)

[DDX]

ucchan schreef op 18 september 2003 @ 18:42:
hmmmmz..... nog steeds geen update voor debian testing...

* DDX begint zich zorgen te maken met 3.6.1p2-3

waarom compile je dan niet zelf 3.7.1 ?

ook zo weird trouwens dat redhat enzo 3.4 patchen steeds
waarom niet gewoon 3.7.1
en nou niet aankomen met 100% tested, dat zijn die patches ook niet die redhat er steeds bij gooit

[CyBeR]

DDX schreef op 18 September 2003 @ 19:54:
[...]


waarom compile je dan niet zelf 3.7.1 ?

Een samengesteld woord: Packagemanagement.

(Al kun je natuurlijk ook een eigen package van 3.7 maken, zo groot is het probleem nou ook weer niet)

[_JGC_]

Topic for #debian is Possible remote *ROOT* ssh vulnerability in the wild, fix for woody (stable) is available now from security.debian.org (3.4p1-1.woody.2) and in sid (unstable) (3.6.1p2-8). For sarge (testing), use woody's or backport sid's yourself

Dus woody zn SSH installeren of de versie van sid backporten naar sarge. Denk dat je het eerste makkelijker zult vinden

[Robtimus]

DDX schreef op 18 September 2003 @ 19:54:
[...]


waarom compile je dan niet zelf 3.7.1 ?

ook zo weird trouwens dat redhat enzo 3.4 patchen steeds
waarom niet gewoon 3.7.1
en nou niet aankomen met 100% tested, dat zijn die patches ook niet die redhat er steeds bij gooit

Op www.openssh.org zijn SRPMS van 3.7.1 te vinden (oa ftp://ftp.easynet.be/open...openssh-3.7.1p1-1.src.rpm). Even rpmbuild --rebuild openssh-3.7.1p1-1.src.rpm, daarna de gecreerde packages installeren en klaar.

[Johannes]

ucchan schreef op 18 September 2003 @ 18:42:
hmmmmz..... nog steeds geen update voor debian testing...

* Johannes begint zich zorgen te maken met 3.6.1p2-3

Aangezien ssh nog 1 RC bug heeft, zal er eerst nog een nieuwe release in unstable moeten komen om ssh weer in testing te krijgen. Dan nog twee dagen wachten (met urgency=high), en dan ben je weer veilig. Tsja, testing wordt duidelijk niet ondersteund door het Security-team.

Wees trouwens blij dat Anthony Towns heeft besloten dat glibc ondanks 6 RC bugs in testing gaat: anders had je ook nog eens kunnen wachten totdat deze allemaal gefixed waren (ssh heeft een dependency op glibc).

[Bananenplant]

okay, hoe zorg ik er nu voor dat de ssh van sarge niet teruggezet wordt ? ik wil wel andere dingen kunnen updaten natuurlijk !

[terabyte]

ucchan schreef op 18 september 2003 @ 18:42:
hmmmmz..... nog steeds geen update voor debian testing...

* terabyte begint zich zorgen te maken met 3.6.1p2-3

Dat is een eigenschap van testing, deze wordt volgens mij 1x per 2 weken (??) geupdate, en dat geldt ook voor security fixes.

[serkoon]

Phantom schreef op 18 September 2003 @ 10:01:
[...]

Behalve dan dat je wachtwoorden enzo un-encrypted over de lijn vliegen

En da's dus niet zo Telnet doet (iig op FreeBSD) tegenwoordig ook gewoon encryptie. Telnet zou best wel eens een stuk veiliger kunnen zijn dan dat immer lekke OpenSSH

[Johannes]

ucchan schreef op 18 september 2003 @ 20:42:
okay, hoe zorg ik er nu voor dat de ssh van sarge niet teruggezet wordt ? ik wil wel andere dingen kunnen updaten natuurlijk !

Pinning. Dit is misschien een makkelijkere uitleg.