Telnet-daemon FreeBSD bevat al twintig jaar groot beveiligingsprobleem

Het opensource-besturingssysteem FreeBSD bevat al twintig jaar een groot beveiligingsprobleem in de telnet-server, waardoor extern root-toegang kan worden verkregen. De bug is mogelijk ook in Mac OS X en Linux-distro's te vinden.

Ontwikkelaars van FreeBSD kondigden het beveiligingsprobleem vlak voor het kerstweekend aan en hebben updates vrijgegeven om het probleem te verhelpen.

Volgens de ontwikkelaars werden ze daartoe gedwongen omdat de bug actief in het wild wordt misbruikt. De bug in de telnet-daemon maakt het mogelijk om extern root-toegang tot een server te krijgen.

De impact van het probleem valt waarschijnlijk mee, omdat gebruik van telnet al jaren wordt afgeraden: ssh is veel betrouwbaarder. Opvallend is wel dat de bug al twintig jaar in de software zit, en dus ook was te misbruiken toen telnet nog wel gangbaar was. Pas in 2001 werd telnet in FreeBSD standaard uitgeschakeld.

Thexploit schrijft dat het gaat om een buffer overflow-kwetsbaarheid, waarbij software de maximale lengte van een string niet goed controleert. Een aanvaller kan daardoor eigen code toevoegen, en in dit geval dus root-toegang krijgen.

Mogelijk is ook Mac OS X kwetsbaar, indien de telnet-daemon is ingeschakeld: uit de broncode van de telnet-client die Apple conform de licentievoorwaarden online heeft geplaatst, blijkt dat deze dezelfde code bevat. Ook de Debian-implementatie van de telnet-daemon was kwetsbaar, maar alleen als het Kerberos-protocol werd gebruikt. Debian wordt net als FreeBSD veel gebruikt in servers en onder meer Ubuntu is op Debian gebaseerd.

Reacties (66)

[iMispel]

Mogelijk is ook Mac OS X kwetsbaar

Het is blijkbaar populair om te zeggen dat Apple systemen een kwetsbaarheid bevatten tegenwoordig, maar in dit geval is niets minder waar: Geen enkel systeem heeft tegenwoordig nog telnet aanstaan (Linux, Mac, Windows,...) Dit is een beetje hetzelfde als zeggen "Windows 98 bevat nieuw ontdekte kwetsbaarheid". Niemand gebruikt het. Sterker nog: Als iemand telnet nu nog had openstaan was dat feit op zich al een groter security risico dan wat nu opgelost is.

Het verbaast me trouwens niet dat er bugs in zitten: Als een programma door bijna niemnd nog gebruikt wordt (of toch zeker niet in omgevingen waar security een issue is), zal er ook niet bijster veel meer op ontwikkelt worden.

_{Wat mij betreft: Iemand die heden ten dage nog telnet gebruikt verdient het gewoon om gehackt te worden}

edit:

OSX is gebaseert op BSD , en die bevat ook elementen van bsd , dus het zou best mogelijk zijn dat OSX ook kwetsbaar is.. Alle software heeft fouten is gewoon heel normaal

Nee! daar doel ik nu net op: Niemand is kwetsbaar behalve de wannabee tweaker die zijn telnet aanlegt. Het komt over alsof er een groot beveilingsprobleem, terwijl dat bijlange zo niet is. Moest deze bug bvb in de SSH code zitten, dan is er een groot probleem.

[Reactie gewijzigd door iMispel op 31 juli 2024 12:28]

[Verwijderd]

[...]

Het is blijkbaar populair om te zeggen dat Apple systemen een kwetsbaarheid bevatten tegenwoordig, maar in dit geval is niets minder waar: Geen enkel systeem heeft tegenwoordig nog telnet aanstaan (Linux, Mac, Windows,...) Dit is een beetje hetzelfde als zeggen "Windows 98 bevat nieuw ontdekte kwetsbaarheid". Niemand gebruikt het. Sterker nog: Als iemand telnet nu nog had openstaan was dat feit op zich al een groter security risico dan wat nu opgelost is.

Het verbaast me trouwens niet dat er bugs in zitten: Als een programma door bijna niemnd nog gebruikt wordt (of toch zeker niet in omgevingen waar security een issue is), zal er ook niet bijster veel meer op ontwikkelt worden.

_{Wat mij betreft: Iemand die heden ten dage nog telnet gebruikt verdient het gewoon om gehackt te worden}

OSX is gebaseert op BSD. Dus OSX bevat ook elementen van BSD , dus het zou best mogelijk zijn dat OSX ook kwetsbaar is.. Alle software heeft fouten is gewoon heel normaal

[Reactie gewijzigd door Verwijderd op 31 juli 2024 12:28]

[ppl]

BSD is heel wat anders als FreeBSD. Wat bij OS X wel zo is, is dat ze voornamelijk de userland van FreeBSD hebben overgenomen (cd, ipfw, etc.).

Bij dit soort systemen staan al dit soort services standaard uit. Zeker tegenwoordig omdat telnet vrijwel niet meer gebruikt wordt. Voor Microsoft dan ook de reden om het maar gewoon in Windows Vista en 7 weg te laten (je moet het nu zelf handmatig installeren, ook wanneer je alleen de client wil). De client wordt vaak nog wel gebruikt om in te loggen op mailservers en hier bepaalde tests op uit te voeren. De security bulleting gaat echter alleen om een vullnerability in telnetd dus de daemon (in dit geval de server) en niet de client.

Of OS X vatbaar is valt te bezien. Ze hebben namelijk niet alle userland spullen overgenomen (in Lion zit wel pf maar in Leopard en Snow Leopard niet terwijl pf wel in FreeBSD zat in die tijd!) en een telnet server aanzetten in OS X is ook vrijwel niet te vinden. Houdt je de client over en die is dus niet kwetsbaar. Nou kun je het wel via Macports, Fink, Homebrew, enz. dit soort dingen installeren maar dat is niet hetzelfde als wat er in FreeBSD zit dus ook hier weer de vraag of je last hebt van die kwetsbaarheid. Roepen dat OS X er mogelijk last van heeft is eigenlijk een schot in het duister. Vergezocht maar niet helemaal ondenkbaar.

Om weer even terug komen op het FreeBSD verhaal: let wel op als je freebsd-update gebruikt om de updates binnen te halen. Het zijn er in totaal 5 stuks waaronder eentje voor libc. Voor wie de sources niet geinstalleerd heeft staan zal bij de libc patch tegen een probleem aan lopen. Hij probeert namelijk iets in /usr/src (de sources dus) te patchen. Als hij niets op die locatie vindt zal hij dat als foutmelding teruggeven en deze patch niet installeren. Helaas blijft de patch nog wel terugkomen wanneer je freebsd-update fetch draait en zal het systeem 'm ook weer willen installeren bij een freebsd-update install. Oplossing is vrij simpel: sources installeren. Voor wie dat niet wil/kan schijnt de directory die hij vraagt aanmaken ook al voldoende te zijn. Zie ook het topic op het FreeBSD forum: with freebsd-update install i get -> libc_dlopen.c: No such file or directory .

[kidde]

Het lijkt er anders zeer sterk op dat ze (Apple) het meeste wel rechtstreeks van Free/OpenBSD hebben overgenomen, kijk maar eens hoe vaak FreeBSD in de code genoemd is:

http://opensource.apple.c...rk_cmds-85/telnetd.tproj/

Hier gaat het echter om het Kerberos protocol, dat is ontwikkeld in Zweden (Heimdal) (GitHub-link) en de cryptografie waar het hier om gaat zo te zien aan MIT.

[ppl]

Ze doen leentjebuur bij voornamelijk FreeBSD wat userland zaken betreft maar vergeet niet dat FreeBSD dit ook doet bij NetBSD, OpenBSD en waar het allemaal mee begon: BSD4.4 zelf. Dat zie je aan de manuals van de diverse tools maar ook aan de manier waarop bepaalde zaken werken. Dat pf verhaal is iets wat ze van FreeBSD hebben overgenomen die het weer van OpenBSD heeft overgenomen want OpenBSD is de geestelijke vader van pf. De kernel van OS X is weer een ander verhaal, dat komt elders vandaan.

Al met al is OS X dus een mix van tools en code die uit diverse hoeken, maar voornamelijk die van BSD en FreeBSD, vandaan is gehaald. Voor veel FreeBSD gebruikers is dit wel de reden geweest om voor hun desktop een Mac te gebruiken. Idem voor andere UNIX(-achtigen) gebruikers. Dit gegeven zorgt er echter ook voor dat je moet oppassen met het wijzen met je vingertje. Het is niet zo dat alles bij FreeBSD vandaan wordt geplukt en dat bugs in FreeBSD dan ook altijd van toepassing zijn op OS X. Het is niet meer dan een mogelijkheid.

[Reactie gewijzigd door ppl op 31 juli 2024 12:28]

[CyBeR]

OSX zou kwetsbaar kunnen zijn, als je de kennis hebt om in OSX telnet aan te zetten. Daar is geen GUI voor namelijk. In de GUI 'remote login' aanzetten, zet SSH aan.

[Reactie gewijzigd door CyBeR op 31 juli 2024 12:28]

[zvbhvb]

ja of nc -l -p 666

[johnkeates]

Dat echo't alleen alle packets op TCP/666 op je huidige terminal... Wat heb je daar aan?

[Alfa1970]

Voor Telnet zie je precies netjes alle wachtwoorden voorbij lopen.. mja, da's niet poort 666...

[Verwijderd]

Ik vraag me af of traditionele bufferoverflows nog te exploiteren zijn. Er zijn tegenwoordig heel veel beschermingen ingebouwd tegen dit soort zaken; non-executable memory ranges (zoals de stack) en random maken van geheugenlayouts, sandboxing e.d.

Daarnaast wordt telnet natuurlijk nauwelijks meer gebruikt. Shell access staat default uit op Mac OS X, en als men het al weet te vinden en weet wat men doet zal men voor ssh kiezen en niet voor telnet.

Dus ja in theorie is het een kwetsbaarheid maar in de praktijk valt het reuze mee.

[zvbhvb]

Bij het gebruik van telnet wordt het wachtwoord in klare text verstuurd. Dat alleen is al een risico.

[kidde]

FTA:

"The timing, to put it bluntly, sucks. ... we try very hard to avoid issuing advisories any time close to holidays ... ... The start of the Christmas weekend -- in some
parts of the world it's already Saturday -- is absolutely not when we want to be
releasing security advisories.

Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd)
is a remote root vulnerability which is being actively exploited in the wild;
bugs really don't come any worse than this."

Maw: Als het zo moeilijk was om te exploiteren hadden ze vast wel tot woensdag 4 januari o.i.d. gewacht.

[Blokker_1999]

Waarom nu weer bashen daarop? De nieuwpost gaat over de BSD telnet client en ook Debian en aanverwanten worden genoemd en dat ene zinnetje haal jij er dan weer uit ...

[El Cid]

Hierboven beweren een aantal mensen dat Telnet niet meer wordt gebruikt. Maar in het artikel staat duidelijk dat de bug in het wild is ontdekt.

[ppl]

Dat is dan mooi verkeerd. De kwetsbaarheid wordt actief misbruikt in het wild wat dan ook de reden is waarom ze bij FreeBSD nu direct met al die updates zijn gekomen. Dat iets in het wild ontdekt wordt is bij security problemen vrij normaal en ook niet de grootste issue. Het daadwerkelijk gebruik maken van zo'n gat in je security is wat alle alarmbellen doet rinkelen en de grootste issue wordt. Dan zul je halsoverkop met updates moeten komen.

[d1ng]

Het blijkt dus dat er mensen/bedrijven zijn die geen encrypted toegang (ssh) toestaan zodat ze alles kunnen 'monitoren'. Dit verklaart dat 'misbruik in the wild'. Zie onderstaand quote uit de mailinglist:

I thought everyone had but an acquaintance explained that he has to run
telnet because his employer doesn't permit any encrypted outside access
so the employer can monitor all traffic.

[Reactie gewijzigd door d1ng op 31 juli 2024 12:28]

[primanocte]

is toch niemand meer die dat gebruikt voor z'n servers neem ik aan?! voor switches ofzo wel.. maar server..

[Verwijderd]

Werd het maar niet voor serveromgevingen gebruikt... ik beheer zelf helaas nog een systeem wat gebouwd is op een 20 jaar oud platform wat bovenop telnet draait. Valt niet te upgraden omdat de client alleen geen veilige protocollen ondersteunt en de client absoluut noodzakelijk is.

Ik denk dat in de zakelijke wereld, waar ook het 54 jaar oude Fortran nog niet uitgeroeid is, er nog echt teveel software met telnet werkt. Patchen dus maar...

[Carda]

ahum, ooit gehoord van ssh tunnels? op de client gewoon te installeren?

[Alfa1970]

Op een 20 jaar oud OS en hoogstwaarschijnlijk net zulke oude hardware?

Ik denk van niet.

[blorf]

Als die handel gewoon op het huidige netwerk zit is het goed te doen. Gewoon de verbinding via een ouwe pc oid sturen die alles wat van die oude computer naar buiten gooit direct een tunnel in stuurt. Tenminste, ik neem aan dat die telnet geen service is die naar buiten open moet staan.
Trouwens, een 20 jaar oud OS waarvan de netwerkstack nog in functie is heeft vast wel ernstigere lekken dan alleen een onbetrouwbare telnetd. Een oude Fortran-versie kan geen kwaad

[Alfa1970]

Wel het zal vast n VAX-VMS systeem zijn, daar zit over het algemeen niet zoveel slechts in, en dan nog zijn er denk ik weinigen die uberhaupt weten hoe ze een dergelijk systeem zouden moeten aanvallen als ze het al kunnen.

De service hoeft niet naar buiten open te staan om misbruikt te kunnen worden, nog steeds vind een groot deel van de hacks op het interne netwerk plaats.

Voor wat Fortran betreft ben ik het met je eens.

[Verwijderd]

Tja, herkenbaar. Firewall ervoor, router erop en alle telnet via vpn's gecontroleerd tunnelen? Dure oplossing, wel veilig.

[Alfa1970]

Fortran mag dan 54 jaar geleden bedacht zijn, maar dat wil niet zeggen dat het al 54 jaar stil staat.

[nasdude]

Een beetje switch doet tegenwoordig ook gewoon ssh hoor, bij mijn cisco stack heb ik telnet zelfs gedisabled

[RedShift]

Zal voor switches waarschijnlijk ook niet van toepassing zijn, tenzij dat ze de code van die telnet daemon ook gebruikt hebben.

[Nactive]

Mijn router draait telnet ... (Al denk ik niet dat hij via het internet benaderbaar is & alleen maar via LAN kant)

[Verwijderd]

Wat een lamme fix trouwens. http://security.freebsd.org/patches/SA-11:08/telnetd.patch

Iemand stuurt duidelijk een bufferoverflow en dan wordt daar practisch niks mee gedaan behalve dan het teveel aan gestuurde informatie negeren.

[arjankoole]

Iemand stuurt duidelijk een bufferoverflow en dan wordt daar practisch niks mee gedaan behalve dan het teveel aan gestuurde informatie negeren.

wat ook prima is om met de teveel aan informatie te doen. Want die hoeveelheid informatie hoort niet, protocol technisch. Discarden is dus een valide methode.

[Verwijderd]

Het discarden moet gebeuren maar ik zou toch graag een log-entry zien.

[Bigs]

Als je 100+ servers beheert kan zo'n log entry je aan je reet roesten Bovendien lijkt het me dat security-minded beheerders telnet sowieso niet aan hebben staan.

[brightvalve]

...uit de broncode van de telnet-client die Apple conform de gpl-voorwaarden online heeft geplaatst...

De code heeft geen GPL-licentie, maar een BSD-licentie (wat, gezien de afkomst, best logisch is )

[kidde]

Welke code?

De telnet daemon heeft idd de BSD licentie (meeste 4-clause, maar er zit ook een stukje OpenBSD 3-clause uit '97 in).

Echter, de client is helemaal niet gelicenseerd onder BSD, maar onder superset APSL;

APSL 2.2 (c):

"(c) If You Externally Deploy Your Modifications, You must make Source Code of all Your Externally Deployed Modifications either available to those to whom You have Externally Deployed Your Modifications, or publicly available. "

[totaalgeenhard]

Hmm..... wel goed dat dit naar buiten is gekomen, zullen alle routers, switches en ander appliances eindelijk standaard SSH gaan krijgen?

[Eric Oud Ammerveld]

Ook ssh kan lekken bevatten.
Als SSH komende 20 jaar niet ontwikkeld wordt is er geheid ook een lek gevonden die root toegang blootstelt na die periode.

[zzattack]

Vier security advisories voor het kerstweekend, dat kunnen ze zelf ook niet leuk gevonden hebben. Heeft iemand een bron over hoezeer de telnet exploit in het wild misbruikt zou worden?

[ppl]

Vijf stuks zelfs en ze waren er zeker niet blij mee omdat het in een tijd zit waarin vrij weinig sysadmins actief zijn. Ze doen dit soort dingen liever op een doordeweekse woensdag zodat het sneller opgemerkt wordt door sysadmins:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

No, the Grinch didn't steal the FreeBSD security officer GPG key, and your eyes
aren't deceiving you: We really did just send out 5 security advisories.

The timing, to put it bluntly, sucks. We normally aim to release advisories on
Wednesdays in order to maximize the number of system administrators who will be
at work already; and we try very hard to avoid issuing advisories any time close
to holidays for the same reason. The start of the Christmas weekend -- in some
parts of the world it's already Saturday -- is absolutely not when we want to be
releasing security advisories.

Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd)
is a remote root vulnerability which is being actively exploited in the wild;
bugs really don't come any worse than this. On the positive side, most people
have moved past telnet and on to SSH by now; but this is still not an issue we
could postpone until a more convenient time.

While I'm writing, a note to freebsd-update users: FreeBSD-SA-11:07.chroot has a
rather messy fix involving adding a new interface to libc; this has the awkward
side effect of causing the sizes of some "symbols" (aka. functions) in libc to
change, resulting in cascading changes into many binaries. The long list of
updated files is irritating, but isn't a sign that anything in freebsd-update
went wrong.

- --
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAk70oKgACgkQFdaIBMps37IsdACgh01CeO+zVGe3o9dn2cLvhh70
ISoAoJCeLUAbJ+0ibyfbVM4fYxpiEfo0
=vt5I
-----END PGP SIGNATURE-----

Directe copy-paste uit de officiële aankondiging.

[deadeyes]

Dit is best wel een onrelevant artikel.

Voor servers ken ik echt wel !niemand! die telnet gebruikt voor login.
Laat staan op FreeBSD specifiek als OS. Als ik me niet vergis komt in de recentere versies (en daarmee spreek ik over FreeBSD 6.x en wrs zelf 5.x en 4.x) geen telnet daemon by default geinstalleerd. De enige reden dat die er nog zou staan en draaien is een luie systeembeheerder.

Verder is ook de bruikbaarheid hiervan eerder beperkt. Telnet is iets dat je niet openzet voor het internet (eigenlijk geen enkel management protocol, zelf niet ssh, daarvoor gebruik je een VPN om en daardoor log je in).

Waar ik het zie gebruikt worden is op switches. Again, als je een deftig architectuur design hebt mag dit op zich geen rechtstreeks probleem zijn (tenzij je netwerk al ergens anders werd gehacked).

Dus de boodschap is gewoon: update.

[zvbhvb]

Waar ik het zie gebruikt worden is op switches. Again, als je een deftig architectuur design hebt mag dit op zich geen rechtstreeks probleem zijn (tenzij je netwerk al ergens anders werd gehacked).

Beter is indien mogelijk met een laptop ter plaatse een of andere terminal applicatie te gebruiken. Of ssh2 en/of een vpn te gebruiken en als het niet anders gaat telnet in te kapselen in een ander protocol dat wel encryptie mogelijk maakt zodat je wachtwoord minder makkelijk gesniffed kan worden.

Dus de boodschap is gewoon: update.

Nee eerder wat je niet hebt kan ook niet aangevallen worden dus deinstalleren of onmogelijk maken dat het opstart.

[jaapio88]

Ligt het aan mij dat ik niet in zie dat een bug van 20 jaar oud gevaarlijk is? Als een bug al 20 jaar bestaat dan was het 20 jaar lang blijkbaar niet intressant om het goed te testen en de verbeteren. Dus waarom dan nu ineens wel?

[iceheart]

omdat de bug nu pas is gevonden. niemand kende deze bug, dus niemand exploiteerde het (hoop je dan). nu is het bekend, en wordt er wel narigheid mee uitgespookt.
als de bug eerder gevonden was was het net zo zeer een priority fix geweest, hoor.

[Proxx]

Volgens de ontwikkelaars werden ze daartoe gedwongen omdat de bug actief in het wild wordt misbruikt.

de bug is dus al eerder gevonden, mensen kende die bug, en het werd geëxploiteerd.
of lees ik nu verkeerd ?

[Q]

Wie anno 2011 een server beheert via telnet verdient het om gehackt te worden.

Echter, wie telnet draait is waarschijnlijk zo 'onverstandig' dat er ook niets relevants te halen valt want zo'n persoon is gewoon te beperkt van verstand om waarde voor andere mensen te kunnen genereren.

Wel is het interessant om met terug werkende kracht hier over na te denken.

Op het moment dat een vulnerability wordt ontdekt is altijd de vraag:

1. hoe makkelijk is deze uit te buiten
2. hoe lang zijn getroffen systemen kwetsbaar geweest

Georganiseerde misdaad en overheden kunnen voldoende middelen vrij maken om gericht naar nieuwe lekken te zoeken om op deze manier stoute dingen te doen. Ik zeg niet dat overheden dat ook doen, maar het is qua resources wel mogelijk.

Dit is echter vooral een issue met productie (web) services. Remote management interfaces hang je natuurlijk niet open en bloot aan het internet, die scherm je af met firewalling/vpn.

Toch?

Toch????

[kidde]

want zo'n persoon is gewoon te beperkt van verstand

Uhm, het gaat hier vziw wel om Kerberos 5, en om dat te draaien moet je volgens mij toch wel enigszins weten waar je mee bezig bent. Dat is nou niet bepaald "peuterspeelgoed".

Denk dat veel "wannabe's" zoals ik het wel eens een keer tegengekomen zijn, en bij het lezen erover halverwege afgehaakt omdat het allemaal best complex is.