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

Apple brengt beveiligingsupdate voor ntp-kwetsbaarheid OS X uit

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.

Door Olaf van Miltenburg

Nieuwsco÷rdinator

23-12-2014 • 08:06

67 Linkedin Google+

Reacties (67)

Wijzig sortering
"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.
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.
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]

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.
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.
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.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True