Let wel op: je kunt niet zomaar even je ntp vervangen door versie 4.2.8, dit is een major release die de maker even gauw
de deur uit geschoven heeft omdat daar dit probleem niet meer in zat, maar die nog lang niet uitontwikkeld en uitgetest was.
Er zijn dus links en rechts al problemen mee. En op zijn minst moet je de config file opnieuw door lopen en aanpassen
omdat er details veranderd zijn aan hoe de dingen werken.

Geen beste actie. Het wachten is op fixes in de bestaande stabiele 4.2.6p5 versie die de meeste distributies gebruiken,
zodat er gewoon een automatische update gedaan kan worden.

uit voorzorg maar verwijderd van opensuse

tlsdate is een vervanger, maar daar heb ik nog geen rpm voor gevonden

Degene die dat geschreven heeft heeft duidelijk niet zo veel ervaring ermee.
Dingen die hij daar suggereert die werken in de praktijk niet (hij zegt wel even terloops dat "not all systems allow time jumps"
maar dit is gewoon de default situatie in zowel de reference implementatie als de Windows versie).
Ook is NTP niet een stukje speelgoed om snel even de klok redelijk te zetten, zoals het protocol wat hij voorstelt.

Ik denk dat NTP wel verbeterd kan worden of dat er andere protocollen voor in de plaats kunnen komen, maar niet op de
manier die hij suggereert. Met NTP kun je de klok echt goed zetten, met zijn protocol krijg je alleen een aannemelijke
setting voor een computer die zelf geen klok heeft. Dat is toch wat anders.

OpenSUSE is nou net een van degenen die een update heeft uitgebracht in de oude bestaande release....

@ Krakatau

ik poog op dit moment via de opensuse buildservice een rpm te maken van chrony 1.31

is in ieder geval iets

Vrijwel alle routers hebben NTP standaard ingebouwd, en bij de paar routers die ik ken, kun je het niet uitschakelen.
In geval je zelf geen NTP server(s) invult, gebruikt de router een aantal default NTP-servers uit de firmware... (OEPS!!!...)

NTP op de router kan dus meestal niet geheel worden uitgeschakeld,
en nu wordt het de hoogste tijd dat de routerfabrikanten eens wakker worden!!!

Het is vooral klassiek paniekvoetbal om nu met z'n allen over ntp te vallen. Ja, het is een oud protocol. Ja, er kunnen dingen beter. Nee, de wereld vergaat niet, zelfs als er een grote stapel gaten in gevonden worden. Vergelijk sendmail: Volgens sommigen ook de duivel, en er zaten ook gigantisch grote gaten in, maar die waren er na een tijdje redelijk aardig uitgeschud en toen bleek het nog best bruikbaar voor de mensen voor wie het bedoeld was: Systeemadministratoren. De "betere" vervangers waren dat ook nog eens niet zomaar.

Een van de dingen die ntp via de reference implementation uitstekend doet is de tijd synchroniseren, beter zelfs dan menig alternatieve, "betere" versie of dan dus dit andere protocol. De gaten en problemen die er in zitten zijn veelal te voorkomen danwel te mitigeren door zorgvuldig configureren ook zonder op de allerlaatste versie over te gaan, en daarnaast is de schade van zelfs remote code executie in veel gevallen zeer beperkt, bijvoorbeeld omdat het ding standaard al onder een eigen gebruiker draait, in een chroot, alleen ongepriviligeerde acties mag uitvoeren zodat tijdbijstellingen alleen kleine aanpassingen (<1s) per keer kunnen doen, waar ook nog eens een limiet van aantal aanpassingen per seconde op zit, en meer van dat soort gein. Zelfs een gerichte aanval met valse tijd en een gestolen sleutel kan bij correct configureren alleen maar van zeer bepaalde hosts en duurt dan een lange tijd om de boel voldoende uit de pas te laten lopen om er misbruik van te kunnen maken.

Het is wel leuk om met z'n allen naar gaten te wijzen en flink te schreeuwen, maar een beetje inhoud is ook wel eens leuk, zo af en toe. En in dit geval is er al best wel veel wat er al gedaan is zodat de impact niet eens zo gek groot zal zijn. Wel even opletten, wel even nadenken, wel even goed kijken hoe het nu zit en wat je er aan kan doen. Maar paniekvoetbal is gewoon niet nodig. Het valt op hoe dat besef hier en elders zo schitterend afwezig is.

Ik heb even snel naar dat tlsdate gekeken en het onttrekt de tijd uit een TLS-verbindingsopbouw. Leuk dat dat daar in zit, maar je moet maar net vertrouwen dat die ene andere servert de juiste tijd heeft, plus dat het een nogal onprecieze tijdsoverdracht geeft. Wat het niet doet, en ntp wel, is naar verschillende servers kijken en de rotte appels negeren. tlsdate is dan ook geen vervanging voor ntp, maar een hack die wellicht rdate kan vervangen. Nogal een verschilletje.

Wat heet. Plus dat ik heel erg verbaasd ben dat mensen iets wat gebouwd wordt op het razend complexe framework van TLS met het hele certificaat model als verbeterde beveiliging beschouwen.
Er zijn nogal een hoop lekken in gevonden, en gegeven de grote complexiteit denk ik echt niet dat we voorlopig klaar zijn daar.

Dat is heel vaak "sntp", een nogal uitgeklede versie, en meestal andere code. Dus of daar dezelfde fouten in zitten? Vele van de aanvalbare codepaden zitten daar helemaal niet eens in.

Vervelender is het als er bijvoorbeeld wel een ntpd in gebruik is maar het configuratiesysteem eromheen staat je niet toe om de benodigde "restrict"-configuratieregels in ntp.conf terecht te doen komen. Of dat de fabrikant dus overduidelijk allerlei open source gebruikt maar alleen maar updates verstrekt als je een onderhoudscontract hebt afgesloten, en de (GPL!) source krijg je ook al niet los.

Dus versies nieuwer dan 4.2.6 missen die bug? (Edit: nee)

Op mijn mac staat versie: 4.2.6@1.2089-o

Maar ik zie dat de Synology nas versie: 4.2.7p446@1.2483-o heeft.

Natuurlijk RCE is in veel gevallen helemaal 'zeer beperkt'; elke security expert weet dat het dan meestal gewoon game-over is. Het is een illussie dan er geen privilege escalation kan plaatsvinden; dat is vrijwel altijd mogelijk, zeker over tijd.

Lang leve OpenNTPd. :) Snel toch maar even een gps klokje maken.

Nee dat heb ik niet gezegd. Er zijn patches voor, en in tegenstelling tot de halve gare die de ntp source beheert hebben
de distributeurs van Linux wel de actie ondernomen om die patches in oudere versies (de versie die ze op hun distributie
leveren, meestal is dat 4.2.6p5) aan te brengen en de binaries te verspreiden.

Dat is een heel wat betere actie dan snel even 4.2.8 eruit pushen zoals die ntp source beheerder gedaan heeft.
Maar patchen moet je dus evengoed wel. Ook die Synology NAS.

Je zegt hier dat alle moeite met chroots, jails, zones, virtual machines, bij voorbaat zinloos is want als er ook maar iets gebeurt "weet elke security expert dat het dan meestal gewoon game-over is." Dat hadden die security experts wel even mogen vertellen, dat had een hoop werk gescheeld. Gewoon alles op de grote hoop, heeft toch geen zin te proberen privileges te scheiden. Iedereen aan de administratierechten, je krijgt ze toch wel. Lekker nuttige bijdrage van die "experts".

Dat gaat je daarmee niet lukken. Daarbij vinden de ontwikkelaars van dat vehikel het ook niet belangrijk om de tijd ook werkelijk accuraat over te brengen. Dan kun je bijna net zo goed gewoon de tijd op je lokale netwerkje per multicast rondbazuinen en er met een minimale multicast-client naar luisteren. Dat is nog veel minder code (een pagina C code ofzo), en dus veiliger, weetsjewel. Of je pakt rdate of ICMP TIMESTAMP, ik noem eens wat obscuurs.

EN dat is wel een HEEL ONBETROUWBARE bron! Die lui verzinnen onzin zoals de "leap second smear".
Daar kun je beter niet aan syncen als je nauwkeurige tijd nodig hebt...
(voor een klokje op de PC om de tijd in je mail goed te hebben is het wel OK uiteraard, maar dat is niet wat NTP maximaal kan)

Je kan als alternatief voor de reference ntp implentatie gebruik maken van chrony: http://chrony.tuxfamily.org/index.html

"Installeer de updates van je leverancier" .

Als je verder niet de kennis (of de zin, of de tijd) hebt om bij allerlei vulnerabiliies voorop te lopen, ergens patches vandaan te toveren, zelf sources compileren is bovenstaande wat overblijft.
En ondanks alle paniek verhalen, voor vrijwel iedereen ook voldoende. Zeker als je zelf geen server of diensten host.

Host je wel diensten, dan moet je gewoon techneuten taal leren.

Als je gewoon NTP als client gebruikt om tijd te halen van één van de internet tijd server als client is de kans erg groot dat je voor de genoemde bug helemaal niet kwetsbaar bent.
Dat lijkt voor veel Linuxen het geval te zijn , je moet een non-default configuratie hebben wil het code pad waarin de bug(s) zitten gevolgd worden, of de aanvaller moet aanwezig zijn op localhost.

(non default - crypto keys gebaseerde control messages accepteren voor remote hosts )

Dus als je geen tijd*server* host of kandidaat hackers direct op je machine hebt zitten, moet je gewoon regelmatig updates installeren. Net als altijd.

zie (voor Linux )
https://bugzilla.redhat.com/show_bug.cgi?id=1176040
https://bugzilla.redhat.com/show_bug.cgi?id=1176037
https://lists.debian.org/debian-security-announce/2014/msg00298.html

Het hoe is een vraag voor je systeembeheerder, en als je dat zelf bent, mag je jezelf inlezen in hoe je dat voor jouw systeem moet doen.

De release notes zijn wel vrij leerzaam overigens. Lees maar mee:

http://support.ntp.org/bin/view/Main/SoftwareDownloads

Met andere woorden, met een regeltje in het configuratiebestand kom je al een heel eind. Daarbij, die "restrict default ... noquery"-regel had je onderhand toch al in je ntp.conf horen te hebben omdat anders je (publiek bereikbare) ntpd misbruikt kan worden voor een "amplification attack". Dat was de vorige ronde paniekvoetbal omtrend ntp.

Gelukkig is Synology doorgaans redelijk vlot met het uitbrengen van updates, dus wacht ik hun actie af. Op die nas staat wel de timeserver aan en veel apparaten op mijn netwerk gebruiken die timeserver, maar hij is vanaf het internet niet bereikbaar. En een kans op een aanval vanuit het locale netwerk is op korte termijn klein zoals anderen ook aangeven.

Of DFC77.

Als je het hebt over een volle TLS handshake ben je toch al niet meer serieus bezig met 'nauwkeurige tijd' , van welke bron je het ook haalt.

Dat is ook precies waar je ntp voor gebruikt, en daar zijn weinig echte alternatieven voor. Wil je "gewoon de tijd" op je veilige lannetje dan kun je andere dingen gebruiken, sntp of rdate of weetikhet, maar je moet niet pretenderen dat die ook maar enigszins nauwkeurig zijn.

Dat dit nogal eens verkeerd gaat, bijvoorbeeld omdat er nogal veel de bek open trekken zonder echt weten waar ze het over hebben, moge evident zijn. Zo herinner ik me een ntp-implementatie voor windows (de standaardimplementatie die je bij xp krijgt) die het bestond om zichzelf een goede tijdsbron te noemen maar vervolgens wel twee minuten verkeerd te lopen. De standaardinstellingen lieten dat toe, werkten het zelfs in de hand.

Nu is het voor zulke machines niet raar (windows is sowieso erg slecht met de tijd bijhouden, dat was al zo met DOS en dat is zo gebleven) en zal het in kantooromgevingen weinig problemen opleveren (want bijvoorbeeld een SSO-oplossing als kerberos staat standaard tot wel vijf minuten verschil toe). Maar een affront vond ik deze liegende software wel.

Ik gebruik op mijn server FreeBSD met OPENNTBD. Er wordt beweerd dat dat niet lek zou zijn. Klopt dat? En zo ja, waarom wordt daar niet naar verwezen als alternatief? OPENTBD is immers ook beschikbaar voor veel linux platforms.

Verder gebruik ik Webmin waarmee je ook datum en tijd in kan stellen. Het is mij alleen niet duidelijk of Webmin daar een eigen NTP client voor gebruikt, of daarvoor ook van OPENNTBD gebruik maakt. Zelf heb ik NTP niet geinstalleerd op mijn server.

Iemand die hier antwoord op kan geven?

Leuk dat TLSdate, maar - correct me if I'm wrong - het gaat niet nauwkeuriger dan op de seconde. NTP doet het natuurlijk op de microseconde, wat dus een factor miljoen nauwkeuriger is. Daarnaast heeft NTP wiskundige algoritmes om network lag mee te rekenen en doet het aan een clockskew (klok langzamer of sneller laten lopen) om de tijd goed te zetten. Dus geen timejumps die je systeem kapot kunnen maken. Het idee van een stratum in je timeserver is natuurlijk ook iets wat tlsdate niet meeneemt. Hoe dichter je bij een stratum 0 in de buurt komt, hoe nauwkeuriger je tijd is.

Laten we alsjeblieft NTP verbeteren in plaats van allemaal brakke nieuwe implementaties te bouwen.

Tot mijn schrik zie ik dat ik een typefout heb gemaakt. Uiteraard moet het OPENNTPD zijn.

Nou dat is niet echt zo. Als je de tijd heel nauwkeurig wilt instellen dan kun je eigenlijk beter PTP gebruiken.
Zeker als je hardware (switches) daar support voor heeft is het nog veel beter dan NTP.

Het is andere code, dus in principe niet nee. En ja, er wordt maar al te graag naar verwezen als alternatief, want door de snelle jongens van openbsd geschreven en dus altijd en bij voorbaat beter. Behalve dan als je serieus bent in het tijd bijhouden, dan mist het gewoon het inzicht van iemand die echt verstand heeft van tijd synchroniseren en het mist ook de jarenlange ervaring die de referentie-implementatie van ntp ondertussen verzameld heeft. Wat het ook al niet doet is met je (hardware) referentieklokken praten. Zowel accuraatheid als referentieklokken vinden ze daar gewoon niet belangrijk.

Het is dus geen alternatief voor waar ntp echt voor is, en dus niet echt een optie voor degenen die echt de tijd goed en nauwkeurig willen synchroniseren. Is dat niet belangrijk dan kun je ook chrony of een ander alternatief pakken. Daarnaast is het ook niet echt nodig, want hoewel er nare gaten in ntpd te vinden waren, zijn ze goed in te dammen, en is dat bij correcte configuratie eigenlijk ook al gebeurd. Zo'n groot probleem is het dus niet. Voor de goed verstaander.

Ik bedoel, dit is een van die dingen die aandacht vragen om recht te zetten*, maar het gepaniekvoetbal en het gekrakeel en geroep om andere "betere" alternatieven die bij nadere inspectie gewoon niet beter zijn, soms zelfs het originele doel niet halen en niet eens kunnen halen, dat is gewoon niet productief.

* En een reden om nog eens serieus naar de code te kijken. Maar niet lang geleden was er een vergelijkbare reden om eens goed naar de code te kijken, en ondertussen heeft iemand dat dus maar eens gedaan, en toen kwam dit bovendrijven. Er zullen nog wel een rits meer patches volgen. En ook die zijn niet echt meer reden om dan maar te gaan roepen "oh we moeten een alternatief hebben!" -- het gaat namelijk om de tijd bijhouden, en dat kan die code erg goed, en de alternatieven minder.**

** Het was fraaier geweest als ze dertig jaar geleden al begonnen waren met te zorgen dat de code niet ook allerlei beveiligingsproblemen zou hebben gehad, maar soit. Als je goed kijkt zie je ook dat er voldoende mechanismen reeds in positie zijn om problemen die toch voorkomen redelijk in te dammen. Daar hebben andere softwaresystemen toch duidelijk minder goede prestaties geleverd in het verleden, en die zijn ook nog steeds overal in gebruik. Lijkt me een beetje overdreven om dan hier effectief het kind met het badwater weg te willen gooien.

Ja, als je een master klok op je LAN hebt kan PTP daar beter mee syncen dan NTP.

Maar wat ik gezien heb is PTP een LAN-only protocol, en daarmee geen alternatief voor NTP als je tijdsbron buiten een LAN gedeeld wordt.

Ja en ?
Ik lees daar nog steeds dat PTP een protocol is waarmee je slave klokken aan een master over een LAN synct.

Ik lees daar ook wel wat FUD over NTP.
De FAQ suggereert dat NTP nauwelijks binnen een seconde kan syncen ,'depending on your internet connection'.
En praat daarna over LAN-only PTP wat veel beter is.

Dat is nogal valse vergelijking, een trage internet link met enorm veel jitter contrasteren met prestaties over LAN.
NTP op een LAN kan prima in orde milliseconden syncen, als de server een stabiele klokfrequentie heeft.

Over een goede internet verbinding is orde tiental milliseconden best haalbaar.

Als de FAQ daarna dan schrijft dat Cesium klokken atoom klokken heten omdat ze gebaseerd zijn op *radioactief verval* kan de auteur echt beter naar huis gaan met de hema wekker, want kennis van klokken heb je dan niet.
(Cesium klokken houden hun frequentie stabiel door die te koppelen aan een bepaalde overgang tussen twee energie niveaus van een cesium atoom. Dat heeft niets met radioactief verval ('atomic decay') te maken. ).

Dus nogmaals : Ik zie PTP echt alleen LAN-only.