Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 115 reacties

Verschillende Linux-distributies hebben in de afgelopen dagen updates uitgebracht voor lekken in de network time protocol daemon. Onder andere Red Hat, Ubuntu en Debian hebben de lekken gedicht.

Afgelopen weekend werden de details van vier kwetsbaarheden in network time protocol daemon bekendgemaakt door US-Cert. De lekken waren aangetroffen door Googles securityteam en betroffen onder andere de random number generator. Vooral de mogelijkheid buffer overflows te veroorzaken maakte dat er sprake was van een ernstige kwetsbaarheid: hiermee kunnen kwaadwillenden code uitvoeren op getroffen systemen.

Alle voorgaande versies van ntp4 zijn kwetsbaar en op 19 december kwam versie 4.2.8 uit die de problemen aanpakte. Apple bracht dinsdag een automatische update met die versie uit om het lek in OS X te dichten maar voor die tijd publiceerden verschillende Linux-distro's al hun patches.

Zo bracht Canonical maandag Security Notice USN-2449-1 uit die Ubuntu 14.10, Ubuntu 14.04 LTS, Ubuntu 12.04 LTS en Ubuntu 10.04 LTS bijwerkt. Debian publiceerde afgelopen weekend DSA-3108 om de problemen aan te pakken en ook Red Hat was er snel bij met zijn RHSA-2014:2025-1-security update voor ntp. De volledige lijst van mogelijk getroffen software is te vinden bij de Vulnerability Notes Database van Cert.

OpenBSD is niet kwetsbaar, zo tekent Theo de Raadt, oprichter van het OS, aan, omdat de software gebruikmaakt van openntpd. "Dat is 10 jaar geleden op mijn verzoek geschreven omdat de broncode van ntpd ons de stuipen op het lijf joeg", aldus De Raadt. Er zou veel overbodige code in gestaan hebben en het ontwikkelteam zou weinig interesse in verbetering getoond hebben. "Wanneer worden softwareleveranciers nu eens wakker?", vraagt hij zich af.

Moderatie-faq Wijzig weergave

Reacties (115)

Ik kan iedereen momenteel aanraden die iets met netwerk of serverbeheer doet om even goed na te gaan of hardware NTP Appliances van bijvoorbeeld Microsemi of Meinberg hier ook vatbaar voor zijn. Dit soort devices worden namelijk in een groot netwerk snel vergeten of over het hoofd gezien.

Meinberg heeft inmiddels al een security advisory op hun site staan:

http://www.meinbergglobal...e-ntp-vulnerabilities.htm

[Reactie gewijzigd door Stacheldraht op 23 december 2014 16:39]

"Dat is 10 jaar geleden op mijn verzoek geschreven omdat de broncode van ntpd ons de stuipen op het lijf joeg", aldus De Raadt. Er zou veel overbodige code in gestaan hebben en het ontwikkelteam zou weinig interesse in verbetering getoond hebben. "Wanneer worden softwareleveranciers nu eens wakker", vraagt hij zich af.
Dit is nu iemand met verstand van zaken. Veel anderen roepen het is open source dus het is veilig, dat werk. Deze man inspecteert de code werkelijk om vervolgens tot de conclusie te komen dat het een rommeltje is en dus een verbetering moet worden aangebracht.
Het zou netter geweest zjn als hij geholpen had de huidige code beter te maken in plaats van een fork/alternatief te (laten) ontwikkelen. Nu heb je in princiepe 2 codebases die hetzelfde eindresultaat hebben.
Dat kan alleen als beide projecten het zelfde doel hebben. Dat is niet het geval. Het ene project wil altijd alles doen:
  • heeft het OS/netwerk geen bescherming tegen MITM, dan stoppen we het toch in NTP;
  • heeft het OS/netwerk geen authenticatie, dan stoppen we het toch in NTP;
  • beheer moet remote kunnen, en remote client info uit kunnen lezen;
  • als de tijd een paar microseconde nauwkeuriger kan, dan doen ze dat.
Het andere project wil veilig tijd kunnen synchroniseren:
  • bescherming tegem MITM is een taak voor IPSEC
  • bescherming tegen DNS injection is een taak voor DNSSEC
  • beheer doe je vanaf de command line;
  • een paar miliseconde is nauwkeurig genoeg.
Het gevolg is dat de codebase van NTP ongeveer 66 maal zo groot is als die van OpenNTPD. Welke codebase zou het beste gereviewed zijn door de white hats?
Ik meen me wel te herrineren dat OpenNTPD hun tijd niet drift (klok versnellen, vertragen) maar gewoon herzet (zoals ntpdate). Waardoor het dus een seesaw patroon kan introduceren en je logs niet helemaal te vertrouwen zijn wegens verspringende tijden.
Ik heb het zojuist opgezocht in de man page en het verschilt afhankelijk van de afwijking. Ook kun je een optie meegeven om dit gedrag aan te passen.

Bij een afwijking die groter is dan 128 ms verspringt de tijd inderdaad, maar dan heb je sowieso al een probleem (gehad) met je systeemtijd.
Je zou toch stellen dat 3, 4 en 5, 6 en 8 combineren tot wat we nodig hebben. Draait het project rond NTP en tijd, de rest doe je ergens anders in je stack.

[Reactie gewijzigd door analog_ op 23 december 2014 23:27]

Er zou veel overbodige code in gestaan hebben en het ontwikkelteam zou weinig interesse in verbetering getoond hebben.
Moeten ze wel meewerken.
Je leest hier natuurlijk maar een kant van het verhaal he. Je weet niet hoe hij het aangeboden heeft. Sommige ontwikkelaars zijn geniaal maar mensenkenis hebben ze niet.
Of je doet het zelf door de boel te forken en de fork wel te patchen. Vrijheid blijheid in opensource land :)
Soms is competitie ook goed voor projecten natuurlijk. En als de huidige beheerders geen interesse tonen in voorstellen voor verbeterting in de code (volgens de lijnen van wat jij een verbetering vindt; de beheerders kunnen daar natuurlijk anders over denken!) dan ligt het voor de hand dat je dan maar je eigen gang gaat.
Tsja, in sommige gevallen is 'de huidige code beter maken' geen optie meer. Dan is het een kwestie van uithuilen en opnieuw beginnen.
Verder is het natuurlijk altijd erg subjectief, stijl van coden, manier van software structureren etc. En mensen zijn vaak wat 'overprotective' over hun eigen code, het is hun 'kindje'. Ook (vooral?) slechte programmeurs vinden vaak dat hun eigen code prima is.
Niemand roept dat omdat iets open source is dat het ook veilig is. Het is vaak een keuze maken tussen zelf patches indienen of van 0 af aan herbeginnen. Ik kan me inbeelden dat er voor BSD ook aanpassingen aan de software noodzakelijk waren en dat ze daar niet aan wilden beginnen. Spijtig dat na 10 jaar er nog niemand in geslaagd is om de 2 projecten terug in elkaar te laten overvloeien.
Niemand roept dat omdat iets open source is dat het ook veilig is.
Dat is zeker tot een paar jaar terug heel vaak geroepen.
Wat ik elders op het net las is dat OpenNTPd bewust minder kan en slechts 'goed genoeg' is voor standaard tijd bijhouden. ntpd probeert echter zo precies mogelijk te zijn en dat brengt complexiteit met zich mee.
Open source zou het in principe leesbaarder maken in vergelijking met assembly code. Het zou daardoor veiliger kunnen zijn mits er maar voldoende enthousiastelingen zijn die ook daadwerkelijk een blik werpen op die code. Helaas sommige programmeurs schrijven nu eenmaal obfuscated code en dan gebeurt het laatste niet.
wat heeft assambly programmeertaal te maken met type licentie open source ?
Het erge vind ik dan dat gast128 op zn profielpagina heeft staan datie in zowel assembly als in c programmeert.., :'(
Iedereen overdrijft toch op zijn profielpagina. Net zoals op een CV.
Het is inderdaad wel een raar punt dat gast128 probeert te maken: sommigen schrijven moeilijk leesbare code en daardoor werkt opensource niet ?
Dat klopt op zich wel. Om open source zo goed mogelijk te laten werken moet een stuk sourcecode voor een buitenstaander makkelijk leesbaar zijn. Veel programmeurs houden er echter nog steeds geen rekening mee dat er ook andere mensen dan zijzelf naar de code zullen kijken...

Uiteraard kan broncode in iedere programmeertaal open source zijn, maar niet iedere taal is even geschikt voor gebruik als open source. Iemand die in assembler schrijft zal veel meer extra werk hebben om z'n code voor een ander leesbaar te krijgen, dan iemand die in Python programmeert.

[Reactie gewijzigd door RSpanjaard op 23 december 2014 21:32]

Assembly kan ook open source zijn hoor, je bedoeld waarschijnlijk machinetaal.
Een beetje debugger laat het in assembly (e.g. mov etc.) zien en niet machinetaal (e.g. opcodes), hoewel op macro's na dit wel een 1 op1 vertaling is. Een klein nuance verschil.

[Reactie gewijzigd door gast128 op 23 december 2014 15:43]

Zowel assembly als machinetaal hebben compleet niks met open source te maken hoor....
Je begrijpt het echt niet? Deze thread werd gestart over het feit dat ondanks dat de broncode van ntpd beschikbaar was, het voor programmeurs te moeilijk was om te begrijpen. ChicaneBT stelt:
Veel anderen roepen het is open source dus het is veilig, dat werk.
Daar breng ik een nuancering op aan. Het is meestal zo dat opensource positief is, mits de broncode goed leesbaar is en als er voldoende collega's naar kijken. Als je de broncode niet zou hebben, rest je namelijk niets anders dan reverse engineering met een debugger in assembly, wat onbegonnen werk is voor de meeste onder ons.

Iemand merkt op dat assembly ook source code kan zijn, maar in de praktijk neem ik aan dat het met broncode hier een hogere taal wordt bedoeld.

Dat jij mij de maat neemt laat ik maar even passeren.
Als je de broncode niet zou hebben, rest je namelijk niets anders dan reverse engineering met een debugger in assembly, wat onbegonnen werk is voor de meeste onder ons.
Dan heb ik je verkeerd begrepen. Ik zie reverse engineering van binaries op zich niet als alternatief voor vrije software. Mischien dat drivers daar enigzins een uitzondering op zijn.
Ik zie reverse engineering van binaries op zich niet als alternatief voor vrije software.
Dat is ook niet zijn punt.
Zijn punt is dat als je naar bugs/exploits/etc wil zoeken in software, dat je dan dus in een disassembly moet zoeken als het niet open source is.
(Dit is dus wat er in Windows gedaan wordt).
Net zoveel als appels en peren op elkaar lijken... maar van beide kan je wel moes maken. Zo kan je voor een opensource project (moes) ook gebruik maken van assembly (appels) of machinetaal (peren).
Mijn Mac heeft zicht netjes gepdatet. Maar de 14.04 servers blijven steken op deze versie: 4.2.6.p5+dfsg-3ubuntu2.14.04.1
Dat is de correcte versie.
Je hebt gelijk, 4.2.6p5 is de gepatchde versie.

Echter:

"Alle voorgaande versies van ntp4 zijn kwetsbaar en op 19 december kwam versie 4.2.8 uit die de problemen aanpakte."

Dan staat het dus verkeerd in het artikel?
Het zou ook kunnen dat er gekozen is om de bugfix te backporten naar de huidige versie in de repositories. Dat is iets waar vooral Debian heel erg bekend om staat en aangezien Ubuntu weer gebaseerd is op Debian zou het kunnen dat zij dat hier zo overgenomen hebben.
Servers patch je door de huidige versie te fixen en niet de nieuwste versie van de software te pushen.

4.2.6.p5 = stock 4.2.6 met 5 patch releases
Dan staat het dus verkeerd in het artikel?
Neen.

De versie bij het NTP-project vandaan waarin dit probleem gepatcht is, is 4.2.8. Maar dat is niet de versie die in Ubuntu, Debian, Red Hat, etc. zit, dus die vendors backporten de patch naar de versie van de software die zij meeleveren zodat die ook veilig is.
Distributies met lange termijn ondersteuning proberen van een pakket ten alle tijde op dezelfde versie te houden. Zo houd men de functionaliteit van een pakket op elk moment gelijk en kan de gebruiker er zeker van zijn dat software die op de eerste dag van de release van de distributie werkte ook nog altijd correct zal werken op de dag, zoveel jaren later, dat de distributie EOL word.

En deze houd Canonical dus de versie op 4.2.6 maar kijken zij naar de bugfix en welke patch zij kunnen overnemen danwel welke code ze zelf moeten herschrijven om het probleem op te lossen.
Ik heb zojuist alle automatische updates voor Ubuntu 14.04 Server doorgevoerd. Maar hier stond niets in met betrekking tot de ntp en uns versie. Hoe kan ik controleren welke versie is geinstalleerd?
Bedankt! Ik heb ook versie 4.2.6.p5 dus dan is die gepatcht volgensmij.
Dat kun je ook mooi in /var/log/apt/history.log zien dan :)
voor centos:
sudo yum update ntp -y

voor debian / ubuntu:
sudo apt-get update&&sudo apt-get install ntp

[Reactie gewijzigd door xleeuwx op 23 december 2014 15:11]

Waarom install en niet upgrade? (Debian/Ubuntu)

Edit: typo

[Reactie gewijzigd door 547741 op 23 december 2014 15:27]

Omdate update alleen nieuwe repositories ophaald en niet het product daadwerkelijk updated terwijl install de nieuwste versie installeerd die beschikbaar is zover hij weet vandaar ook eerst de update.

http://askubuntu.com/ques...es-sudo-apt-get-update-do
Ik bedoelde upgrade eigenlijk (stond verkeerd in mijn posting).
eu ja das voor mij meer een macht der gewoonte, maar zou inderdaad netter zijn om upgrade te gebruiken.
Het zijn verschillende commando's.

apt-get install ntp installeert (of als je 'm al hebt, upgradet) alleen 'ntp' (en alles wat daar eventueel bij komt kijken.)

apt-get upgrade doet een upgrade van alle packages op je systeem (zover die geen nieuwe dependencies introduceren)

apt-get dist-upgrade doet een upgrade van alle packages op je systeem, ook als die nieuwe dependencies introduceren.
Als je je systeem up to date wil houden, is het upgrade argument beter. Dus:

sudo apt-get update && sudo apt-get upgrade
Ahum: "sudo apt-get update && sudo apt-get upgrade" doet hetzelfde, kijk maar:
Start-Date: 2014-12-23 02:29:32
Commandline: apt-get upgrade
Upgrade: ntpdate:amd64 (4.2.6.p5+dfsg-3ubuntu2, 4.2.6.p5+dfsg-3ubuntu2.14.04.1)
End-Date: 2014-12-23 02:29:32
(/var/log/apt/history | tail uit een VPS van mij)

Na deze update zegt "dpkg -s ntpdate | grep -i version" het volgende:
Version: 1:4.2.6.p5+dfsg-3ubuntu2.14.04.1
Met wat jij voorstelt raak je ook eventuele custom configs kwijt in sommige gevallen.

[Reactie gewijzigd door sfranken op 23 december 2014 15:38]

Met wat jij voorstelt raak je ook eventuele custom configs kwijt in sommige gevallen.
Alleen in het geval dat je zegt 'gooi m'n config maar weg', en dat gebeurt bij upgrade even hard. Voor het package is install of upgrade hetzelfde als het package al geinstalleerd was. Het verschil is dat upgrade ook andere packages upgrade, waar install zich alleen bezig houdt met wat je opgegeven hebt en de dependencies daarvan.
Als je DebConf op "ja hoor ik vind het prima doe maar" heb ingested, wat sommige mensen schijnbaar doen. Maar je hebt inderdaad gelijk verder.
Doe maar sudo yum update ntpdate ntp
Maar het lek zit in ntp niet in ntpdate.
Daarom beiden even updaten. Zal vast geen kwaad kunnen.
Mijn Mac heeft de update ook automatisch doorgevoerd, wat te zien was aan een (nogal generieke) melding en in een logfile. In de installatiegeschiedenis van de App Store duikt hij echter niet op.

Toevoeging: ik gebruik OS X Yosemite.

[Reactie gewijzigd door Commendatore op 23 december 2014 15:05]

Voor kritieke bugs zit er een update mechanisme in OSX wat zonder tussenkomst van de gebruiker werkt. Vandaar dat hij niet in de App Store update geschiedenis te zien is.
Ik heb hem gsiteren gewoon met de hand geinstalleerd. Hij staat dus ook gewoon ind e update geschiedenis van mijn Mac.
Staat gewoon netjes in het lijstje van updates hoor. Compleet met link naar de notes: http://support.apple.com/en-us/HT1222
is deze update er ook voor lubuntu
Lubuntu is een Ubuntu-distro, dus haal de patch via de updates maar op zou ik zeggen :)
Thanks, was niet zeker of de patches van ubuntu ook direct uitkwamen voor lubuntu
(heb nog maar twee dagen lubuntu draaien)

[Reactie gewijzigd door maevian op 23 december 2014 19:52]

Voor zover ik weet wel.
Ik vraag me af of Debian affected is?
We zien nog geen updates op onze servers.
Debian heeft deze bug al 3 dagen geleden gepatched in versie 1:4.2.6.p5+dfsg-2+deb7u1. Als je unattended-upgrades nachtelijks security updates laat draaien kreeg je deze in de nacht van 20 op 21 december binnen.

[Reactie gewijzigd door CyBeR op 23 december 2014 15:16]

Oke vandaar dat we hem niet zagen in de updates :)
Bedankt.
http://j.mp/1E3lbb1

Ja dus ... En zoals je ziet is de patch ook al uitgerold.

Edit: verkeerde link naar subversion update 8)7

[Reactie gewijzigd door 547741 op 23 december 2014 15:22]

In het stukje staat dat Debian afgelopen weekend gereageerd heeft.
Naar aanleiding van het nieuwsbericht van vanochtend op mijn MBP ook eens naar updates gezocht en gevonden, en daarna ook op de diverse Debian en Ubuntu-machines die ik in beheer heb. Gelukkig weer snel gepatcht,

Als het commentaar van Theo de Raadt waar is is dat wel weer een kwalijke zaak; het is een softwarecomponent wat in zeer veel systemen gebruikt wordt en waar de beheerders dus ook ofwel goed om moeten gaan met kritiek en suggesties voor verbetering, ofwel de verantwoordelijkheid niet langer op zich nemen en het project aan anderen overdragen.
ntpd zal net zo iets zijn als openssl wat de club van Theo ook geforked heeft en opnieuw aan het opbouwen zijn. Dingen zijn vaak, een decennium of nog langer geleden gemaakt, vaak wordt er boven op bestaande sources gebouwd door mensen die niet exact weten waar dit of dat ook al weer voor was en zo worden oude zaken in takt gehouden. Het komt niet vaak voor dat iets echt gestript wordt zoals openBSD doet.
Misschien handig om te weten aangezien het in het artikel niet vermeld staat, distro's als Red Hat en CentOS backporten de patches waardoor het versie nummer blijft steken op 4.2.6-p5-2 in plaats van 4.2.8 (die vermeld staat in het artikel). Het wil dus niet meteen zeggen dat als je nog 4.2.6 draait dat je automatisch vatbaar bent voor de bugs. Dit is overigens met veel security updates zo bij die distro's :)

Meer kun je hier lezen over de bug: https://rhn.redhat.com/errata/RHSA-2014-2024.html
suse had afgelopen vrijdag de 19de de patch al voor suse 13.1, ook: 4.2.6-p5-15.13.1.

kijk anders even in yast2 bij changelog van ntp

bnc#910764: VU#852879 ntp security fixes
* A potential remote code execution problem was found inside
ntpd. The functions crypto_recv() (when using autokey
authentication), ctl_putdata(), and configure() where updated
to avoid buffer overflows that could be
exploited. (CVE-2014-9295)
* Furthermore a problem inside the ntpd error handling was found
that is missing a return statement. This could also lead to a
potentially attack vector. (CVE-2014-9296)
De meeste NTP-gebruikers laten een willekeurige NTP-Server uit pool.ntp.org zonder enige authenticatie de klok van hun systeem/netwerk bedienen. Let wel: een NTP-server uit pool.ntp.org is dus gewoon iets wat bij iemand op zolder of in de kelder/meterkast draait.

En dan gaan mauwen over een lek in ntpd dat louter betrekking heeft op authenticatie (genereren van pseudo-random-numbers). Beetje overdreven wanneer je authentication nog niet eens gebruikt!!!!!!

[Reactie gewijzigd door 2TheMaks op 23 december 2014 17:58]

Dus het lek hoeft niet gefixt te worden want volgens jou gebruikt toch niemand die optie? Nu NTP steeds vaker misbruikt wordt om DDoS aanvallen te versterken worden mensen wakker en is het juist belangrijk dat mensen wl authenticatie gaan gebruiken en dat dit natuurlijk dan ook werkt.

Windows gebruikt voor zover ik weet al tijden time.windows.com of een van de NIST servers die in handen zijn van Microsoft dan wel de overheid.

[Reactie gewijzigd door Ventieldopje op 23 december 2014 18:44]

Dus het lek hoeft niet gefixt te worden want volgens jou gebruikt toch niemand die optie?
Dat zeg ik niet.

Ik zeg dat het zwaaaaaaar overdreven is om te mauwen over een door een bug/leak veroorzaakte vulnerability wanneer je door geen authenticatie te gebruiken sowieso vulnerable bent. Zelfs met een bug/leak in de authenticatie ben je dan nog stukken minder kwetsbaar.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True