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 , , 67 reacties

Apple heeft een fix voor een kwetsbaarheid in de ntp-implementatie in OS X uitgebracht. Via het lek konden kwaadwillenden een buffer overflow veroorzaken en zo op afstand eigen code op een Mac uitvoeren.

De 'OS X NTP Security Update' is beschikbaar voor Mac-systemen die versie 10.10 Yosemite, 10.9 Mavericks en 10.8 Mountain Lion draaien. Het gaat volgens Apple om een pleister tegen een 'kritiek beveiligingslek in de software die de Network Time Protocol-dienst voor OS X levert'.

Googles Security Team ontdekte eerder deze maand dat kwaadwillenden via de network time protocol daemon buffer overflows konden genereren en vervolgens eigen code op getroffen systemen konden uitvoeren.

De update zou op de achtergrond gedownload moeten zijn als gebruikers dit zo ingesteld hebben en anders is deze als update bij de Mac Store te zien. Het zou om de eerste beveiligingsupdate gaan die Apple automatisch pusht. Gebruikers zouden de volgende ntp-versies moeten hebben na het doorvoeren van de update, te zien via Terminal na het invoeren van what /usr/sbin/ntpd: Mountain Lion: ntp-77.1.1, Mavericks: ntp-88.1.1 en Yosemite: ntp-92.5.1.

Moderatie-faq Wijzig weergave

Reacties (67)

Dat is vrij snel voor Apple standaarden :+

Toch vraag ik me af hoe derde de code kunnen aftrappen om de buffer overflow te genereren. Volgens mij moet ik als gebruiker nog steeds toegang geven aan software om dat te doen.

Gebruikers zijn first defence. als die niet oppassen helpt geen enkele security fix.
Je computer krijgt een verkeerd pakketje binnen, dat er uit ziet als iets voor de NTP daemon, waardoor die een buffer overflow genereert en het return adres ergens uitkomt waar de aanvaller het wil en dus willekeurige code kan uitvoeren (eventueel ook aangeleverd, verpakt als pakketjes voor NTP). Geen interactie met de eindgebruiker nodig dus.

Je hebt dan nog wel een andere exploit nodig, want NTP draait op elk deftig hedendaags Unix-systeem met beperkte rechten, dus nog een privilege escalation bug nodig om wat meer te kunnen. Voor systemen met RBAC (role based access control), zoals SELinux, moet je ook nog uit die rol ontsnappen (meestal worden een aantal daemons opgevolgd met SELinux en niet het hele systeem).

[Reactie gewijzigd door vide op 23 december 2014 08:22]

Wel is grappig om te zien dat blijkbaar ntpd op een OSX systeem nog steeds onder root draait:

root 1737 0.0 0.0 2496748 1832 ?? Ss 8:09AM 0:00.08 /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift

Op een ander linux systeem draait die wel al netjes onder de user ntp. Dat die nog onder root draait is waarschijnlijk de reden voor het snel beschikbaar stellen van een security update.
Apple heeft al langer issues met NTP.

zie ook de in 10.9 geintroduceerde deamon pacemaker.
https://developer.apple.c...ges/man8/pacemaker.8.html
Via een buffer overflow kan je in een stuk geheugen terecht komen wat root rechten heeft.
"Geheugen" heeft geen rechten als zodanig; het is wel afgeschermd, maar dat wordt geregeld door de processor. NTP is een user-mode programma, dus zelfs als de memory protection geheel zou falen en je in een stuk kernelcode terecht komt (wat om te beginnen al niet kan) dan nog zou die code niet uitgevoerd kunnen worden omdat je niet in de juiste ring zit (dit is de beveiliging op processorniveau).

Het "enige" dat je met een buffer overflow bereikt is dat er code van jouw ontwerp uitgevoerd wordt, hetzij code die je meegeeft, hetzij reeds bestaande code die je slinks manipuleert (en dat kan code uit de algemene systeemlibrary zijn, dus met voldoende slimheid kun je alles).

Daarna hangt het volledig af van hoeveel rechten de gebruiker heeft waar het proces onder draait: is dat root, dan is je systeem volledig compromitteerd, is dat (zoals op ieder fatsoenlijk systeem) een account met alleen precies die rechten die nodig zijn, dan blijft de schade beperkt tot wat dat account kan doen.

In het geval van NTP kun je dan nog steeds een systeem lamleggen, omdat de NTP daemon per definitie het recht heeft de systeemklok te manipuleren. Dat die goed blijft lopen is toch een vrij essentieel onderdeel van veel servers; een beveiligingsprotocol als Kerberos werkt niet als de timestamps op de servers teveel van elkaar verschillen. Ook kun je dit gebruiken als onderdeel van een andere aanval, om logfiles mee te vervalsen. Voor een desktopmachine zou de schade beperkter zijn.

Zoals @Beuker hieronder vermeldt: onder OS X draait ntpd blijkbaar als root, dus je hele systeem is gecompromitteerd als er een lek in ntpd zit, en dat is voor desktopmachines natuurlijk net zo erg. Daar is geen goed excuus voor; een service als ntpd hoeft absoluut niet als root te draaien alleen omdat hij de klok moet kunnen zetten.

[Reactie gewijzigd door MneoreJ op 23 december 2014 11:18]

"Geheugen" heeft geen rechten als zodanig; het is wel afgeschermd, maar dat wordt geregeld door de processor. NTP is een user-mode programma, dus zelfs als de memory protection geheel zou falen en je in een stuk kernelcode terecht komt (wat om te beginnen al niet kan) dan nog zou die code niet uitgevoerd kunnen worden omdat je niet in de juiste ring zit (dit is de beveiliging op processorniveau).
Ik wil dit even iets nuanceren.
Het is namelijk best wel mogelijk om via een bug in een user-mode programma root-rechten te krijgen, danwel code in kernelmode te kunnen draaien.
Een voorbeeld hierbij zou bv kunnen zijn een bug in een netwerkdriver.
Via een user-mode programma zou je dan een socket kunnen openen, en een speciaal geprepareerd pakketje versturen, dat dan naar de driver gestuurd wordt, die in kernelmode draait, en daar een bug triggert, waarna code in jouw pakketje gedraaid kan worden.
Met die code kan je dan vervolgens je user-mode proces root-rechten geven, en het systeem overnemen.
Daar is geen goed excuus voor; een service als ntpd hoeft absoluut niet als root te draaien alleen omdat hij de klok moet kunnen zetten.
Daar ben ik het deels mee eens.
Maar dat is vooral een beperking van het rechtenmanagement in UNIX. Dat is namelijk alles-of-niets.
Je wil niet dat iedere gebruiker en ieder proces aan de klok kan zitten (want het verzetten van de klok heeft allerlei effecten op dingen als timestamps in logs, geschedulede zaken etc. Klok moet betrouwbaar zijn).
Dus blijft er weinig anders over dan dit maar aan root te koppelen.
Ik vind dus dat er een ander mechanisme zou moeten zijn om die rechten toe te wijzen dan alleen root/niet-root.
Maar op zich, gegeven dat er geen andere manier is om de toegang tot de klok te beperken, is het hebben van root-rechten best te verdedigen.
Een voorbeeld hierbij zou bv kunnen zijn een bug in een netwerkdriver.
Dat klopt, maar dan zit de bug in de driver, en we hadden het over ntpd.
Ik vind dus dat er een ander mechanisme zou moeten zijn om die rechten toe te wijzen dan alleen root/niet-root.
Zulke mechanismes bestaan ook, onder Linux althans, zoals @vide al vermeldde. In het geval van ntp kun je met ./config --enable-linuxcaps een ntpd bouwen die geen root nodig heeft, mits je kernel gecompileerd is met capabilities. Veel distro's gebruiken dit echter niet.

Het is in het algemeen wel waar dat het rechtenbeheer in Unix-systemen niet nauwkeurig genoeg geregeld kan worden en er teveel als root moet draaien dat eigenlijk maar heel beperkte taken nodig heeft.
Dat klopt, maar dan zit de bug in de driver, en we hadden het over ntpd.
Uit jouw verhaal blijkt dat echter niet, vandaar dat ik reageerde.
Jouw verhaal zegt in feite: "Als je proces user-rechten heeft, kun je NOOIT code met kernel-rechten uitvoeren".
Dat kan dus wel.
Dat deze ntpd-bug een iets ander verhaal is, staat los van het verhaal dat je hierboven plaatste. Dat verhaal klopt gewoon niet.
mits je kernel gecompileerd is met capabilities. Veel distro's gebruiken dit echter niet.
Zie daar het probleem.
Jouw verhaal zegt in feite: "Als je proces user-rechten heeft, kun je NOOIT code met kernel-rechten uitvoeren".
Het is bijzonder irritant als mensen woorden in je mond leggen door je uit te leggen wat je "in feite" zegt. Please don't do that. Ik snap wat je zegt, maar het enige waar je me van kunt betichten is dat ik niet volledig ben geweest over wat buffer overflows allemaal kunnen doen. Ik heb nooit gezegd (en ook nooit bedoeld te zeggen) dat je via een user-mode programma geen buffer overflow in kernelcode kan exploiten. Context matters. Als ik een algemeen verhaal wilde plaatsen had ik het wel buiten dit nieuwsbericht gedaan, en dan had ik er ook veel meer alinea's aan moeten wijden.
Ik snap wat je zegt, maar het enige waar je me van kunt betichten is dat ik niet volledig ben geweest over wat buffer overflows allemaal kunnen doen.
Niet mee eens.
Ik heb nooit gezegd (en ook nooit bedoeld te zeggen) dat je via een user-mode programma geen buffer overflow in kernelcode kan exploiten.
Daar komt je verhaal anders LETTERLIJK op neer. Lees nog maar eens goed na.
Context matters.
Want?
Zoals ik al eerder zei, ik zie geen context waarbinnen jouw beweringen wel kloppen.
ntpd past namelijk de klok aan, en dat gaat wel degelijk via de kernel, ook al is ntpd zelf user-mode.
Misschien is dat de denkfout in jouw verhaal?
Ik zou nog eens goed nadenken over wat je eigenlijk wilde zeggen, en nog eens kritisch lezen wat je eigenlijk hebt opgeschreven. Want zoals ik al zei, wat er staat klopt gewoon niet. En het excuus van 'context' dekt de lading simpelweg niet.

Dit is dus het probleem:
NTP is een user-mode programma, dus zelfs als de memory protection geheel zou falen en je in een stuk kernelcode terecht komt (wat om te beginnen al niet kan) dan nog zou die code niet uitgevoerd kunnen worden omdat je niet in de juiste ring zit (dit is de beveiliging op processorniveau).
1) Een usermode programma is helemaal geen garantie dat er geen code in kernelmode wordt uitgevoerd. Usermode-programmas kunnen best functies aanroepen die uiteindelijk naar de kernel gaan (gebeurt heel vaak zelfs).
2) Je kunt dus prima in een stuk kernelcode terechtkomen vanuit usermode.
3) Die kernelcode kan prima uitgevoerd worden, zelfs als de memory protection NIET faalt.
4) Je zit dan dus WEL in de juiste ring.

Iets met klok en klepel, ben ik bang.

[Reactie gewijzigd door Scalibq op 24 december 2014 11:44]

Ik zou nog eens goed nadenken over wat je eigenlijk wilde zeggen, en nog eens kritisch lezen wat je eigenlijk hebt opgeschreven.
Dat lijkt me nu niet meer nodig. Ik denk dat wij elkaar begrijpen, en deze discussie voortzetten is niet interessant voor de rest.
Ik heb mijn reactie nog wat uitgebreid, en wat pijnpunten in je betoog aangestipt.
Als je buiten je process space gaat zal het OS de boel wel killen.
de NTP daemon loopt gewoon op de achtergrond. Je gaat echt geen popupje krijgen van je NTP om de tijd aan te passen.
Vreemd is las op een andere site dat de update automatisch ge´nstalleerd wordt zonder de toestemming van de gebruiker.

Niet dat dit slecht is, meer dat het hier niet vermeld staat.
Hangt ook van je instellingen af, als jij dit zo hebt ingesteld dan gebeurd dit op de achtergrond... anders niet.
Dit staat standaard aan (het onderste vinkje in de instellingen, alleen voor speciale security fixes, malware signatures etc.) dus tenzij iemand het bewust heeft uitgezet heeft iedereen dit meteen geinstalleerd.

[Reactie gewijzigd door Maurits van Baerle op 23 december 2014 10:28]

Ik moest deze update zelfstandig laten starten (wat ik vanavond pas doe).
http://cdn.onemorething.n...c8952bc5397512e_70696.png

Daar zie je dat ik op update moet en kan klikken.
Het is niet een kwestie van alleen maar een vinkje aan hebben staan. Het enige wat dat vinkje doet is zeggen dat ie 1 keer in de x tijd moet kijken naar updates en als hij deze vindt ze direct moet downloaden en installeren. Je bent echter nog steeds afhankelijk van die "x tijd". Het maakt nogal wat uit als deze op 5 minuten is ingesteld of 1x per dag of op een specifiek tijdstip. Als je dan je Mac niet zo lang aan hebt staan kan het zijn dat hij niet eens de kans krijgt om te checken. Of wat te denken van situaties waarin je geen internetconnectie hebt. Dan wordt het verschoven en kan het zomaar zijn dat ie niet diezelfde dag nog ge´nstalleerd wordt maar pas na een week.

Het kan dus even duren vooraleer die update wordt ge´nstalleerd ook al heb je dat vinkje aan staan. Zo was dit bij mij het geval op 2 Macs. Ik heb zelf op updates moeten checken omdat dit sneller ging dan afwachten tot ie het zelf ging doen. Had ik dat niet gedaan dan was de update in de loop van de dag (of week) vast wel ge´nstalleerd.
Automatische updates staan bij mij uit. Aangezien ik onderweg nog weleens met mn Macbook op de hotspot van mijn telefoon zit, kunnen die updates weleens veel data opslokken. Toch synct de app store niet helemaal vlekkeloos. Soms wel twee dagen later heb ik het idee.
Dat wordt het dus niet, kan ik bevestigen ;) Ik moest met de hand de update aanklikken (Waarschijnlijk omdat ik dat zo heb ingesteld). Overigens hadden mijn Debian machines de update de 20e al ;)
Precies, dat is misschien nog wel nieuwswaardiger dan de update zelf.

Toen ik gisteravond het scherm van mijn Mac aanzette zag ik in de bovenhoek heel even 'Security update installed', en was daarna onvindbaar. Ik heb uiteindelijk de logfiles van mijn systeem na moeten kijken wat er gebeurt was...

Dec 22 23:14:11 Miinii.local Software Update[2621]: Auto-download of "OS X NTP Security Update" SUCCESSFUL.
Mijn Ubuntu bakken hadden vanmorgen ook deze update, maar dat is blijkbaar geen nieuws ;)
Idd apart dat op een site als tweakers een update aan OSX als meer nieuwswaardig wordt gezien dan eenzelfde update aan servers waar meer dan de helft van het internet op draait..
Idd apart dat op een site als tweakers een update aan OSX als meer nieuwswaardig wordt gezien dan eenzelfde update aan servers waar meer dan de helft van het internet op draait..
De mensen die die servers beheren zijn geabonneerd op alle security buletins, en hebben al lang de update getest en uitgerold.

Tweakers is tegenwoordig veel meer toegespits op de normale consument, en dat is nou juist een doelgroep voor Mac OS X. Ergo, het is prima te verklaren waarom dat voor linux niet gemeld wordt, en voor OS X wel. Het is nou niet zo dat het marktaandeel linux op consumenten PC's echt groot is. ( ik dacht < 1%)
De vraag is, zit deze bug ook in de grootste Linux distributie van allemaal, Android?
Smartphones halen hun tijd op via de GSM verbinding en niet via ntp.

Een veel groter probleem zijn routers en mediaplayers. Updates doorvoor kun je echt op je buik schrijven en die dingen zijn altijd met internet verbonden. (Maar met de vorige bash bug zijn die dingen ook al als security failure bestempeld, om van heartbleed maar te zwijgen)

[Reactie gewijzigd door 118226 op 23 december 2014 09:52]

Smartphones halen hun tijd op via de GSM verbinding en niet via ntp.
Niet alle Android devices hebben GSM (de meeste tablets bv, en GoogleTV/AndroidTV, Chromecast, ChromeOS etc), en zelfs smartphones hebben niet altijd een GSM verbinding en werken dan via WiFi.
ChromeOS is geen Android. Chromecast ook niet. Die kunnen best NTP gebruiken.

Als een smartphone (even) geen GSM verbinding heeft dat wordt de tijd niet gesynchroniseerd. Hoe andere, niet smartphone devices, draaiend op Android het oplossen weet ik zo niet (en die heb ik inderdaad even over het hoofd gezien). Maar onderwater is het gewoon Linux, dus het zou kunnen dat er dan een NTP deamon draait.
Als je via WIFI werkt en een SIM in je toestel hebt zitten, heb je nog altijd verbinding met het 2G/3G netwerk. Via dat kanaal wordt de tijd gesynched.

Alleen als je een smartphone zonder SIM gebruikt heb je geen 2G/3G verbinding. Maar dat soort details is mierenneukerij want dat heeft vrijwel niemand.
Hoewel het GSM netwerk inderdaad een tijdsignaal mee stuurt verwacht ik eerlijk gezegd niet dat moderne smartphone OS-en er teveel op vertrouwen. Mijn ervaring met de netwerktijd is niet al te best (bij mijn oude Blackberry kon je instellen waar hij mee moest synchroniseren). Om als fabrikant er op te vertrouwen dat alle duizenden mobiele operators allemaal zo netjes met hun tijdsignaal om gaan zou ik niet doen als het niet hoeft.

Ik vermoed dat een moderne smartphone het GSM-netwerk signaal wel gebruikt om de tijdzone in te stellen (zo weet je telefoon nadat je hem na een vliegreis weer aanzet snel waar hij ongeveer is) maar dat er daarna liever op de Googles, Apples of Microsofts eigen NTP server vertrouwd wordt om de exacte tijd in te stellen. Pas als er dan na een paar minuten nog geen internet is dan heeft het zin om op GSM-netwerktijd terug te vallen.

Dat betekent dus dat er een NTP-client op veel smartphones zou draaien. Nou weet ik niet of deze vulnerability op de meeste smartphone OS-en net zoveel kwaad kan als op de meeste desktop OS-en.
Een beetje googlelen had je kunnen leren dat je verwachting/vermoeden niet klopt.

Kijk een naar NITZ: http://en.wikipedia.org/wiki/NITZ
Daar staat toch nergens dat smartphones geen NTP gebruiken? Er staat precies wat ik zeg, ze kunnen hun tijdzone halen uit het netwerk. Er staat bovendien dat NITZ niet erg betrouwbaar is.

Een beetje Googlen leert dat Android een combinatie van NITZ en NTP gebruikt middels NetworkTimeUpdateService

iOS gebruikt NSDate wat ook rond NTP is opgebouwd. Vermoedelijk gebruikt die Apples eigen NTP server per regio, voor ons is dat time.euro.apple.com.

Windows Phone gebruikt een combinatie van NITZ en NTP, standaard ingesteld op Microsofts eigen NTP server: time.windows.com

Kortom, smartphones gebruiken inderdaad NTP om hun tijd te synchroniseren. Of ze in de praktijk ook last hebben van dit probleem is een tweede. Het lijkt een probleem in de standaard en niet in een specifieke implementatie dus in theorie kan iedereen er last van hebben. Daarentegen zou het best wel eens een stuk moeilijker te exploiteren kunnen zijn op een mobiel OS.

[Reactie gewijzigd door Maurits van Baerle op 23 december 2014 12:04]

Nee, natuurlijk staat daar niets over NTP. Het is een pagina over NITZ. En er staat duidelijke een lijstje met telefoons die NITZ gebruiken. Waaronder de iPhone en zo'n beetje alle Android toestellen. Wat meer wil je nog hebben?

Over betrouwbaarheid heb ik niets gezegd, alleen dat het gebruikt wordt. Sorry, maar NITZ wordt nu eenmaal gebruikt. Iets anders kan ik er niet van maken.
De vraag is, zit deze bug ook in de grootste Linux distributie van allemaal, Android?
Als android een ntp daemon draait wel.
Of iOS natuurlijk, ik neem aan dat ze daar ook wel iets van tijdsynchronisatie hebben. Dit zijn allemaal vrij simpele fixes voor desktops en servers, maar een nieuwe iOS- of Androidversie ligt iets gecompliceerder.

[Reactie gewijzigd door Dubbeldrank op 23 december 2014 09:40]

Ja, maar een NTP deamon is wel iets algemeens dat vermoedelijk op heel veel linux systemen voor kan komen. Dus niet alleen pc's maar ook op alle linux devices/randapparatuur. Als je dan weer naar 'marktaandeel' kijkt dan heb je het over hele andere cijfers.
De vraag is dan natuurlijk of dit probleem zich ook op die devices voordoet.
Dat is precies het kip en het ei verhaal waar ik zo wantrouwend tegen ben. Want schrijft de media nu een apparaat/ OS of software omhoog voor de pageviews of durft het stelling te nemen en voert het echte journalistiek uit.

Edit ik reageer eigenlijk op kramer65
Wat bedoel je nu precies? Sinds wanneer is het aan de journalistiek om een bepaalde stelling te nemen? Dat is nu juist een valkuil.

Ik heb echter het idee dat diverse leden teveel gefocust zijn op het innemen van welke stelling dan ook, tegen Apple.
Nog niet zo heel lang geleden was het juist de journalistiek die een bepaalde stelling in nam. Iedere krant had z'n eigen signatuur dat overal werd doorgevoerd. Nu wordt het meer door verkoopaantallen gedreven (logisch, gezien de problemen waar nieuwsmedia mee te maken hebben). Maar een krant als het Reformatisch Dagblad neemt nog altijd duidelijk stelling vanuit hun beginselen.
Dat heeft meer te maken met de kernwaardes. Maar dat vind ik hier minder toepasselijk. Hier valt moeilijk een stelling in te nemen.
Dat ligt een beetje aan het soort stat wat je gebruikt. W3C rapporteert bijvoorbeeld 5%, terwijl Netmarketshare 1,25% stelt. Er zijn verschillende factoren die dit getal be´nvloeden, zoals sample size, welk soort publiek de website bezoekt en user agent switchers (populair op Linux omdat Linux op sommige websites geblocked wordt).

Ik neig zelf meer naar de 5% dan naar de 1,25%. Maar het blijft een beetje natte vinger werk.

Daarbij, zoals Dreamvoid ook al aangeeft, is Linux ook populair op andere platforms, denk buiten Android ook aan "internet of things" appliances die bijzonder vaak Linux gebruiken als basis.
Meer dan de helft van het internet draait Ubuntu? Geloof ik toch niet echt. Had je Linux gezegd, dan wellicht wel.
Waar heb ik het woord "Ubuntu" gebruikt? Ik doelde idd op het feit dat NTP op alle Linuxbakken zit..
De reactie waar jij op reageerde ging over Ubuntu specifiek, vandaar dus. Maar inderdaad, alle linuxjes met NTP waren de sjaak.
Heel flauw maar zeker waar: gebruik van het woord Apple levert geld op voor De Persgroep. Het woord Apple doet veel meer mensen klikken = nieuwe advertentie. Zowel vanaf de frontpage maar vooral ook na een zoekopdracht bij Google natuurlijk.

Of Tweakers ook al op deze manier werkt weet ik natuurlijk niet. Wel kan ik je vertellen dat de stagiairs van nu.nl die bij mij op de opleiding zitten, er gegarandeerd schouderklopjes voor krijgen.
Tweakers werkt al lange tijd op deze manier....

Pageviews = money.
Advertenties
We hebben een team verkopers dat, zonder invloed of zeggenschap op de redactie en Pricewatch contact heeft met fabrikanten en samen met hen probeert hun producten via bannering op de juiste plekken binnen Tweakers onder de aandacht te brengen. Fabrikanten betalen Tweakers op basis van het aantal impressies, oftewel het aantal keer dat hun banner op de site is vertoond. Hoe vaak er op wordt geklikt maakt voor onze inkomsten niet uit. Daarover lees je verderop meer bij 'Mythes ontkracht'.
http://tweakers.net/info/over_tweakers/verdienmodel

[Reactie gewijzigd door GroeneThee op 23 december 2014 09:18]

Wat een onzin, dit is gewoon beveiligingsnieuws zoals we dat voor allerhande besturingssystemen en software brengen. Als je vindt dat er nieuws over Linux is dat op de FP moet verschijnen kun je dat gewoon submitten.
Imo mag je van een redactie verwachten dat er wat onderzoek gedaan wordt over het nieuws, en er is geen groot onderzoek nodig om er achter te komen dat het een issue is dat op meerdere platformen speelt, en ook op meerdere platformen gepatched wordt. Het nieuws over de Bash-bug was in dat opzicht veel beter...
Ik heb gisteren ook de update binnen gekregen op Ubuntu 14.04.
Lijkt er op dat men op meerdere platformen snel handelt om beveiligingsproblemen te voorkomen.

Voor Red Hat was deze update al op 20 december beschikbaar:

https://rhn.redhat.com/errata/RHSA-2014-2025.html

:)
Ik zal het je sterker vertellen: ik kreeg deze update zelfs gisteren al binnen toen ik een updateronde deed langs al mijn computers thuis. Thuis heb ik voornamelijk Xubuntu, Lubuntu en Linux Mint op mijn bakken staan, en inderdaad: de patches onder het Linux-platform waren weer eens ouderwets retesnel. Maar ach.... dat is allemaal niet zo belangrijk. Onder een ander platform is het wŔl nieuws....

Het valt me op dat op Tweakers.net de laatste tijd helemaal niet zoveel Linux-gerelateerd nieuws meer op de site zet. Het is de laatste tijd alleen nog maar Windows, Apple, smartphone-gerelateerd en games-gerelateerd nieuws dat voorbij komt.

Er zitten zeker geen Linux-fans meer op de redactie? :X

[Reactie gewijzigd door Qalo op 23 december 2014 12:58]

Is er ook een update voor oudere systemen met OSX 10.7 en ouder beschikbaar ?
Nee. OS X 10.7 zit waarschijnlijk op hetzelfde als OS X 10.6 aan het eind van zijn leven. Dat eindigde in februari van dit jaar, maar de laatste update was van september 2013. Ik denk niet dat Apple nog enige intentie heeft om updates uit te brengen voor OS X 10.7.
Nee. OS X 10.7 zit waarschijnlijk op hetzelfde als OS X 10.6 aan het eind van zijn leven. Dat eindigde in februari van dit jaar, maar de laatste update was van september 2013. Ik denk niet dat Apple nog enige intentie heeft om updates uit te brengen voor OS X 10.7.
Wel apart dat wanneer Microsoft de stekker uit XP (2001) trekt, de wereld in brand staat maar als Apple de stekker uit een versie van OSX uit 2012 (!) trekt, is er niets aan de hand.

Wat een rare wereld is dit toch.
Microsoft is heel erg bezig met backwards-compatibility altijd. Nieuwe frameworks blijft Microsoft ook nog jaren uitbrengen voor een OS, dat doet Apple helemaal niet. Zo kwamen er voor Windows XP jaren later nog nieuwigheden in DirectX en .net. Bij Apple zitten dit soort dingen ingebakken in het OS. Ook is het zo dat Apple-gebruikers al jarenlang gewend zijn sneller te upgraden door de snellere release-cycle. Het aantal Mac gebruikers dat nog op een 8 jaar oud systeem zit is nog geen 5%, het aantal Windows gebruikers dat nog op een bijna 14 jaar oud OS zit is 10% (wereldwijd). Meer dan 75% van de Mac gebruikers zit op een Systeem dan minder dan 2,5 jaar oud is. Bij Windows-gebruikers is dat nog geen 20%.
Wel apart dat wanneer Microsoft de stekker uit XP (2001) trekt, de wereld in brand staat maar als Apple de stekker uit een versie van OSX uit 2012 (!) trekt, is er niets aan de hand.
Dat komt omdat er ook niets aan de hand is. Alle OS updates zijn sinds 10.7 gewoon gratis i.p.v. een retail versie van Windows 8 pro die 250 euro kost.
Ook voor 10.7.5 zie ik toch regelmatig Security Updates voorbij komen. Misschien dat de betreffende kwetsbaarheid niet in de NTP van de oudere vesies van OSX voor komt ?
10.7 wordt sinds de release van 10.10 niet meer ondersteund. De laatste update voor dat systeem is ergens in september geweest.
Nee Apple heeft al een tijd geen updates uitgebracht voor bijvoorbeeld OS-X 10.6 of OS-X 10.7. Deze versies zijn nog wel gewoon te koop in de Apple store. De nieuwe versies van OS-X hebben niet alleen maar voordelen, ook een paar nadelen, en dus kunnen er goede redenen zijn om een oude versie te gebruiken. Maar Apple waarschuwt in het geheel niet in de Apple store dat deze versies niet meer van updates worden voorzien, en dus gaandeweg steeds meer lek raken.

OS-X 10.6 heeft wat update ondersteuning grote overeenkomsten met Windows XP. Maar van Windows XP is inmiddels bekend dat men het niet meer (of met verhoogde voorzichtigheid) moet gebruiken, omdat Microsoft dit duidelijk geuit heeft.
Apple zwijgt helaas. Geen fraaie manier van communiceren (hoe klein de groep mensen die 10.6 gebruikt, of wil gebruiken ook is)
Ik zit zelf helaas nog steeds vast op 10.7.5. Vanaf 10.8 is er een nieuwe bug die bij bepaalde grafische toepassingen een nogal vervelend geheugenlek heeft. Daarnaast heeft Apple het AVFoundation Framework dusdanig dichtgespijkerd voor ontwikkelaars dat Yosemite voor mij helemaal onbruikbaar maakt.
Altijd goed dat er updates uitgevoerd worden om lekken te dichten! Ook is Apple tegenwoordig steeds sneller met het uitbrengen van fixes van zowel beveiliging als soft/hardware :)

[Reactie gewijzigd door icter-tje op 23 december 2014 08:16]

Die van mij gebruikt anders gewoon ntp (clocksync). Dat is tenminste enigzins betrouwbaar, met gsm zag ik op (vorige) telefoons toch behoorlijk wat drift, vandaar nu standaard app voor mijn devices.

Grrrr, was bedoeld als reactie op elbo 09:49

[Reactie gewijzigd door Dorank op 23 december 2014 11:16]

Ah, ik was dus niet op de hoogte van dit probleem
meteen de update er op geknald.

Ook meteen alle debian kisten even langs dan maar ! ( dit gaat wel weer even duren >.> )
Apple zegt nooit of een OS al dan niet ondersteund wordt - en dan wil men diensten gaan aanbieden voor bedrijven - dat gaat dik in orde komen!
Je bedoelt te zeggen "Ik heb nooit bekeken of een OS al dan niet ondersteund wordt" want dat is gewoon bekend. Daarnaast bieden ze al jaren oplossingen voor bedrijven, dik in orde blijkbaar gezien hun success.

[Reactie gewijzigd door Kura op 23 december 2014 17:32]

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