Onderzoeker vindt nieuwe kwetsbaarheden in OS X Lion
Een beveiligingsonderzoeker heeft in OS X Lion een aantal beveiligingsgaten gevonden die nog niet in oudere versies van Apples besturingssysteem aanwezig waren. Door de kwetsbaarheden kunnen mogelijk wachtwoorden worden gekraakt.
Beveiligingsonderzoeker Patrick Dunstan heeft ontdekt dat elke gebruiker in OS X Lion de ShadowHashData-bestanden van een willekeurige andere gebruiker kan opvragen; bij oudere OS X-versies was hiervoor nog het root-wachtwoord nodig. Met deze hashbestanden kan geprobeerd worden het wachtwoord van een gebruiker te achterhalen, bijvoorbeeld via een dictionary-aanval of met behulp van rainbow tables. Dunstan heeft een Python-script online gezet waarmee geprobeerd kan worden om de hashes in OS X Lion te kraken.
Dunstan is nog meer problemen in Lion tegengekomen. Zo is het mogelijk om in de directory services het wachtwoord voor de huidige ingelogde gebruiker te wijzigen zonder dat er om authenticatie wordt gevraagd. Dit is een potentieel beveiligingsprobleem als bijvoorbeeld een ingelogde gebruiker een terminalscherm onbeheerd open laat staan.
Het is nog niet duidelijk of Apple de genoemde gaten op korte termijn zal dichten. Vorige week bracht het bedrijf een patch uit waarmee ssl-certificaten van DigiNotar in OS X en Safari niet langer als betrouwbaar worden beschouwd. Daarmee was Apple het laatste grote bedrijf die dit probleem aanpakte.
Reacties (81)
Heerlijk dit soort nederlands! 
OT: Dit is wel echt slecht zeg, dat zonder authenticatie het wachtwoord kan worden veranderd. Bij mij op stage zie ik overal laptops, ook apples, openstaan waarbij dus zo het wachtwoord veranderd kan worden!
OT: Dit is wel echt slecht zeg, dat zonder authenticatie het wachtwoord kan worden veranderd. Bij mij op stage zie ik overal laptops, ook apples, openstaan waarbij dus zo het wachtwoord veranderd kan worden!
is op windows toch ook, "net user <name> <password>"?
Dat is met je administratorrechten een account resetten, wat eventueel toevallig je eigen account is. Heb je geen adminaccount dan werkt het niet.
Dat is per definitie een beveiligingsprobleem, als een gebruiker z'n scherm onbeheerd achter laat zonder de screensaver (OID) te activeren / te locken.Dit is een potentieel beveiligingsprobleem als bijvoorbeeld een ingelogde gebruiker een terminalscherm onbeheerd open laat staan.
Fysieke toegang is in alle gevallen een issue, als je mensen binnenlaat die je niet kunt vertrouwen.
Het minimale wat er iig in zou moeten zitten is dat je bij het wijzigen van een wachtwoord, het oude wachtwoord in moet vullen...
Dat zit er al standaard in.
In de "directory services" blijkbaar niet, volgens het artikel.
Edit: Dead Pixel legt het beter uit.
Edit: Dead Pixel legt het beter uit.
[Reactie gewijzigd door Aham brahmasmi op maandag 19 september 2011 12:37]
Vanuit een ander account heb je inderdaad het oude wachtwoord nodig. Maar vanuit de dezelfde gebruiker kun je het wachtwoord zonder het oude wachtwoord in te vullen het wachtwoord veranderen. Dit staat ook in het artikel van de hacker.
Ik vindt dat Apple hier ook een patch moet voor uitbrengen zodat, zoals jij zei, er om het oude wachtwoord wordt gevraagd. Ook al is het dezelfde gebruiker.
Ik vindt dat Apple hier ook een patch moet voor uitbrengen zodat, zoals jij zei, er om het oude wachtwoord wordt gevraagd. Ook al is het dezelfde gebruiker.
ik heb anders wel mijn wachtwoord nodig om mijn huidige wachtwoord te veranderen onder OS X...
Het werkt dan ook niet via de normale manier van veranderen. Lees het artikel, daarin staat beschreven hoe je het moet doen (namelijk via de directory services).
Fysieke toegang verlenen aan personen die je niet vertrouwt is natuurlijk één ding, maar toch klopt het inderdaad niet dat dit mogelijk mag zijn.
Ik heb nagegaan of het werkt zoals beschreven, en dat doet het ook op mijn Mac OS X 10.7.1 (Build 11B26). Geen FUD dus, maar ook geen gapend beveiligingsgat. Toch hoop ik op een snelle fix. Zelfs indien het op zich niet misbruikt kan worden, is het toch nog steeds een verzwarende omstandigheid wanneer een ander deel van de beveiliging (deels) gecompromitteerd wordt.
Edit:
DT-fout
Ik heb nagegaan of het werkt zoals beschreven, en dat doet het ook op mijn Mac OS X 10.7.1 (Build 11B26). Geen FUD dus, maar ook geen gapend beveiligingsgat. Toch hoop ik op een snelle fix. Zelfs indien het op zich niet misbruikt kan worden, is het toch nog steeds een verzwarende omstandigheid wanneer een ander deel van de beveiliging (deels) gecompromitteerd wordt.
Edit:
DT-fout
[Reactie gewijzigd door M0N0 op maandag 19 september 2011 13:12]
Veel mensen verlenen die toegang zonder er echt bij stil te staan. simpelweg door hun machine onbeheerd (lees: niet vergrendeld) achter te laten op kantoor of onderwijsinstelling. Kijk voor de grap maar eens om je heen.
In combinatie met bv een remote browser of SSH exploit is dit wel degelijk gevaarlijk. Daarom heet het artikel ook "Defence In Depth".
[Reactie gewijzigd door Dreamvoid op maandag 19 september 2011 12:08]
normaal gezien heb je een paswoord nodig voor belangrijke dingen te wijzigen, als je natuurlijk dit paswoord eerst zelf kan instellen (zonder het oude in te geven), dan kan je nadien alles wijzigen/doen wat je wil...
Als het goed is dan is het wachtwoord van een simpele gebruiker nog niets waard. Een gewone gebruiker mag ook niets wijzigen. Anders log je in met te veel rechten!
Of je nou achter een willekeurige PC plaats neemt, onebeerd je werkstation achterlaten en niet locken is erg dom. Zeker als je belangrijke of zelfs geheime gegegevens beheerd.
Maar het is zo snel gebeurd. Heb er ooit zelf een collega voor gewaarschuwd om nog geen 2 dagen later zelf in de fout te gaan. Collegas waren met mijn account informatie aan het opvragen waar ze geen recht toe hadden omdat ik vergeten was de PC te vergrendellen.
Bij mij is het zo'n gewoonte geworden dat ik mijn pc zelfs thuis vaak lock. Is een extra handeling geworden bij het opstaan 
Helemaal correct. Echter kan ik hier in linux mijn /etc/shadow niet dumpen. Stel dat je remote op een linux server ssh toegang hebt als user "pietje" voor werkzaamheden die je toegewezen zijn. Dan is het niet netjes dat de gebruiker "pietje" de crypted passwords mag inzien van anderen. En daar heeft het principe "fysieke toegang" helemaal niks mee te maken.
Helemaal waar, en aangezien er ook Mac OS X Lion servers draaien, is dit wel degelijk een reeel risiso.
Op mijn macbook staat ook de SSH service aan en heeft een vriend van mij toegang met z'n eigen account, ik zou het niet fijn vinden als hij mijn wachtwoorden kon uitlezen (wat hij in theorie nu dus kan).
Op mijn macbook staat ook de SSH service aan en heeft een vriend van mij toegang met z'n eigen account, ik zou het niet fijn vinden als hij mijn wachtwoorden kon uitlezen (wat hij in theorie nu dus kan).
[Reactie gewijzigd door JapyDooge op maandag 19 september 2011 13:17]
Daarom heb ik ook geen vrienden 
edit: typo
edit: typo
[Reactie gewijzigd door goestin op maandag 19 september 2011 14:21]
Dat klopt dat geldt voor ieder OS.[...]
Dat is per definitie een beveiligingsprobleem, als een gebruiker z'n scherm onbeheerd achter laat zonder de screensaver (OID) te activeren / te locken.
Maar wat niet geldt voro ieder OS is;
endat elke gebruiker in OS X Lion de ShadowHashData-bestanden van een willekeurige andere gebruiker kan opvragen
Bij iedere andere *nux varianten moet je al niet root gebruiker (uid 0) altijd eerst je oude wachtwoord in typen.Zo is het mogelijk om in de directory services het wachtwoord voor de huidige ingelogde gebruiker te wijzigen zonder dat er om authenticatie wordt gevraagd.
Als je shadow passwordfile world rendabele is is OSX wel erg ver terug gegaan in de tijd.
Nee, die maken zich niet zo druk om Windows! Interesseert mij het nu wat Windows doet! Snap die discussies dan ook nooit! Ga me toch niet druk maken om iets wat ik NIET heb?? Sneu.
Ik ga toch ook niet zeiken op een Opel forum als ik een Volkswagen heb??
Ik ga toch ook niet zeiken op een Opel forum als ik een Volkswagen heb??
Neej, idd, je maakt je op dit moment totaal niet druk, neej... Zelfs niet over een simpele opmerking over MS... 
Zonder uitroeptekens had ik je geloofd!!!
Zonder uitroeptekens had ik je geloofd!!!
[Reactie gewijzigd door KinGuiN op dinsdag 20 september 2011 14:28]
Hoe je het wendt of keert. Dat de encrypte strings in te zien zijn van gebruikers is niet netjes en gewoon fout. En of dat nu kan op linux, windows, osx, plan9, of op de gameboy mogelijk is, het is gewoon fout. go fix it.
Want fysieke toegang is lastig te krijgen? Kijkend naar de nonchalance waarmee veel mensen hun computer onvergrendeld achterlaten (kantoor/school) als ze even naar het toilet gaan of koffie gaan halen is dit een redelijk vervelend lek.
Spijkers op laag water zoeken wil ik het zeker niet noemen.
Spijkers op laag water zoeken wil ik het zeker niet noemen.
Sorry, apple is echt niet heiliger dan de paus. Ze hebben een fout gemaakt, ze hebben iets geintroduceerd dat mogelijk een veiligheidsrisico vormt. Mensen horen zoiets te weten. Veiligheid gaat voor alles.
Euhw neuw, dus als ik met mijn Macbook tussen een stel duistere figuren ga zitten en ik laat deze dan zonder te locken (of zelfs aan een slot te hangen?) achter om even een ommetje te maken of om te pissen dan zou het zomaar kunnen dat ze er iets mee kunnen!!
Goh..
bijna hetzelfde als een lopende cabrio in het centrum van Amsterdam achter te laten met de sleutels er in om even een plasje te plegen..
Goh..
bijna hetzelfde als een lopende cabrio in het centrum van Amsterdam achter te laten met de sleutels er in om even een plasje te plegen..
Nee. Als een gebruiker het kan doen, dan betekend het dat een applicatie dit ook kan doen. Dat hoort niet te kunnen, als een applicatie wil rommelen in het systeem zelf hoort het toestemming van de gebruiker te hebben dmv het wachtwoord. Dit onderzoek van deze meneer is dus helemaal prima. Het wil niet zeggen dat Lion zo lek als een mandje is, maar dat er wel zeker zwakheden zijn.
Dit is helemaal niet zo. Een gebruiker kan dit doen in een terminalvenster met root-rechten. In Mac OS X hebben programma's standaard geen root-rechten en moet dan dus wel eerst het wachtwoord ingevoerd worden. En je moet toch wel erg dom zijn om een programma root rechten te geven als het programma niet betrouwbaar is.Nee. Als een gebruiker het kan doen, dan betekend het dat een applicatie dit ook kan doen.
Desalniettemin zal Apple toch even een update moeten uitbrengen dat bij het veranderen van het wachtwoord sowiso het oude wachtwoord wordt gevraagd, maar echt hoog lijkt me dit beveiligingsrisico niet..
Heb je het artikel gelezen? Je hebt in dit geval dus geen root-rechten nodig om het password te wijzigen. Wanneer een gebruiker zijn Mac onbeheerd achterlaat is het dus een kwestie van een terminal openen (geen extra rechten nodig) en via die terminal de Directory Services aanspreken en vervolgens danwel de SHA512+4 hash kapen, danwel het password wijzigen.
Dit is een stuk eenvoudiger dan de procedure die normaal nodig is om (met fysieke toegang) het password te wijzigen, namelijk: booten in single user mode, of booten van install media. Daarnaast zijn deze 2 laatste methoden redelijk af te vangen door het gebruiken van een firmware password. Ook dat is in dit geval niet nodig.
Dit is een stuk eenvoudiger dan de procedure die normaal nodig is om (met fysieke toegang) het password te wijzigen, namelijk: booten in single user mode, of booten van install media. Daarnaast zijn deze 2 laatste methoden redelijk af te vangen door het gebruiken van een firmware password. Ook dat is in dit geval niet nodig.
De vergelijking zou kloppen als je de sleutels van de auto niet in de auto achterlaat, en dat mensen er toch met je auto vandoor blijken te kunnen gaan. Terwijl je dacht dat het risico kleiner was (en uit voorzorg had je je zonnebril en telefoon mee naar binnen genomen).
De verglijking klopt pas als je de sleutels wel meeneemt maar de auto niet op slot doet en daarna blijkt dat er mensen de auto in konden en de auto konden starten na een paar handelingen die auto-dieven kennen.. Doe verstandig en doe je auto steeds op slot, net als je mac..
Auto vergelijkingen gaan toch altijd krom met dit soort dingen...
Typerend Applefanboi commentaar. Altijd zeuren dat Windows onveilig is maar wanneer er iets met OS X is moet je maar gewoon zorgen dat niemand je pc aanraakt? ..
Ik vind het raar, dat er dan nu op die plaatsen beveiligings gaten zijn, terwijl dat in oudere versies nog niet was. Mijn mening is dat de makers van OS X Lion het dan gewoon te snel hebben af geraffeld.
ja osx word groter en dan moet alles sneller ,,
waar ze jaren op microsoft windows aan zeiken waren komen ze nu zelf in die situaties ,,
het groeien van een product gaat nooit zonder gevolgen
waar ze jaren op microsoft windows aan zeiken waren komen ze nu zelf in die situaties ,,
het groeien van een product gaat nooit zonder gevolgen
Dat valt nu ook wel weer mee, Apple gaat vooral prat op het niet aanwezig zijn van echte virussen, dit soort zaken zijn vaker voorgekomen en inherent aan het maken van een complex OS. Het gevaar wat hier wordt beschreven is nog behoorlijk beperkt en wordt waarschijnlijk tijdig gepatched... alleen maar goed dit werk!
@vgroenewold: Vandaar dit http://tweakers.net/nieuw...sscanner-installeren.html
Als ik dan vervolgens dat artikel leest wat jij aanhaalt, is de reden dat Apple dat doen aanraadde:
En als je de comments van dat artikel leest, of überhaupt op internet even gaat zoeken naar desbetreffende programma's dan komt het er op neer dat de virusscanners vooral op zoek zijn naar virussen voor het Windows OS (wat in principe niks met OS X te maken heeft, hoewel het er natuurlijk niet thuis hoort in je OS X).
Over virussen gesproken, heb je een bron voor mij waarin wordt aangetoond dat die er daadwerkelijk zijn voor OS X?
Malware is er overigens wel, hetzij gelukkig niet veel.
Natuurlijk moet Apple deze kwetsbaarheden zo snel mogelijk herstellen, dit mag niet mogelijk zijn.
De reden waarom een virusscanner wordt aangeraden door Apple is dus niet de aanwezigheid van virussen, maar een extra soort beveiliging (de virusscanner) om mensen ervan te weerhouden virussen te schrijven voor OS X.Een virusscanner is volgens Apple nodig, zodat programmeurs van virussen om meer dan een programma heen moeten om het systeem binnen te dringen, zodat het lastiger wordt om een virus te schrijven voor Mac Os X.
En als je de comments van dat artikel leest, of überhaupt op internet even gaat zoeken naar desbetreffende programma's dan komt het er op neer dat de virusscanners vooral op zoek zijn naar virussen voor het Windows OS (wat in principe niks met OS X te maken heeft, hoewel het er natuurlijk niet thuis hoort in je OS X).
Over virussen gesproken, heb je een bron voor mij waarin wordt aangetoond dat die er daadwerkelijk zijn voor OS X?
Malware is er overigens wel, hetzij gelukkig niet veel.
Natuurlijk moet Apple deze kwetsbaarheden zo snel mogelijk herstellen, dit mag niet mogelijk zijn.
Dat is een worm, geen virus en dan nog iets uit 2006 ergens welke geen enkele bedreiging is geweest of geworden.
Gelukkig zijn virussen een stuk gevaarlijker voor gebruikers dan malware...
Maar blijf vooral ontkennen dat er virussen voor mac en Unix zijn, de rest van de wereld weet onderhand wel beter...
Maar blijf vooral ontkennen dat er virussen voor mac en Unix zijn, de rest van de wereld weet onderhand wel beter...
Kom maar met een bron... de reden dat Unix wordt gebruikt voor veel servers is juist o.a. het ontbreken van echte grote bedreigingen vanuit het virus-veld. Waarom dat altijd zo ontkent wordt vind ik zo typisch, alsof het een rechtvaardiging moet zijn voor die duizenden duidelijke Windows virussen. Dat speelt bij OSX en Unix gewoon niet.
[Reactie gewijzigd door vgroenewold op dinsdag 20 september 2011 14:53]
Zie je mij ergens MS bugs goedpraten?? Niet, leg me dan ook geen woorden in de mond, aub... Het gaat erom dat er al jaren door mensen die er weinig verstand van hebben, geroepen wordt dat er voor mac en Unix geen virussen zijn, zonder verdere onderbouwing.. Zodra er dan iemand zegt dat dit niet zo is, worden echt alle registers opengetrokken om die persoon aan te vallen...
Maar je wilt links?? Symantec betrouwbaar genoeg???
http://www.symantec.com/s...docid=2002-021614-0555-99
http://www.symantec.com/s...docid=2004-021617-3040-99
http://www.f-secure.com/v-descs/bliss.shtml
Verder:
Unix.Abuser
Unix.Bash
Unix.Demo
UNIX.DirWorm
Unix.Dumb.A
Unix.Dumb.B
Unix.Gift
UNIX.Intender
Unix.Jaded
Unix.Klizan
Unix.LoveLetter
Unix.ls
Unix.Molus
Unix.Owr
Unix.Penguin1
Unix.PSite
Unix.Rubyparadox
Unix.Silly
Unix.Tvar
Unix.Unsafe
Unix.Vamp
Unix.Zoonic
Linux.Abditive.Worm
Linux.Abulia
Linux.ADM.Worm
Linux.Adrastea
Linux.Alaeda
Linux.Amalthea
Linux.Backdoor.IN
Linux.BinFly.Trojan
Linux.Binom
Linux.Bliss.A
Linux.Bliss.B
Linux.Cassini
Linux.Crimea
Linux.Cron
Linux.DDoS.MStream
Linux.Debilove
Linux.Derfun
Linux.Dido
Linux.Dies.969
Linux.Diesel
Linux.Doggie
Linux.DoS.tfn2k.td
Linux.DoS.trinoo.ms
Linux.DoS.trinoo.ns
Linux.Dummy
Linux.Dup.Trojan
Linux.Durock
Linux.Durock!inf
Linux.Elend
Linux.Emwerm.Worm
Linux.Eriz.Int
Linux.Flooder
Linux.Gildo
Linux.Hermalite
Linux.HLLO.Dirax
Linux.Holawor
Linux.Kagob
Linux.Kitw.Worm
Linux.Kork.Worm
Linux.Lotek
Linux.Mandragore.666
Linux.Metis
Linux.Mixter
Linux.Nel.A
Linux.Neox.A
Linux.Nuxbee.1411
Linux.Obsid.gen
Linux.Orig
Linux.Ovets
Linux.Pavid
Linux.Phobi
Linux.Quasi
Linux.Rike
Linux.RST.A
Linux.RST.Trojan
Linux.Satyr
Linux.Scalper.int
Linux.Sickabs
Linux.Siilov.5916
Linux.Silv5444
Linux.Silvio.B
Linux.Snoopy.A
Linux.Snoopy.B
Linux.Snoopy.C
Linux.Spork
Linux.Staog
Linux.Tarog
Linux.Thebe
Linux.Vit.4096
Linux.Ynit.827
Linux.Zipworm
Linux.Zone.A
MacOS.ChinaTalk
MacOS.CursorPrank
MacOS.DimWit
MacOS.Frankie
MacOS.HotlineDelete
MacOS.HotlineServer
MacOS.Legacy
MacOS.NaughtyLeftovers
MacOS.Oldgirl
MacOS.Scores
MacOS.SubSeven
Zoals jij het nu brengt, moeten mensen zich maar niet druk maken, omdat er zo weinig zijn.. "Ja, zet die miljoenennota maar vast op z'n plek, er zullen vast niet zoveel mensen gaan kijken oftie er al staat.."
Maar je wilt links?? Symantec betrouwbaar genoeg???
http://www.symantec.com/s...docid=2002-021614-0555-99
http://www.symantec.com/s...docid=2004-021617-3040-99
http://www.f-secure.com/v-descs/bliss.shtml
Verder:
Unix.Abuser
Unix.Bash
Unix.Demo
UNIX.DirWorm
Unix.Dumb.A
Unix.Dumb.B
Unix.Gift
UNIX.Intender
Unix.Jaded
Unix.Klizan
Unix.LoveLetter
Unix.ls
Unix.Molus
Unix.Owr
Unix.Penguin1
Unix.PSite
Unix.Rubyparadox
Unix.Silly
Unix.Tvar
Unix.Unsafe
Unix.Vamp
Unix.Zoonic
Linux.Abditive.Worm
Linux.Abulia
Linux.ADM.Worm
Linux.Adrastea
Linux.Alaeda
Linux.Amalthea
Linux.Backdoor.IN
Linux.BinFly.Trojan
Linux.Binom
Linux.Bliss.A
Linux.Bliss.B
Linux.Cassini
Linux.Crimea
Linux.Cron
Linux.DDoS.MStream
Linux.Debilove
Linux.Derfun
Linux.Dido
Linux.Dies.969
Linux.Diesel
Linux.Doggie
Linux.DoS.tfn2k.td
Linux.DoS.trinoo.ms
Linux.DoS.trinoo.ns
Linux.Dummy
Linux.Dup.Trojan
Linux.Durock
Linux.Durock!inf
Linux.Elend
Linux.Emwerm.Worm
Linux.Eriz.Int
Linux.Flooder
Linux.Gildo
Linux.Hermalite
Linux.HLLO.Dirax
Linux.Holawor
Linux.Kagob
Linux.Kitw.Worm
Linux.Kork.Worm
Linux.Lotek
Linux.Mandragore.666
Linux.Metis
Linux.Mixter
Linux.Nel.A
Linux.Neox.A
Linux.Nuxbee.1411
Linux.Obsid.gen
Linux.Orig
Linux.Ovets
Linux.Pavid
Linux.Phobi
Linux.Quasi
Linux.Rike
Linux.RST.A
Linux.RST.Trojan
Linux.Satyr
Linux.Scalper.int
Linux.Sickabs
Linux.Siilov.5916
Linux.Silv5444
Linux.Silvio.B
Linux.Snoopy.A
Linux.Snoopy.B
Linux.Snoopy.C
Linux.Spork
Linux.Staog
Linux.Tarog
Linux.Thebe
Linux.Vit.4096
Linux.Ynit.827
Linux.Zipworm
Linux.Zone.A
MacOS.ChinaTalk
MacOS.CursorPrank
MacOS.DimWit
MacOS.Frankie
MacOS.HotlineDelete
MacOS.HotlineServer
MacOS.Legacy
MacOS.NaughtyLeftovers
MacOS.Oldgirl
MacOS.Scores
MacOS.SubSeven
Zoals jij het nu brengt, moeten mensen zich maar niet druk maken, omdat er zo weinig zijn.. "Ja, zet die miljoenennota maar vast op z'n plek, er zullen vast niet zoveel mensen gaan kijken oftie er al staat.."
Daarom zei ik "Alsof het een rechtvaardiging is"... als in, dat maak ik ervan
Ok, wellicht (en heel misschien) zijn er wat virussen bekend... moet ik me nog inlezen in hoe verre dat ook echt virussen zijn (want veel van die lijstjes gaan daarin mank). Het gaat erom of die ook duidelijke bedreigingen vormen, zijn ze op de huidige systemen een bedreiging, etc. In vrijwel geen van de gevallen zal het gaan om een type virus wat net als onder Windows zich zo gemakkelijk weet te verspreiden, anders had ik dit echt niet geroepen hoor.. ik heb echt geen bord voor m'n kop, maar probeer wel een beetje realistisch te denken. Als die MacOS gevallen echt virussen zijn, dan had ik daar allang veel meer over gehoord. En ik lees vrijwel altijd dit soort zins-snedes (als in je 3e link): "Bliss does contain potentionally harmful code, but it is unclear if this is executed or not." met daarbij nog het feit dat het een "virus" uit 1997 is. En je 2e link: "Risk Level 1: Very Low".
Verder zijn er al een aantal wedstrijden geweest, zelfs, om virussen te schrijven voor beide systemen. Dat leverde niet echt wat op.
Ok, wellicht (en heel misschien) zijn er wat virussen bekend... moet ik me nog inlezen in hoe verre dat ook echt virussen zijn (want veel van die lijstjes gaan daarin mank). Het gaat erom of die ook duidelijke bedreigingen vormen, zijn ze op de huidige systemen een bedreiging, etc. In vrijwel geen van de gevallen zal het gaan om een type virus wat net als onder Windows zich zo gemakkelijk weet te verspreiden, anders had ik dit echt niet geroepen hoor.. ik heb echt geen bord voor m'n kop, maar probeer wel een beetje realistisch te denken. Als die MacOS gevallen echt virussen zijn, dan had ik daar allang veel meer over gehoord. En ik lees vrijwel altijd dit soort zins-snedes (als in je 3e link): "Bliss does contain potentionally harmful code, but it is unclear if this is executed or not." met daarbij nog het feit dat het een "virus" uit 1997 is. En je 2e link: "Risk Level 1: Very Low".
Verder zijn er al een aantal wedstrijden geweest, zelfs, om virussen te schrijven voor beide systemen. Dat leverde niet echt wat op.
[Reactie gewijzigd door vgroenewold op dinsdag 20 september 2011 16:39]
Mooi hè, dat zelfs beveiligingslekken door fanboys worden gezien als goed werk!! Want apple doet niets fout, das gewoon een feature, of ze willen gewoon even kijken of hun gebruikers nog wel wakker zijn!!!
Damn, wat een bord heb je er dan voor hangen, zeg...
Damn, wat een bord heb je er dan voor hangen, zeg...
Je leest duidelijk niet, vrij typerend voor een basher. Ik doelde op goed werk van de onderzoeker, dit kan nu simpel gepatched worden voor het een probleem wordt. En als je me een beetje kende denk ik dat je fanboy als aanduiding niet had gebruikt.
Mijn excuses, maar dan had je die laatste zin iets duidelijker moeten neerzetten... Ik las daar inderdaad in dat je de bugs goed werk vond...
Lion heeft nog een ander probleem: bij LDAP wordt bij authenticatie enkel gecontroleerd of de gebruikersnaam bij het domein bekend, je kunt elk welk willekeurig wachtwoord in het wachtwoord veld opgeven en je kunt aanmelden op de client. (zelf ondervonden)
Link: http://www.theregister.co...c_osx_lion_security_hole/
Link: http://www.theregister.co...c_osx_lion_security_hole/
[Reactie gewijzigd door ieperlingetje op maandag 19 september 2011 12:21]
hmmm, ik kan dat probleem toch echt niet reproduceren op mijn setup. Misschien als de gebruiker waar je mee inlogt ook als OD administrator te boek staat, maar normale gebruikers lukt 't mij niet mee.
De echte reden waarom Steve Jobs zijn functie heeft neergelegd
[Reactie gewijzigd door Inproba op maandag 19 september 2011 12:33]
Bij Active Directory kan een beheerder (beter gezegd: iedereen met voldoende rechten) het wachtwoord van een gebruiker resetten zonder dat het oude password hoeft te worden ingevoerd, dat is wel zo handig bij vergeten passwords
Ik zie het probleem bij die directory services-vulnerability dus ook niet.
Ik zie het probleem bij die directory services-vulnerability dus ook niet.
Het probleem is dat de gebruiker het zelf ook kan hier.
Dit lukt je onder bijv. Windows niet, daar zul je toch echt je oude wachtwoord moeten opgeven.
Dit lukt je onder bijv. Windows niet, daar zul je toch echt je oude wachtwoord moeten opgeven.
Daar zeg je het precies. hier kan iedere gebruiker het van zijn eigen account zonder het oude wachtwoord in te voeren.beter gezegd: iedereen met voldoende rechten
Deze zijn niet vulnerable want je moet een gebruiker zijn met bepaalde rechten. Die rechten leg je zelf vast c.q. je moet dit zelf veranderen standaard kan alleen root dit.Ik zie het probleem bij die directory services-vulnerability dus ook niet.
de echte vulnerability lijkt hem te zitten in het kunnen zien van de shadow hash. Het zonder password kunnen wijzigen van een user pass is nog steeds een vervelende flaw, dat hoort een user mijns inziens niet op die manier te kunnen (een admin dan weer wel maar dat kan ook allang).
Kortom: elke user (of iemand met toegang tot de desktop van die user, al dan niet fysiek) kan zonder het bestaande password te weten het password van een user wijzigen. Dat wordt een pijnlijke dag voor Apple als iemand een succesvol stukje malware bouwt dat dit lek misbruikt..
"Duizenden Mac-gebruikers buitengesloten door malware." <-- zoiets?
Kortom: elke user (of iemand met toegang tot de desktop van die user, al dan niet fysiek) kan zonder het bestaande password te weten het password van een user wijzigen. Dat wordt een pijnlijke dag voor Apple als iemand een succesvol stukje malware bouwt dat dit lek misbruikt..
"Duizenden Mac-gebruikers buitengesloten door malware." <-- zoiets?
Bij de OSX implementatie van OpenLDAP kan een niet Admin dat ook. En dat is het verschil.
Dit is natuurlijk gewoon een beveiligings issue, toch vind ik het knap dat sommige mac gebruikers het nog goed praten ook... Je kunt toch gewoon snappen dat dit een risico is voor eventuele Macs die aan een netwerk gekoppeld zijn binnen een bedrijf?
Kwalijke zaak als je het mij vraagt.
Kwalijke zaak als je het mij vraagt.
Het risico valt wel mee in verhouding met andere typen risico's, dat is wat er bedoelt wordt. Dat het een risico is zal ik niet betwisten.
als een kwaadwillende fysieke toegang heeft tot je computers en netwerk, ben je sowieso de sigaar, daar bestaat haast geen bewapening tegen.
(of liever: die bestaat wel, maar vrijwel niemand implementeerd dat, omdat het veel te moeilijk is voor de beheerders)
(of liever: die bestaat wel, maar vrijwel niemand implementeerd dat, omdat het veel te moeilijk is voor de beheerders)
Het gaat om proportionaliteit, ik vind de AD/ldap nog niet zo'n issue (overigens neem ik het aan dat het over ldap op osx server hebben, anders is het geen osx probleem), wel het feit dat je als gewone gebruiker bij de hashed shadowpasswords kunt komen.
wederom, niet echt vergelijkbaar met <insert random windows root exploit>
Overigens zijn al die apple fanboys die niet willen inzien dat alle software bugs bevatten net zo erg als al die windows fanboys die dit soort nieuws als een soort rechtvaardiging van de problemen op windows zien.
wederom, niet echt vergelijkbaar met <insert random windows root exploit>
Overigens zijn al die apple fanboys die niet willen inzien dat alle software bugs bevatten net zo erg als al die windows fanboys die dit soort nieuws als een soort rechtvaardiging van de problemen op windows zien.
Begrijp ik het nu goed dat als een admin een keertje op zo'n mac heeft ingelogd, deze hash dus te achterhalen is door een gebruiker?? Oftewel, in een kantorennetwerk heeft een gewone gebruiker "binnen de kortste keren" een admin gebruikersnaam en wachtwoord achterhaald???
des te groter het bedrijf des te trager word er gereageerd, het grote geblaat tegen o.a. microsoft komt nu wel erg snel bij de eigen gelederen.
Helaas is het ook weer zo dat de Mac die hard's het weer 'goed' proberen te praten erg vreemd weer.
Helaas is het ook weer zo dat de Mac die hard's het weer 'goed' proberen te praten erg vreemd weer.
Niet dat ik geen Windows Of Mac fan boy ben. Maar toch moet ik de bug(s) zeer nuanceren. Het is een nieuwe fout in het laatste product. En daarbij niet direct van buiten af exploiteerbaar. Een in het veld gevonden exploit die 10 jaar oude code gebruikt. En dus reeds 10 jaar schade kon veroorzaken is vele male erger.
desalniettemin is zeker de ontbrekende gebruikers authenticatie op directory services erg slordig. Omdat dit niet eens een exploit is maar niet functionerende code.
desalniettemin is zeker de ontbrekende gebruikers authenticatie op directory services erg slordig. Omdat dit niet eens een exploit is maar niet functionerende code.
[Reactie gewijzigd door daft_dutch op maandag 19 september 2011 13:24]
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht Galaxy S
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
