Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' 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 repareert kritieke sudo-kwetsbaarheid in macOS

Apple heeft een update uitgebracht voor macOS waarmee een kwetsbaarheid in het sudo-commando wordt gerepareerd. Daarmee was het mogelijk commando's met adminrechten uit te voeren. De fix was al eerder beschikbaar op Linux.

Het gaat om macOS Big Sur 11.2.1, macOS Catalina 10.15.7 Supplemental Update en macOS Mojave 10.14.6 Security Update 2021-002. Daarin wordt een bug in het sudo-commando gerepareerd. CVE-2021-3156 is een buffer-overflow-kwetsbaarheid die vorige maand werd ontdekt door beveiligingsonderzoekers van Qualys. Met de kwetsbaarheid is het mogelijk om met toegang tot een machine commando's in een shell uit te voeren met adminrechten.

Hoewel sudo als commando het bekendst is van het gebruik op Linux-distro's is het ook op macOS een populair commando. Bij de ontdekking wisten de onderzoekers een proof-of-concept uit te voeren op Ubuntu, Debian en Fedora. Op macOS werd dat niet geprobeerd. Er was ook al langer een patch beschikbaar, maar die wordt op Apple-besturingssystemen nu pas automatisch doorgevoerd.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Tijs Hofmans

Redacteur privacy & security

10-02-2021 • 11:17

65 Linkedin

Reacties (65)

Wijzig sortering
Is dit echt dezelfde bug als die op Linux? Ik hoop maar dat macOS verder mitigerende maatregelen treft in zijn besturingssysteem want het is al twee weken sinds de fix uitgerold is voor andere producten, en de CVE zelf komt van anderhalve week voor de uitrol begon.

Nu is Microsoft eindelink afgestapt van patch Tuesday voor dit soort dingen, gaat Apple hun securityfixes weken uitstellen. Niet echt chique. Als dit echt dezelfde bug is, ben ik benieuwd hoeveel malware in de tussentijd van de exploit gebruik heeft gemaakt. Het lijkt me dat iedere botnetauteur binnen dagen hun software heeft uitgebreid om zich nu nog dieper in het systeem te nestelen.
Is dit echt dezelfde bug als die op Linux?
Nouja, de bug is gemeld voor een aantal Linux distributies en expliciet niet getest op macOS. Het probleem zit in het 'sudoedit' commando wat niet op macOS aanwezig is. Nu blijkt de functionaliteit ook bereikbaar te zijn door een symlink van sudoedit naar sudo te maken. In die zin is er een (relatief eenvoudige) extra stap nodig. Ik begrijp wel dat het even geduurd heeft voordat dat duidelijk was.
Het lijkt me dat iedere botnetauteur binnen dagen hun software heeft uitgebreid om zich nu nog dieper in het systeem te nestelen.
Op Macs heb je ook nog System Integrity Protection. Sinds Catalina is het root filesysteem niet meer zonder meer schrijfbaar (ook niet voor de root user). Met default settings moet je hard je best doen om daar blijvende wijzigingen te doen...
Apple heeft de fix uitgebracht één week (9 feb) nadat bevestigd werd (2 feb) dat MacOS ook kwetsbaar is (al is de exploit blijkbaar wel moeilijker wegens aanwezigheid van checksum).

De exploit vereist in elk geval ook voorafgaande toegang tot de shell.
Voorafgaande toegang is natuurlijk altijd nodig als je privilege escalation wil uitvoeren.

Toch vind ik een week eigenlijk best lang als het gaat om een bekende exploit.
Zoals @Myaimistrue al aangeeft is het vrij snel gefixed. Daar komt bij dat dit natuurlijk een ernstig probleem is maar er is wel gebruikers toegang nodig (anders dan bijvoorbeeld de 3 beveiligingsproblemen die in de laatste Windows patch zijn opgelost).

Local privilege escalation problemen worden bij Microsoft ook niet direct gepatched en gedistribueerd. Daarvoor is een ernstig netwerk probleem voor nodig of de fout moet al in het wild worden misbruikt. Microsoft is verder ook niet van patch Tuesday afgestapt. Dat blijkt wel uit de meest recente update.

Uiteindelijk is het voor Microsoft simpel: men maakt een inschatting van de ernst en bepalen dan de uitrol. Als het kan wachten tot patch tuesday dan zullen ze dat ook echt doen. Ik neem aan dat het voor Apple (en alle anderen) niet anders is.
Het is weer typisch om te zien dat de Linux en BSD distro's hun patch klaar hebben op het moment dat zo'n lek wordt aangekondigd, dat de commerciele leveranciers een paar dagen later komen. En de "security wereld" komt daar weer na.
Sudo is een kern utility in Linux land. Veel van die appliances die op Linux draaien hebben een kopie aan boord. Je zou dus een enorme vloed aan patches voor al die appliances verwachten maar die heb ik nog niet gezien (wel een paar, maar minder dan ik aannemelijk vind).

Wellicht heeft dat er iets mee te maken dat die commerciele clubs meer willen testen en/of dat de security clubs pas iets willen publiceren als ze absoluut zeker zijn van de kwaliteit. Maar ondertussen zijn de meeste Linux-systemen inmiddels automatisch gepatched terwijl de duur betaalde security appliances nog bezig zijn met hun onderzoek.
Je zou bijna denken dat de Linux en BSD boeren voorkennis hebben. Best wel knap op iets als opgelost te hebben als het aangekondigd wordt.

Maar zonder gekheid: het is natuurlijk logisch dat commerciele bedrijven meer testen voordat ze iets releasen. Zij hebben SLA met afnemers en kunnen die pas nakomen als ze heel zeker zijn dat de nieuwe software werkt. Er hoeft maar 1 bug in te zitten (en dat kan ook heel ergens anders zitten) en ze kunnn de afspraken in de SLA niet nakomen met allen consequenties van dien.
Op het moment dat de devs van sudo de kwetsbaarheid bekend maken is de patch voor sudo ook gewoon beschikbaar. Vele distributies hebben voor vele van de tools die ze verschepen ook toegang tot security mailinglijsten van die tools waardoor zij op voorhand al weten dat dit eraan komt en vaak ook al de patch kunnen doorvoeren zodat ze hun packages klaar hebben op het moment dat het wordt aangekondigd, maar zelfs als dat niet het geval is, is het meestal een kwestie van uren voordat ze die patch zelf hebben doorgevoerd.

Dus voorkennis? Soms wel, soms niet maar zelfs zonder voorkennis zal het zelden dagen duren voordat de patch er is.
Je zou bijna denken dat de Linux en BSD boeren voorkennis hebben. Best wel knap op iets als opgelost te hebben als het aangekondigd wordt.

Maar zonder gekheid: het is natuurlijk logisch dat commerciele bedrijven meer testen voordat ze iets releasen. Zij hebben SLA met afnemers en kunnen die pas nakomen als ze heel zeker zijn dat de nieuwe software werkt. Er hoeft maar 1 bug in te zitten (en dat kan ook heel ergens anders zitten) en ze kunnn de afspraken in de SLA niet nakomen met allen consequenties van dien.
Er is ook voorkennis, er is een heel proces om dit soort problemen te melden zodat leveranciers kunnen zorgen dat ze een oplossing klaar hebben op het moment dat het probleem officieel wordt gepubliceerd.
Maar waarom zorgen die vendors dan niet dat ze zelf vooraan in de rij staan?
Als die Linux & BSD distributies het kunnen dan kunnen die commercielen het ook, zou je denken.
Ik denk dat het probleem is dat ze niet zelf bijdragen aan de software waar ze hun product bovenop bouwen (zoals Linux en sudo) maar dat ze wachten tot de Linux-distributies het werk voor ze opknappen.

Je kan je ook afvragen of de prioriteiten goed liggen. Het snel dichten van zo'n gat heeft blijkbaar minder prioriteit dan zorgen dat "het werkt". Veiligheid zou een groot onderdeel van SLA's moeten zijn.
Ik download the update op dit moment voor mijn macOS 10.14.6 computer, en dit blijkt een update van 1,73GB te zijn.

Kijkende naar de release notes zit hier niet alleen de sudo fix in. Er stonden nog meer fixes in de queue. Ook een Intel Graphics driver security update.

Zo'n update testen op bij-effecten is waarschijnlijk de reden dat het niet in een paar uur uitgerold kan worden.

In mijn tijd als software product manager bij een telefoonmakertje moesten heel veel mensen over de hele wereld akkoord geven voordat een update richting klanten gepushed mocht worden. Ik ga er van uit dat dit bij Apple niet anders is.
Een security patch op sudo hoeft echt niet in een update van 1,73GB gepropt te worden. Dat zijn keuzes. Een patch op 1 package kan net zo goed als alleen die patch worden uitgerold op het moment dat die beschikbaar is. Door dit soort patches te bundelen met andere patches en updates, ga je dat proces hoe dan ook vertragen.
Bij de ontdekking wisten de onderzoekers een proof-of-concept uit te voeren op Ubuntu, Debian en Fedora. Op macOS werd dat niet geprobeerd.
Waarom dat dan weer niet :?
Misschien dat de onderzoekers op Linux focussen en niet toevallig een Mac hebben liggen?
Hoe serieus ben je dan met je vak bezig als je niet 1 van de grootste platforms in huis hebt. Dan is het hobby, niet meer dan dat.
Sure, Apple 1 v.d. grootste platforms? Dat kun je niet serieus menen. Apple heeft minder dan 10% van de markt (Google maar even), waarvan niet eens duidelijk is wat er allemaal in dat aandeel meegeteld wordt.

Waar ik gewerkt heb, was Mac voor de managers (laptops), niet voor backend systemen. Je mag hopen dan mobiele apparaten geen core-data bevatte. Dat hoort ergens beter opgeslagen te zijn, in backend of cloud oid.Linux zie ik zelf helemaal zelden op end-user systemen, vandaar dat ik de sudo problemen aan backend systemen koppel. Als developer die bugs op lost, had je dus geen Apple tot je beschikking...
Volgens deze bron heeft OS X op de desktop in het Verenigd Koninkrijk een marktaandeel van 28.7%.

Wikipedia heeft het over een globaal aandeel van 17.1% in December 2020 en citeert StatCounter.

[Reactie gewijzigd door AndrewF op 10 februari 2021 17:46]

Het is inderdaad niet het grootste maar wel een serieuze. In de VS is het marktaandeel hoger, zeker in vergelijking met Nederland.
Het geeft ook een vertekend beeld: zakelijk is het vooral Windows dat de klok slaat. Maar daardoor mag je macOS niet uitvlakken.
Sure, Apple 1 v.d. grootste platforms? Dat kun je niet serieus menen. Apple heeft minder dan 10% van de markt (Google maar even), waarvan niet eens duidelijk is wat er allemaal in dat aandeel meegeteld wordt.
Het is de grootste desktop Unix. Nee, Linux wordt niet daadwerkelijk gebruikt op de desktop.
Je kunt dit ook omkeren: Linux heeft minder dan 4% van de markt, dus waarom zou je daarop onderzoek doen?
Omdat naar mijn weten >50% van de servers op Linux draaien. Voor de desktop wereld is Linux inderdaad niet zo interessant, maar voor de server en online wereld kan je er niet omheen. Gehackte servers raken toch meer mensen dan gehackte desktops.
Maar hoe groot is de servermarkt?
Volgens www.crn.com totaal ongeveer 1,5 miljoen in 2019, terwijl de PC markt volgens wikipedia.org in 2019 ongeveer 261 miljoen was, waarvan de Mac in 2019 7% was.
Dan is de Mac markt, ook als is het '10%' (of 7%) toch groter dan de server markt.

Deze verkoopgetallen vallen natuurlijk in het niet bij de verkoop en installed base van smartphones en tablets.
Je zou dus hopen dat daar veel onderzoek naar is en er heel goede update mogelijkheden zijn voor deze producten... Helaas draait een groot deel van de smartphones Android...
Behalve dat iedere PC doorgaans maar door 1 persoon gebruikt wordt, terwijl iedere server door duizenden personen gebruikt kan worden. Ik durf zelfs te stellen dat er geen persoon is die op internet komt die geen Linux gebruikt. Dus er zijn ongeveer 7-10% van de personen die een Mac gebruiken, maar er zijn +-100% van de personen die Linux gebruiken. Ook al is dat Linux gebruik misschien niet je eigen PC.

Immers gebruik je iets van Google of Facebook, dan zit Linux ergens in de lijn. Updates voor je Mac of iphone, worden zeer waarschijnlijk geserveerd vanaf een Linux machine. Je Android telefoon is al Linux. Windows machines gebruiken in de basis waarschijnlijk geen Linux, maar als je dus iets op internet doet raak je al heel snel Linux aan. Je router in de meter kast, zeer waarschijnlijk Linux. De switches buitenshuis waar je internet langs gaat, zeer waarschijnlijk Linux.

[Reactie gewijzigd door lappro op 11 februari 2021 13:53]

Behalve dat iedere PC doorgaans maar door 1 persoon gebruikt wordt, terwijl iedere server door duizenden personen gebruikt kan worden.
Dat een server door iemand gebruikt wordt, betekent niet meteen dat die gebruiker ook shell rechten heeft. M.a.w. veel van die gebruikers kunnen helemaal geen shell commando's uitvoeren, sterker nog, er zijn genoeg servers waar alleen maar de admins toegang toe hebben, die hebben doorgaans al root rechten, en dan is een sudo escalation een "don't care" geworden.
Ik durf zelfs te stellen dat er geen persoon is die op internet komt die geen Linux gebruikt
Dat je dat durft te stellen, maakt het natuurlijk nog niet waar. Enige onderbouwing zou hier wel gewenst zijn.

De relevante device groep, zijn machines waar een shell op loopt, waar je sudo op kan runnen, en waar er een of meer gebruikers zijn zonder admin rechten maar wel met shell rechten.
Veel (de meeste) van de Linux devices die je noemt vallen helemaal buiten de boot v.w.b. het topic.
Dit terwijl veel desktop mac's wel onder deze noemer vallen.
Backend systemen is heel weinig Mac, maar onder developers zelf is Mac redelijk populair.

Exploits vinden niet alleen op servers plaats, helaas.

En dan misschien het argument: maar behalve jezelf sudo’t er toch niemand op een laptop? Tsja, op servers hebben doorgaans ook alleen vertrouwde beheerders een login. De sudo kwetsbaarheid is domweg iets dat mooi als onderdeel van een ‘chained attack’ kan worden ingezet.

En dan is de desktop ook kwetsbaar.

[Reactie gewijzigd door Keypunchie op 10 februari 2021 19:28]

Qualys is een firma die zich bezig houd met cloud security en compliance.
Vermits Os X quasi onbestaande is als server platform lijkt het me zeer redelijk dat ze daar geen moeite in steken om daar op te testen.
Dan spin je toch even een macOS instance op in AWS.. kost weinig ($1.083 per hour (billed per second) ) om dit even te testen..
https://aws.amazon.com/ec2/instance-types/

Ok iets meer dus.. ongeveer $25 om te testen.. nog steeds geen wereldbedrag..
https://acloudguru.com/bl...wss-new-ec2-mac-instances

[Reactie gewijzigd door ToolkiT op 10 februari 2021 17:50]

Als je geen mac in huis hebt kan het snel regelen wel eens tegenvallen. Zeker als je geheimhouding wenst zolang er geen oplossing klaar ligt. En niet iedereen gaat zomaar snel even een mac kopen om te testen of het daar ook op lukt. Die dingen zijn niet goedkoop, en voor een eenmalige test is het een beetje onzinnig.
Als ze dat wel zouden doen is hun onderzoek al snel niet grondig meer maar oppervlakkig, aan de andere kant als een team bewijst dat het ongeacht de distributie aanwezig is zou iedereen die diezelfde broncode gebruikt even achter zijn oren moeten krabben of zij ook niet kwetsbaar zijn.
Dat zal wel dan, maar ik zie niet waarom het een het ander uitsluit. Je kunt toch beiden grondig doen? Voor het geval dat? Want anders blijven het enkel aannames.
De onderzoekers zagen een kwetsbaarheid in sudo, testen dat op een aantal beduidend verschillende distributies van Linux en constateerde daar allemaal dezelfde problemen. Dat bewijst eigenlijk dat het niet aan het OS ligt maar echt bij sudo ligt.

Ieder Unix-like systeem dat sudo heeft zou dit gelijk moeten zien als reden tot onderzoek, en blijkbaar had Apple dat ook wel gedaan maar liet de patch gewoon wat langer op zich wachten.
Wat maakt het nou uit of de onderzoekers wel of geen macOS meenemen? Het gaat om een proof of concept, dat sudo op allemaal andere nicheproducten aanwezig is, boeit niet zo. Dat is de verantwoordelijkheid van de ontwikkelaars van die nicheproducten. Wat maakt macOS voor jou zo boeiend dat het onmisbaar is om hierin mee te nemen? Desnoods probeer je het lekker zelf even de volgende keer. Ik snap wel waarom ze het niet op macOS doen, om nou een heel dure laptop of ander apparaat aan te schaffen om een paar regeltjes code te testen is ook weer zo zinloos.

Jij stelt de vraag; waarom niet, maar draai die vraag eens om, waarom wel? Kunnen anderen ook gewoon doen hoor. Je zeurt om niets.
Het aandeel van Linux/Unix is vele, vele malen groter dan dat van macOS, juist op multi-user systemen waar dit security issue het meest urgent is (want laten we wel wezen, uiteindelijk is privilege separation op de desktop toch voornamelijk iets dat de enige gebruiker van het ding een beetje tegen zichzelf in bescherming moet nemen).

En wat betreft de grondigheid van het onderzoek: Weet jij wat de onderzoeksvraag was, en zo nee, hoe wil jij dan beoordelen of het onderzoek grondig is gedaan of niet? Als de onderzoeksvraag (of als er misschien geen concrete vraag was, het aandachtsgebied van de onderzoekers) zich puur richt op het vinden van buffer overflows, of de sudo software an sich, dan kan ik me heel goed indenken dat ze na het vinden van de bug een paar veelgebruikte OS-en getest hebben, en daarmee voor hun voldoende de praktijkwaarde van de bevindingen hebben aangetoond. Het testen van nog meer OS-en is vervolgens gewoon vrij saai werk, niet echt meer 'onderzoek'. Dat kunnen de betreffende release-bouwers en system integrators prima zelf doen (hetgeen Apple dus ondertussen ook gedaan heeft).
Het heeft een groter marktaandeel dan Linux/Unix en als het standaard ook sudo aan boord heeft, waarom niet dan?
MacOS is beduidend veel kleiner dan linux. Het grootste deel van het web + alle android devices draaien linux.
Mja, beetje onzinnige discussies elke keer, Android en webservers vergelijken met macOS.

Ten eerste gebruikt praktisch niemand ooit een shell terminal op zijn Mac, Android-gebruikers al helemaal niet en zelfs als je toegang hebt tot de hosting van een Linux webserver moet je al een duurder pakket nemen wat een shell überhaupt toestaat want ook hier geldt dat niemand dat gebruikt en de hosting provider wil het al helemaal niet.
Je wil niet weten hoeveel mensen front-end ontwikkeling doen op 'n Mac. Net op Mac en Linux is dit 'n verademing tov Windows omdat je 'n goeie command line (bash, zsh, ...) hebt.
Beetje onzinnige antwoorden elke keer. Privilige escalation is gewoon een groot security probleem, onafhankelijk van de wijze waarop. Iemand die kwaad wil doet namelijk:
1. Een terminal open.
2. Privilage escalation.
3. Verder waar die voor kwam.

Edit: en ja, dat kan ook gewoon op android. Zit je dan met ruim een miljard potentiele devices in een botnet...
Edit2: Ik open toch echt een paar keer per dag terminals op zowel windows als mac....

[Reactie gewijzigd door hottestbrain op 10 februari 2021 18:09]

1. Iemand die kwaad wil, kan zomaar bij jouw Android toestel? Dan houdt het al op met je veiligheid.
2. Als je apparaat onderdeel is van een botnet, heb je een groter en heel ander probleem dan alleen sudo.
3. Al heb je nog zoveel Android apparaten online.. Jij bent waarschijnlijk de enige in de straat die überhaupt weet wat de shell is.
Ten eerste gebruikt praktisch niemand ooit een shell terminal op zijn Mac
Hahaha, sure. En uit welke glazenbol komt die kennis van je? Want ik kan je verzekeren dat je een nieuwe nodig hebt, deze kraamt onzin uit.
Kom maar met overtuigende argumenten dan :)

Als je zoekt op 'site:apple.com shell' kom je alleen links naar iOS apps tegen van olieraffinaderij Shell, over grappig gesproken.
Dat zijn dan 2 security updates vlak na elkaar. Op 1 februari kwam beveiligingsupdate 2021-001 uit. Ben benieuwd waarom het 8 dagen langer duurde voor deze aanvullende fix.
Had ook al wat zitten turen naar de diff sinds sudo 1.9.5p2. Maar er zit volgens mij niet veel in, behalve een nieuw fuzzing systeem. Maar ik heb 't ook maar even geskimmed.

[Reactie gewijzigd door Henk Poley op 10 februari 2021 14:02]

Apple zorgt er ook voor dat accu's gratis kunnen worden vervangen indien het opladen tot 1% bij de MacBook Pro's van 2016/2017 niet verder gaat. Het probleem zou namelijk middels deze zelfde update opgelost moeten zijn, zo blijkt uit dit support document.

[Reactie gewijzigd door Step op 10 februari 2021 11:26]

Ik zou toch liever die nieuwe accu hebben... :X
Heeft iemand ondertussen de vuln kunnen reproduceren? Ik heb er nog niets over gevonden.
Hoe je 'm kan reproduceren stond in het vorige artikel, dat ging over de patch in linux. nieuws: Bug in sudo-commando kon rootrechten toekennen aan iedere gebruiker
Helaas staat daar alleen hoe je kan zien dat er iets niet goed is. Er staat niet hoe je er gebruik van kan maken voor bijv. privalige escalation.
Ik hoop echt dat dit de laatste keer is dat ze zo lang wachten om die fix naar ons te pushen. Een bedrijf wat zit te stoeien met security en een Apple slotje in een Keynote blijkt ver van het veiligste os. Schandalig gewoon dat ze er zo weer van af komen. En ik denken dat je een veilig dichtgetimmerd product in handen hebt als je even online een betaling verricht. Ik vermeidt voor die manier pc s met Windows. Je gaat je nog afvragen wat het veiligst is om te liggen internet bankieren. Echt een schande is het gewoon.
De fix was al eerder beschikbaar op Linux.
Pardon? Het heeft dus twee weken geduurd voordat Apple een fix uitrolde die elke Linux distributie had binnen een dag? Het is toch niet acceptabel om een bekende exploit zoals deze twee weken in het systeem te laten zitten.

Mooie om mee te nemen in de volgende beveiligingsevaluatie.
Wat zouden ze bedoelen met de laatste zin van het stukje?
Als ik het zo begrijp, hebben ze een serieuze beveiligingsfout gewoon twee weken op de plank laten liggen. Je had hem dus handmatig kunnen installeren, maar dat is niet acceptabel: Dankzij Windows XP weten we allemaal wel ondertussen hoe fanatiek gebruikers zijn met het handmatig updaten van hun computers...
Dat is geen Linux, maar BSD.
Dan zijn we het over de diefstal eens dus. Bedankt!
Je kraamt onzin uit. Mach, de MacOS kernel is gebaseerd op BSD, welke opensource en gratis te gebruiken is, ook voor bedrijven. Daarnaast is Mach opensource en gratis te downloaden en aan te passen voor iedereen, en leveren ze sourcecode terug naar BSD. Dus hoe je erbij komt dat ze dingen hebben gejat geen idee, ik denk dat je gewoon geen idee hebt waar je het over hebt?
Nou, ondanks dat je begint met een goed punt is Apple niet per definitie minder veilig dan Windows of Linux distro's. Er zitten wat designkeuzes in macOS die inherent veiliger zijn dan in veel andere distro's/OSjes. Ik denk alleen niet dat Apple die designkeuzes heeft gemaakt met security in het achterhoofd, maar om andere relevante redenen.

Dat Apple forse fouten in het verleden heeft gemaakt is natuurlijk een feit. Dat ze niet zo snel zijn met fixes zoals dit, is ook op zich niet nieuw. Jailbreaks die gebruik maken van bekende vulnerabilities in iOS blijven ook relatief lang bestaan.

Ik ben het niet met je eens dat de fouten bij Apple door testautomatisering aan het licht gekomen zou moeten zijn. Het zijn zodanig obscure fouten dat ik mij voorstel dat een paar testautomatiseringsscripts daar echt niet op gericht zullen zijn. Wel zou het tijdens het aanpassen/ontwerp/ontwikkelen/normaal testen zichtbaar geworden moeten zijn. Maar gezien de grote aantallen bugs in major iOS en macOS releases, waarbij bedrijven in de policy opnemen dat ze één of meerdere maanden moeten wachten bij grote releases laat wel zien dat er op testvlak veel mis gaat. Dat is dan wel op het niveau van de teststrategie en ontwikkelstrategie. Testautomatisering is hier niet de oplossing voor. Dat komt pas als de voorgaande factoren in orde zijn.
Ik heb het hier dan ook niet over de designkeuzes in hun systemen. Voor security is het belangrijk dat je snel reageert en lekken zo snel mogelijk patcht. Als je als commercieel bedrijf, zeker één dat toch wel een redelijk premium aanrekent op zijn producten, 2 weken langer nodig hebt dan een stelletje hobbyisten waarvan de meeste het in hun vrije tijd doen, dan doe je iets dik verkeerd.

Natuurlijk zou dit met een goede teststrategie opgevangen moeten worden... Je zou echt wel een test moeten hebben die zegt "if password field left empty, permission is not granted". Als die 1/3 keer faalt dan weet je dat het niet goed gaat ergens. Alsook bij disk encryption zou je toch echt tests moeten hebben die bevestigen dat het encryption password niet in plain text in het geëncrypteerde resultaat voorkomt.
Dit zijn geen edge cases, maar gewoon de basic acceptance criteria.
Kunnen we verwachten dat er ook nog een fix komt voor High Sierra?

Op dit item kan niet meer gereageerd worden.


Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Microsoft Xbox Series X LG CX Google Pixel 5a 5G Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True