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 , , 130 reacties
Submitter: CriticalHit_NL

OS X en iOS hebben een kwetsbaarheid gehad, waarmee aanvallers met het serveren van een enkel ip-packet een apparaat konden laten herstarten. Apple heeft de kwetsbaarheid van de week verholpen met OS X 10.10.3 en iOS 8.3.

De kwetsbaarheid heeft van de ontdekker, beveiligingsbedrijf Kaspersky Labs, de naam Darwin Nuke gekregen, omdat de kwetsbaarheid zit in de opensource Darwin-kernel van beide besturingssystemen. Gebruikers van Macs, iPads en iPhones die de update nog niet hebben gedaan, zijn kwetsbaar.

Behalve het herstarten kunnen aanvallers geen toegang krijgen tot het systeem met deze kwetsbaarheid. Door de kwetsbaarheid keer op keer te misbruiken om het apparaat zichzelf te laten afsluiten, is het mogelijk om iemand het werken ermee onmogelijk te maken.

De kwetsbaarheid bestaat eruit dat er een kernel panic komt, zodra een ip-packet een header van precies zestig karakters heeft, terwijl de load 65 karakters of minder moet zijn en er fouten moeten zitten in de ip-opties. Voor zover bekend hebben aanvallers deze kwetsbaarheid niet misbruikt bij een aanval. Of het lek ook in eerdere versies dan OS X Yosemite en iOS 8 zitten, is niet duidelijk. Eerder deze week kwam naar buiten dat Apple met OS X 10.10.3 een andere kwetsbaarheid heeft gerepareerd.

Darwin Nuke

Moderatie-faq Wijzig weergave

Reacties (130)

Normaal reageer ik nooit op iets maar deze reactie van Xieoxer is wel erg niet meer van deze tijd (understatement). Echte Apple gebruiker. Helaas leven we in een wereld waarin de realiteit is dat wat nu veilig is, ineens niet meer veilig kan zijn. Het kan al anders zijn als ik klaar ben met deze regl typen.

Elke - lees ELKE - vorm van software bevat bugs. Het is alleen een kwestie van tijd voordat ze gevonden worden en een kwestie van interesse of iemand er tijd in wil stoppen.

Het advies geven om geen beveiliging toe te passen en gewoonweg maar wat te doen is erg slim hoor. Ik hoop dat ze ook bij je terugkomen als hun banksaldo ooit een keer geplunderd is.
Ik gebruik al jaren geen virus scanner, en ik zou zelfs op windows geheel veilig bankzaken kunnen doen (dankzij de rabo-reader). Dus geen idee waar je het over hebt.

Maar mn bitcoin wallet zou ik nooit op een windows machine zetten, en ook al vertrouw ik mn mac meer zet ik hem daar ook niet op. Die heb ik mooi op mn iPhone staan. Ik weet vrij zeker dat ik daar niet zomaar een virus op krijg die bij mn bitcoins kan (lang leve sandboxing).

En bugs zitten zeker niet in alle software. Dat ligt puur aan complexiteit en prioriteiten die gesteld worden.
Ik snap de hypothese dat iOS volledig veilig is doordat het geen open systeem is niet. Er valt gewoon root toegang te krijgen op een dergelijk apparaat aangezien ze allemaal te jailbreaken zijn, dat betekent dat een hacker deze kwetsbaarheid ook kan gebruiken, en dus ook mee zou kunnen kijken naar je bankzaken.
Ik bedank je jailbreakers voor al hun harde werk. Daar word iOS uiteindelijk juist veiliger door. En als ik zie wat voor ingewikkelde handelingen ze moeten verrichten om te kunnen jailbreaken, én dat dat meestal een vaste aansluiting aan een pc verreist (wat ik nooit gebruik). Met dat nieuws voel ik me meestal alleen maar veiliger :).
alleen in heel erg simpele software zitten geen bugs en os'en vallen daar niet onder. Hoe hoog de prioriteit ook ligt.
Bankzaken doe ik bij voorkeur op de iPad. De geslotenheid van iOS is niet altijd even fijn, maar maakt het wel mogelijk om met vrij grote zekerheid virusvrij te kunnen werken. Zo lang iemand geen jailbreak heeft, dan lijkt me het niet nodig om extra maatregelen te treffen.
Ik werd we een beetje nerveus toen ik mijn ipad, waarmee ik mijn bankzaken regel, niet meer in mijn hotelkamer kon vinden. En op vakantie je bankrekeningen blokkeren doe ik ook niet graag. (Mijn ipad lag tussen twee matrassen in).
Hoezo zou je daar nerveus van worden? Je hebt neem ik aan een Passcode of wachtwoord nodig om een dergelijk apparaat te kunnen gebruiken, plus de losse passcode van de bank app. en dan eventueel ook nog eens een reader of tan codes. (sorry hoor, maar ik met 3 wachtwoorden/beveiligingsdingen maak ik me geen druk over diefstal van mn telefoon of iPad.

je weet lig zeker dat je nu geen virussen hebt. Iets wat je met android nooit kan zeggen.
Als je iPad weg is, dan is dat erg zonde van je geld, het is toch een paar honderd euro! Afgezien daarvan zou ik me niet te druk maken: als je er je bankzaken mee regelt dan zal je de beveiliging van de iPad an sich wel voor elkaar hebben (pincode/wachtwoord), op de app van je bank kan je waarschijnlijk ook niet veel zien tenzij je eerst inlogt en vervolgens zal je je transacties ook nog moeten bevestigen. Als je het zaakje niet vertrouwd als je iPad echt weg is, dan kan je m via iCloud ook nog eens het commando geven om zichzelf leeg te halen... Met andere woorden: er is in feite niks aan de hand!
Met het gebruik van tweestapsauthenticatie via een telefoon was er alsnog geen man overboord geweest. Daarnaast is het met de functie Find My iPad mogelijk om via elke webbrowser de iPad op afstand te locken of zelfs te wissen (of om hem een ping te laten geven, zodat je hoort dat hij tussen de matrassen ligt! ;) ).
Klein beetje offtopic maar ik gebruik Windows, Ubuntu, IOS en Android. Op de eerste drie doe ik met een gerust hart bankverrichtingen, op Android zoals het nu is, no way. Op een jailbroken IOS device ook niet. Het heeft dus inderdaad voor een stuk wel te maken met enkel zaken installeren die je vertrouwd en vanaf bronnen die je vertrouwd. Dat geeft geen 100% garantie dat het nooit mis kan lopen maar doet wel al heel veel.
Ik snap niet waarom je reactie ge-0-mod word, het klopt wat je zegt! Hoe zo'n leuk, mooi, open en aanpasbaar besturingssysteem Android ook is, beveiliging is één van haar zwakste punten. Alleen al het feit dat er buiten de Play Store om apps geïnstalleerd kunnen worden draagt sterk bij aan de slechte beveiliging. Daarnaast is het op Android ook nog mogelijk om een app allerlei dingen in de achtergrond uit te laten voeren...
Dat is een bewuste keuze die je als gebruiker aan moet zetten. Dus ben je daarmee verantwoordelijk voor de gevolgen die het kan hebben.

Daarnaast blijft het voor welk systeem dan ook zaak om te weten waar je apps vandaan haalt, wat je download, welke sites je opent etc. Plus een virusscanner kan nooit kwaad, eveneens ongeacht het besturingssysteem. Ik heb klanten die toch blij mogen zijn dat op hun OSX en Linux een virusscanner actief was, anders was het leed gelijk aan bijvoorbeeld Windows of wat dan ook.

Er is geen veilig besturingssysteem wanneer je gebruik gaat maken van toegang tot onbekende bronnen. Of dat nu het internet, apps, verwijderbare media of wat dan ook is.
Zodra je op iets van buitenaf op je device zet loop je al risico, geen enkel systeem is waterdicht. Je kan je risico's wel beperken, en waar ik op doelde is dat Android daar geen ster in is. Android geeft teveel vrijheid aan de gebruiker, waardoor die domme fouten kan maken.
Tsja, het "domme dingen doen" blijft de verantwoording van de gebruiker. Een systeem als iOS beschermt de gebruiker inderdaad tegen die dingen, maar vormt daarmee ook gelijk een behoorlijke beperking.

Met een auto neem je over het algemeen ook niet allemaal wildvreemden mee. Doe je dat wel, loop je ook zekere risico's. Gezond verstand en enig nadenken blijft dus cruciaal. Daar zijn we het over eens. ;)
:)

Klopt, maar dat je geen vreemden mag oppikken is voor non-techies nog wel te begrijpen, maar ik kan mijn vader niet aan het verstand peuteren wat wel of niet veilig is op zijn computer (het verschil tussen de linker en rechter muisknop en enkel of dubbel klikken zijn hem ook niet duidelijk, om even het niveau aan te geven). Feit is wel dat zulke mensen ook gebruik willen (en, in mijn vaders geval, moeten) maken van computers en tablets. Voor zulke mensen vind ik OS X en iOS toch beter dan Windows en Android, al was het alleen maar om de veiligheid en het gebruiksgemak.

[Reactie gewijzigd door biteMark op 13 april 2015 14:49]

Als digibeet lijkt mij één optie verstandig: Ken je het niet, klik er niet op. Wat via de officiële kanalen komt, is te vertrouwen. Maar duistere Chinese beschrijvingen zou reden genoeg moeten zijn om er niets mee te doen. Evenals op webpagina's alles klikken dat knippert of rondborstig is. Dat moet je als digibeet niet willen doen. Anders is het gelijk aan onveilige seks. ;)

Wat er doorheen glipt bij controles, is voor zowel Apple als Linux, Windows en Android gelijk. Dus 100% veilig is en wordt het nooit.
OSX heeft beveiliging ingebouwd, er zit gewoon antivirus, antimalware en firewall in. Dat het niet net zoals in windows werkt met een beveiligingscentrum, popups, tray-icons en andere zaken maakt niet dat het afwezig is. XProtect en Quarantaine zitten er al zeker 4 versies in.

[Reactie gewijzigd door johnkeates op 12 april 2015 17:29]

Ik had eerder een wtf, nu pas op Tweakers! momentje. Dit nieuws was al even bekend. (En de updates waren ook al geïnstalleerd)
Tja, dat is de keerzijde van populairiteit. Die komt er ook bij niet zo white-hat-hackers.

Het aan het licht komen van beveiligingsissues is mijn ogen vooral een goed ding. Software bedrijven die doen voorkomen alsof ze er geen hebben zijn naar mijn mening gevaarlijker.

Er is overigens geen misbruik van dit issue bekend en gezien wat er mee kan lijkt misbruik ook niet waarschijnlijk
Volgens mij zijn er eigenlijk alleen bedrijven als IBM met z/OS of anders True64 Unix of OpenBSD ofzo die nog proberen te verkopen dat hun systeem 'super veilig' is. Uiteraard kan je er wel verschillen in niveau in vinden, maar als je het puur op commerciële grote OS slijters houdt zijn bedrijven als Apple, Microsoft en Canonical echt niet aan het adverteren dat hun systemen waterdicht zijn.

Misschien dat je specifiek op Apple probeert te doelen, maar daar zijn ze echt wel met security bezig hoor:

- Xprotect ingebouwd sinds 10.6 of 10.7, anti virus, anti malware, volledig automatisch
- sandboxing system-wide
- gatekeeper zodat je niet zomaar software kan uitvoeren uit ongecontroleerde bron
- beveiligingsmodel dat standaard erg weinig rechten aan software geeft
- alle user-wijzigingen worden beperkt tot binnen de home directory
- de default browser staat niet toe onveilige plugins zoals oude flash of java uit te voeren

en zo zijn er nog wel wat dingen. Het is dus echt niet alsof aanvalsvectoren genegeerd worden. Er wordt ook gewoon geadverteerd met het feit dat er security monitoring bij het systeem zit om OS X specifieke problemen aan te pakken.
ik denk dat je je daarin nog goed kan vergissen. Een bedrijf wat voornamelijk/alleen maar met osX werkt kan volledig uitgeschakeld worden met de bug
Precies waar ik meteen aan dacht. Het zijn natuurlijk altijd uitzonderingen die problemen veroorzaken, maar een panic (of in de POD: buffer overflow) zou je toch wel afgevangen verwachten, of met een TCP/IP fuzzer gevonden worden.
De verleiding om te programmeren dat beide zijden van een communicatie protocol het protocol netjes volgen zal denk ik altijd wel groot blijven. Als mag het inmiddels wel duidelijk zijn dat je zo ongeveer elke input moet wantrouwen. Maar inderdaad je zou wellicht verwachten dat het met moderne tools wel eerder gevonden zou worden.
Ik zal ook al te denken aan bijv. RFC implementatie tests, daar zou je dan ook wel wat non-conformiteits checks in verwachten. Dat een RFC bijv. zegt dat er een X aantal bytes moeten zijn, en dat je dan checkt of dat zo is. Om dat je die test schrijft zou je ook verwachten dat je tests schrijft die er onder en boven zitten om te kijken of je implementatie bij non-RFC standaard input stand houdt. Waarschijnlijk is dat niet gedaan of is de codebase overgenomen en als 'werkend' beschouwd. Stel dat XNU (Darwin Kernel is niet een ding, de kernel van Darwin is XNU) bijv. een TCP/IP stack van BSD of Mach ofzo heeft overgenomen, dan zou het dus best kunnen dat daar de fout al in zat. De vraag is dan (om dat die historisch gezien zo lang gelezen opgezet is) of die bij de implementatie toen wel voldoende getest is.

Ik zou bijna in de OS X kernel sources gaan rondrijken om te zien waar de fout precies zit, maar dat is ook weer zo extreem :p
Als je TDD is het zeker van belang om niet alleen te testen met gegarandeerd valide input nee .. alleen soms kunnen de mogelijke fout combinaties nogal oplopen :)

En als het dan ook nog performance kritieke delen zijn .. dan wordt er al snel bezuinigd op al te veel checks (en soms assumpties gedaan dat iets al ergens anders in de code wel gecheckt is en dus niet gerechecked hoeft te worden.. wat soms dan ook zo is ... totdat die betreffende check dan weer door een code change gewijzigd of verwijderd wordt ...)

BSD tcp/ip stack mag toch ondertussen wel getest zijn .. waar zit die niet (in beginsel) onder :p
[...]
zou je toch wel afgevangen verwachten
[...]
Het grote probleem hierbij is dat steeds meer 'processorkracht' en geheugen gebruikt moet/gaat worden om de uitzonderingen af te vangen in plaats van te doen wat er moet gebeuren.

Een webserver is te bouwen in een miniem stukje geheugen met een handje vol regels code. Stel je voor dat je dat op je quad+ core 2+Ghz server kunt draaien!

Maar dat maakt software ontwikkeling ook nog leuk, 10 jaar geleden was iedereen nog bezig met dichtgetimmerde contracten (XML), wat te traag werd, nu gaan we over naar JSON wat weer een gebrek aan controle geeft en waarbij je de controle weer meer zelf doet. En dan komt daar weer een oplossing voor (die weer verdacht veel op XML lijkt ;) )

Daarom verbaast het me weinig dat er low-level nog wel wat checks ontbreken, die zijn namelijk heel duur (worden elke keer gedaan) en de mannen die daar aan bouwen zijn nog wat meer met performance bezig dan de high-level programmeertalen.

[Reactie gewijzigd door TheGhostInc op 12 april 2015 18:31]

Ja, maar deze check die mist is eigenlijk onacceptabel. Een kernel panic door user input staat eigenlijk altijd gelijk aan slechte foutafhandeling. Daarom ook die panic ;-) Dat betekent in dit geval waarschijnlijk niet eens dat XNU of Apple de schuldige is, maar eerder de bron waar de TCP/IP stack ooit vandaan getrokken is. Ik denk stiekem nog steeds dat dat een oudere revisie van een BSD stack is, en dat Apple vanaf een bepaalde revisie zelf aan het patchen geslagen is waardoor upstream patches niet meegenomen zijn. Dat is over het algemeen geen punt, tot dat blijkt dat er upstream een fout was en die daar wel gefixt is en op de Apple branch niet :P
Ja, maar deze check die mist is eigenlijk onacceptabel. Een kernel panic door user input staat eigenlijk altijd gelijk aan slechte foutafhandeling. Daarom ook die panic ;-)
Een kernel panic voor een stukje data dat van een extern systeem komt is sowieso al een drama. Maar aan de andere kant heeft het ook met ontwerpkeuzes te maken in het protocol.

In plaats van elke uitzondering te moeten checken, kunnen we ons ook afvragen waarom dit überhaupt een variabel onderdeel is. Het is natuurlijk schitterend dat elke vorm van communicatie over TCP/IP kan, maar misschien wordt het ook wel gewoon tijd om de stack een klein beetje uit te kleden, zodat we die 99,99% van het verkeer sneller kunnen afhandelen. En die 0,01% die buiten de boot valt, die kan ook prima in de payload worden gestopt.
Eenvoudig te fixen door de input te valideren. Het is misschien een idee wat mensuren vrij te maken om de andere input ook te valideren.
Dit soort Denial of Service fouten komen zelden met een hoog risico voor gewone gebruikers. Consumenten en klein bedrijf zit meestal achter NAT en zijn daarmee niet direct te targeten. Grotere bedrijven en professioneel gehoste servers hebben oa firewalls aan de rand van het netwerk die IP-packets met foutieve IP-opties filteren. Blijft over en klein percentage slecht beveiligde systemen die daardoor waarschijnlijk al flink risico lopen door tal van andere beveiligings issues.
Ik vind dat dit soort fouten in het juiste perspectief in het nieuws horen te komen. Leuk voor Kaspersky dat ze deze kwetsbaarheid gevonden hebben, maar echt bijzonder of hoog risico is het niet.
Het lijkt wel of het een hype begint te worden met de beveiligingslekken in iOS en OS X. :+

Des te populairder Apple begint te worden onder consumenten (als het dat al niet is) des te meer van dit soort berichten er komen. Het bedrijf richt zich de laatste jaren dan ook veel meer op consumentenproducten dan professionele toepassingen, vooral met de software.
Valt mee, alleen krijgt het wel meer aandacht.

De patch-rondes van MS krijgen praktisch geen aandacht terwijl het ook kwetsbaarheden moet oplossen.
https://technet.microsoft.com/security/bulletin/
Hoe meer lekken er ontdekt worden hoe beter het wordt. Op een gegeven moment zal het systeem vast wel dichtgeplakt zijn. Uiteindelijk krijg je dat een keurig systeem wat prima dichtgetimmerd is.
Uiteraard, aangezien iOS en OSX een steeds grotere userbase krijgen, en daarbij een steeds minder technische userbase worden ze aantrekkelijker voor black-hats.
is toch ook logisch? Wordt alsmaar interessanter voor hackers...
Waarom heeft windows zoveel last van virussen, niet omdat het zo'n een slecht OS is, maar wel omdat het zo populair is...
Nou, het OS is misschien niet slecht, maar helemaal met security in gedachte opgebouwd kan je het ook niet noemen. Eigenlijk is alles de laatste jaren er 'op geplakt'. DEP, UAC, ASLR, sandboxing enz. is allemaal vrij 'nieuw' in Windows land en ook niet origineel in Windows ingebouwd in de architectuur, maar 'toegevoegd' op plekken die overgeslagen kunnen worden. De beveiliging is niet system-wide, maar eerder een doosje waar je uit kan ontsnappen waarna er geen beveiliging meer is.

Neem bijv. POSIX security op Unix, BSD en Linux (en OS X), dat is system-wide en kan je niet 'negeren'. Het is geen laagje boven op een onbeveiligd systeem, en kan dus niet 'omzeild' worden voor onbeperkte toegang. Stel dat je langs een read beveiliging komt, dan is dat misschien voor 1 map of 1 bestand, maar dan kom je een ander bestand, een andere map, of een andere call weer gewoon beveiliging tegen.
... um, dat laatste is precies hetzelfde op WinNT zoals origineel ontworpen in 1989?
Nee, je kan als je bijv. op C: een handle kan openen met de rechten die je wil gebruiken die rechten gebruiken om alle onderliggende objecten te manipuleren.
Windows was eerder posix dan OSX bijv.
Onderliggende rechten op c: ( dus de root) zij er in windows niet. Wel bovenliggende ;)
Je haalt allerlei zaken hier door elkaar. Het rechtensysteem van windows is niks mis mee. Sinds NT zit dar net zo grondig in elkaar dan andere OS sen. Het windows probleem zat met name in een verkeerd (geadviseerd) gebruik en veel legacy die zwakheden mee moet nemen.
Windows was eerder posix dan OSX bijv.
Dat is wel raar, aangezien Darwin wel volledig posix compliant is en Windows niet...
Windows NT was POSIX compliant tussen NT 3.1 en 4.0, maar alleen met POSIX.1. In principe is Microsoft in staat om NT weer POSIX compliant te maken door het subsystem weer mee te compilen, maar waarom zouden ze?
Uit jouw link :
without threads or sockets
Dus net niet volledig. Maar goed, het hoeft geen muggenziften te worden.
Niet echt raar. Windows NT stamt uit 1993 en OS X uit 2001 Dus kon NT al posix compliant zijn voordat OS X in haar huidige vorm bestond.
De manier waarop rechten gecontaind worden is anders helemaal niet zo veilig. Het lijkt een beetje op het x86 ring systeem waarbij je zolang je maar in een bovenliggende ring komt je alles wat er onder zit kan manipuleren. Dat is wat ik bedoel.

Of een systeem POSIX compliant is of niet kan wel verschillen, maar ik heb het niet over de certificering maar over het POSIX rechten model.

Dat met NT toen eindelijk een bruikbaar rechtensysteem kwam was inderdaad een goede zet, maar dat maakt het nog niet veilig. En dan bedoel ik dus niet slechts de filesystem rechten en ACL's.
Dat is ook de reden waarom veel Linux distro's met SELinux of AppArmor komen (al dan niet ingeschakeld) omdat het rechten model an sich niet genoeg veiligheid biedt. Beetje jammer alleen dat de configuratie wat complex/lastig is en veel mensen het voor het gemak maar uitschakelen.

[Reactie gewijzigd door Jorick op 12 april 2015 19:39]

Nee, SELinux en AppArmor zijn er vooral om de granulariteit te vergroten. Het is zegmaar een ACL voor ACLs.
ehm, als je toegang hebt tot \Device\PhysicalDriveX dan wel, maar enkel \??\C: geeft je toch werkelijk geen rechten tot \??\C:\geheim als de ACLs dat niet toestaan, je niet de eigenaar van het object bent en niet SeTakeOwnershipPrivilege hebt...
\Device\PhysicalDrive[id] inderdaad. Ik weet nooit precies wat iemands niveau is, dus als ik een handle naar een schijf zou schrijven denken mensen van alles, maar als ik C: zeg is het voor de meeste mensen wel duidelijk dat ik de systeemschijf bedoel waar permissie en ACL niet op uitgeschakeld kan worden om dat Windows er actief op draait. Op andere schijven kan je natuurlijk gewoon toegangscontrole uitzetten en dan maakt het helemaal niet uit wat NTFS er van vind.

Los daar van: het gaat niet puur over filesystems, maar over de rechten die je nodig hebt, en dat zijn er bar weinig. Met 1 of 2 privileges kan je alles. Nagenoeg alle bruikbare toegangen leveren je carte blace op qua toegang. Beveiliging is leuk, maar als iedereen op aanvraag een loper krijgt is het idee dat meerdere sloten en meerdere deuren veiliger is opeens een stuk minder waar.
... maar op typische Unix-systemen kun je net so makkelijk de block-device openen als 'root' - dat Windows de standaardgebruiker lange tijd administratorrechten gaf is daaraan toch niet relevant...
Laten we block devices en filesystems even voor het voortzetten van de discussie vergeten, het was misschien niet het beste voorbeeld.

Wat ik bedoel is dat je onder Windows bij vrij veel API's hebt dat als je een call doet die elevation nodig heeft je die elevation kan vasthouden en zonder verdere vragen lekker door kan gaan. Er wordt niet geforceerd om de elevation op te geven.
Je past je kletsverhaal naadloos aan met de windrichting.
Je weet te weinig van het rechtensysteem van Windows dat is wel duidelijk. Verder is het erg veel klok en klepel verhaal waar ik eerlijk niet zon zin in heb om allemaal te weerleggen. Misschien dat iemand met meer geduld dat kan opbrengen?
uhh, je kunt op C ook alle rechten uitschakelen die je wilt, alleen zorg je dus zelf dan voor problemen, net zo goed als dat je dat zou doen bij andere OSsen.. Je kunt windows goed dichttimmeren als je daar de moeite voor neemt en je er in verdiept, net zo goed als bij andere OSsen...
Ja, maar dan komt het open source argument om de hoek kijken: alles kan totdat het op code niveau moet en dan kan het bij Windows niet.
Omdat Microsoft heeft nooit beweerd dat Windows veilig is, wel dat een versie veiliger is dan de vorige maar meer niet.

Apple heeft vroeger (nu niet meer) beweert dat hun OSX virusproof is, onzin kwestie van dat een hacker of virusmaker liever voor een platform kiest die 90% van de mensen gebruikt, in plaats van eentje waar 8% gebruik van maakt,

OSX is niet veilig omdat het veilig is, het is veilig geweest omdat er geen interesse in was dat groot genoeg was om het aan te vallen, dat veranderd langzaam.

iOS is daartegen een compleet ander verhaal, het is volledig dichtgetimmerd, je kan niks zelf doen maar zolang je geen gekke dingen als jailbreak doet is de kans op infectie door een virus erg laag, puur omdat het zo extreem gesloten is (en in dat geval is dat een voordeel).
En toch klopt dat dan weer niet, als je de regels die je toepast zou volgen. Immers zijn Macs van oudsher voor hen die net iets meer te verteren hebben, gezien de prijs, en dus in potentie meer geld zouden moeten kunnen genereren indien gehackt of besmet.
Als het makkelijk was, was het ook voor die 8% gebeurd.
Hacken is sowieso niet makkelijk, 0 day`s vinden al helemaal niet, dat geldt voor elk beveiligd en onderhouden gepatched OS, daar gaat een hoop tijd in zitten.

Pick your battles dus.
Mompelt iets met "liever 90x een stuiver dan 8x een kwartje"

[Reactie gewijzigd door Teijgetje op 12 april 2015 18:34]

iOS is daartegen een compleet ander verhaal, het is volledig dichtgetimmerd, je kan niks zelf doen maar zolang je geen gekke dingen als jailbreak doet is de kans op infectie door een virus erg laag, puur omdat het zo extreem gesloten is (en in dat geval is dat een voordeel).

Ah vandaar;
http://www.zdnet.com/arti...ozens-of-security-issues/

De complete lijst fixes vind je hier.
Das wel even scrollen......... ;)

[Reactie gewijzigd door Teijgetje op 12 april 2015 19:01]

Flink wat veranderd sinds dat ik 1,5 jaar weg van iOS ben gegaan, blijkbaar toch wel flink wat lekken in geweest, deels wist ik dat wel anders zou jaibreaken ook niet kunnen, maar dit is meer dan ik destijds dacht.

Weer eens wat nieuws geleerd :)
Een vriend van mij heeft eens een zaak gewonnen bij de Reclame Code Comissie, een jaar of 10 geleden. Microsoft beweerde toen dat ze het veiligste OS ter wereld waren. Ik geloof op de radio.
Ze zijn toen door de RCC verboden om het spotje nog uit te zenden.
Ja hoor vandaar dat er in 1982 al een virus was voor MacOS.

In 30 jaar tijd zijn er 15 virus/trojan/malwares geweest op mac, sinds OSX geen virus - alleen een proof of concept, verders malware.
1982? Volgens mij dateert de eerste versie van het Mac OS van 1984.
Dat was de Apple II, de Mac, met grafische interface, en Mac OS, kwam in 1984.
Onzin. Het probleem is *dat* er headlines te vinden zijn. ;)
Het genereert pas echt headlines op een systeem als OpenBSD.
Dat je er geen headlines over vindt, is zeer positief. Op het moment dat er wel headlines over komen, dan is er pas een probleem.

Dat iets meer headlines genereert is dus niet bepaald een mooie situatie.
Het lijkt wel een hype te worden van tweakers om werkelijk elk lek of ander negativiteit te melden als het om Apple gaat. Zolang het iets negatiefs is dan staat het er, software en hardwarematig. De bug is al opgelost met de meest recente update en niet misbruikt dus echt belangrijk is het niet. Over de talloze beveiligingslekken van android hoor je zelden iets. Een bug waarbij de flitser van de s6 continue brand horen we ook niks over. Over de buigbaarheid van de iphone zijn ongeveer 4 artikels geschreven waar de s6 en edge minder presteren alleen hoor je daar niks over.

Lijkt wel alsof bepaalde mensen bij tweakers een Apple allergie hebben, prima dat dit soort nieuws word geplaatst maar doe het dan net zo goed bij andere merken. Hoge bomen vangen meer wind alleen lijkt samsung me nou niet echt een bonsai.

Heb overigens zelf apperaten van zowel Samsung, Windows en Apple dus het maakt me verder vrij weinig uit maar het valt de laatste tijd wel erg op.
" waar de s6 en edge minder presteren alleen hoor je daar niks over. "

Hoebedoel je minder presteert? Benchmark liegen er niet om.

Zelf heb ik de iPhone 6+ op internet gaat het rond dat Apple Samsung nadoet. Denk eerder andersom.
Tothabone refereert aan Bendgate, en niets anders. Er wordt bedoeld dat die S6 net zo makkelijk of makkelijker te buigen is, als de iphone 6, maar dat je daar niets van hoort.

[Reactie gewijzigd door BeePee00 op 12 april 2015 16:19]

Niet alles hoor je hier anders, de iOS 8.3 bug met de gedeactiveerde vingerafdrukscanner wordt hier doodgezwegen bijvoorbeeld.

Of vergelijk de berichtgeving over de 8.3 release eens....

http://www.zdnet.com/arti...ozens-of-security-issues/
vs
nieuws: IOS 8.3 met Nederlandstalige versie Siri komt uit

Van Tweakers niets dan lof, toegegeven ZDnet was een dag later en wist toen pas van de dozijnen gedichte veiligheidslekken uit Apples bulletin een dag eerder. O-)

[Reactie gewijzigd door Teijgetje op 12 april 2015 19:15]

Heb je een link voor de gedeactiveerde scanner? Zou wel een bummer zijn namelijk als dat zo is.

Dat over de nederlandse versie van Siri is overigens wel erg laat gemeld vind ik. Dit was mij begin februari al bekend dacht ik.
Toen ik het eerder van de week las dacht ik nog "zal ik het nieuwstippen?" Maar ik dacht dat komt wel boven drijven bij Tweakers...
De scanner werkt gewoon, maar er schijnt een probleem te zijn met betalen via TouchID in de App store.

http://forums.macrumors.com/showthread.php?t=1864071

[Reactie gewijzigd door Teijgetje op 13 april 2015 01:52]

bump

[Reactie gewijzigd door CozNL op 13 april 2015 10:13]

Dit soort bugs waren in 1998 (ping of death anyone) nog gewoon. Dat ze 17 jaar later nog zoiets vinden is dus wel degelijk nieuws en geeft aan dat de industry nog steeds in de kinderschoenen staat. Kun je bashen noemen, ik noem het name-and-shame.
Tja veel in de publiciteit staan werkt beide kanten op. Elke scheet van Apple komt in het nieuws (ook op tweakers), of het nou gaat om negatieve berichtgeving als positieve berichtgeving. Dat is nou eenmaal zo als veel mensen op de berichten klikken. Apple maakt dankbaar gebruik van al die publiciteit als het gaat om het lanceren van nieuwe producten, dan krijg je ook met de keerzijde te maken.
Een hype zou ik het niet noemen, de hoeveelheid informatie die gepubliceerd wordt is niet zo zeer nieuw, maar het is vooral dat het op nieuwssites nu overgenomen wordt.
Je zou toch bijna zeggen dat het gewoon een computer is.. met code.. geschreven door mensen....

nah.... :P
Na het installeren van de iOS 8.3 update kreeg ik Popcorn Time niet meer aan de praat. Ik moest de app verwijderen, "Zoek mijn iPad" uitschakelen bij Instellingen -> iCloud en opnieuw installeren. Na het nodige gepruts heb ik ze weer aan de gang gekregen.

[Reactie gewijzigd door Titan_Fox op 12 april 2015 16:58]

Deze kwetsbaarheid is v.v.t. voor iedereen die zijn OS up to date houdt.
Zonder beveiligingslekken te weinig brood voor nieuwe dingen. Al zat ik dan weer helemaal niet op een ander fotoprogramma voorzien van stompzinnig icoon te wachten.

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