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

Wifi-systemen iPhones uit te schakelen door te verbinden met ssid '%p%s%s%s%s%n'

Een Deense reverse engineer heeft een bug gevonden in iOS op iPhones die de wifi-functionaliteit onbruikbaar maakt. Een gebruiker hoeft alleen maar te verbinden met een signaal met ssid '%p%s%s%s%s%n' en de wifi is buiten werking.

Wie verbindt met zo'n netwerk, zal merken dat de wifi uitgeschakeld wordt en niet meer in te schakelen is, ook niet na een reset. "Zelfs rebooten of de ssid aanpassen helpt niet", zegt hij. Een oplossing daarvoor is er gelukkig wel: wie alle netwerkinstellingen volledig reset, krijgt zijn wifi-functionaliteiten terug. Op Android richt de ssid niets aan.

Volgens een analyse van Bleeping Computer gaat het vermoedelijk om een string formatting vulnerability. In C en programmeertalen die daarop lijken, worden %-tekens gevolgd door een letter geïnterpreteerd als een variabele of een commando, schrijft de site. 9to5Mac speculeert verder: "Het wifi-systeem stuurt deze tekst door naar een interne library die aan string formatting doet, die weer arbitrair aan geheugen-writes gaat doen, een buffer overflow veroorzaakt, waarna de iOS watchdog het proces de nek omdraait."

Bleeping Computer wist het euvel te herproduceren op een iPhone die op iOS 14.6 draait en de Deen zelf, Carl Schou, deed het op een iPhone XS met iOS 14.4.2 aan boord. Apple heeft nog niet gereageerd op een verzoek om commentaar van Bleeping Computer.

Klik op de afbeelding voor een gifje

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Mark Hendrikman

Nieuwsposter

20-06-2021 • 13:54

138 Linkedin

Reacties (138)

Wijzig sortering
Ik ben bezig om dit issue te reproduceren op een iPhone 11 pro max die draait op 14.6.

Het gaat er om dat de naam van het SSID dus gelijk is aan het volgende ergens bevat
%p%s%s%s%s%n
Zonder quotes. Met quotes gebeurd er niet zoveel. Ik heb nu mijn telefoon zo ver dat ie dus niet meer geactiveerd kan worden.

Mijn macbook kan echter zonder problemen verbinden met dit SSID.
Ik heb zojuist de andere SSID verwijderd vanuit netwerkvoorkeuren op mijn mac en die gaf ook direct aan dat het daardoor niet meer bruikbaar is voor andere apparaten met iCloud sleutelhanger.

Dit wordt niet geheel direct gesynced want ik denk dat ook dat proces om zeep wordt geholpen. Mijn iPhone heeft wifi gedeactiveerd, maar als ik terug ga naar het instellingen scherm staat het kapotte SSID wel als huidig verbonden netwerk. Ik ga nu een reboot doen en kijken of ik via 4G weer de sync kan doen met iCloud.

En tada dit werkt, Wifi is weer up en running zonder een netwerk reset te hoeven doen.

edit: Het issue zit hem dus in het feit dat de credentials aanwezig zijn en dat het apparaat bij activeren van wifi die hele lijst doorgaat. Zodra hij het netwerk tegenkomt om te scannen ga je nat. als je hem dus met een ander apparaat kunt verwijderen is er niets aan de hand.

edit2: de SSID moet de reeks hierboven alleen bevatten om de bug uiteindelijk te kunnen triggeren. het volgende SSID kostte wat meer moeite maar bricked uiteindelijk ook:
tweakers%p%s%s%s%s%n
Andersom gaat het ook stuk:
%p%s%s%s%s%ntweakers
edit3: Bij verder testen kwam ik erachter dat alleen het hebben van de credentials niet genoeg is. Op iOS zul je altijd eerst nog een keer verbinding moeten maken met het netwerk. iCloud keychain zorgt er alleen voor dat de credentials er al een keer zijn, maar het netwerk moet handmatig 2 keer verbonden worden (maar je hoeft dus geen creds in te vullen dan). De eerste keer gaat het direct fout, maar de tweede keer duurt wat langer en gaat ie stuk.

TL;DR, een netwerk reset is dus niet nodig als je een mac hebt en beide apparaten via iCloud-keychain credentials uit kunnen wisselen.

[Reactie gewijzigd door supersnathan94 op 20 juni 2021 14:50]

Uit interesse, is die macbook waarop je test een Intel- of een M1-model? Kan me zo voorstellen dat die WiFi (settings) stack op m1 meer gelijkenissen met iOS zal vertonen dan op Intel, misschien dat het op een M1-device wel fout gaat. Zou nog een leuk puntje kunnen zijn om te weten, misschien (Ik heb helaas uberhaupt geen Apple-devices om op te testen voorhanden!).
Nee gat om een 2015 15” rMBP. Is dus een intel apparaat.

Ik krijg binnenkort wel een m1 iMac binnen dus als het dan nog kan zal ik het even testen.
Super, sowieso interessant of het nou wél, of niet zo is! Ik ben benieuwd, en veel plezier alvast met je nieuwe iMac :)
Tja hij is helaas niet voor mezelf, maar moet hem wel instellen en dergelijke dus kan dan ff kieken en er mee spelen. Wil ook direct docker support dan eens bekijken. Als dat goed werkt voor het werk namelijk erg interessant.

Ik vraag me idd ook af nu of dit met de M1 apparaten ook een dingetje is. Of dat ht echt alleen op de iPhones gebeurd (iPad staat niks over vermeld ook dus vandaar).
Lijkt mij meer een (iPhone) OS issue, lijkt me niet gerelateerd aan CPU architectuur.
Nee maar uiteraard hergebruikt Apple stukken code. Kans is dus niet 0 dat dezelfde bug ook aanwezig is op een m1 mac of iPad.

Het is ws een code issue, maar de vraag is waar die code verder nog meer gebruikt wordt.
En als je die SSID gebruikt met andere letters/cijfers erbij? Of alleen %s gevolgd door alleen maar letters?
Als ik de specifieke string hierboven pak en er allerlei zit achter plemp gaat het ook fout.

Het is echter wel iets complexer als in het artikel beschreven staat. Bij het verbinden de eerste keer zal de telefoon zeggen dat ie geen verbinding kan maken, maar hij slaat alles wel netjes op. Verbind je dan de tweede keer dan pas wordt de bug actief.
Dankjewel! Misschien handig als @Mark_88 deze informatie aan het artikel toe kan voegen.
Is het niet mogelijk het wifi netwerk via de iphone te 'vergeten'?
Nee, want daarvoor moet je Wifi eerst aan kunnen zetten. Je moet namelijk op eerder verbonden SSID klikken om in een submenu de boel te kunnen vergeten en aangezien de service vrijwel direct crashed gaat dat niet.
Zou ik ook bijna een design fout noemen. Waarom kun je niet bij opgeslagen WiFi netwerken komen als WiFi uit staat? (Overigens heeft Android dezelfde eigenschap)
Dus als je geen Mac hebt om uit uit de iCloud te verwijderen en een sync te doen over mobiele data, of een iPad zonder simkaart, dan is de enige optie een full wipe van het device om dit op te lossen.
je kan alleen de netwerkinstellingen resetten, de rest van je data blijft dan wel behouden. Wel even zorgen dat hij de credentials niet weer terug synct via iCloud ;)
dan is de enige optie een full wipe van het device om dit op te lossen.
Nee je kunt ook alleen de netwerkinstellingen weggooien, dan is er ook niks aan de hand verder.
Goed experiment! Jammer dat Tweakers dit niet heeft gedaan, ze zijn een doorgeefkanaal voor nieuws geworden...
Ja, maar aan de andere kant kan ik me ook voorstellen dat niet ieder redactielid een iPhone en mac heeft die via iCloud gekoppeld zijn en vervolgens ook nog het idee heeft om daar even naar te kijken. Heeft bleeping Computer namelijk ook niet gedaan.

Vandaar dat het wel een handige optie is om te vermelden. scheelt een hoop gedoe met wachtwoorden opnieuw inregelen.
Maar mag je misschien wel verwachten dat er (en het is nu zondag dat snap ik) een iPhone en mac ligt voor dit soort dingen (naast een windows aparaat en een android telefoon).
Plus, zou dit ook op een virtual machine te replicate zijn? Puur uit interesse, niks gedaan met virtualisatie van OSX/IOS
Ja ergens op de zaak ws wel, maar tis wel thuiswerken nu dus ik kan er wel inkomen dat ie er niet continu een bij de hand heeft.

Maar goed. Ook dan moet je maar net op het idee komen om specifiek dit te checken.
Daar is de keuze, snel of iets toe willen voegen.
Daar heb je een punt. Mijn dank voor je bijdrage!
het merendeel van de tijd testen ze dingen helemaal niet. De redactie is een nieuwssite geworden over tech ipv een techsite met nieuws
Goed experiment! Jammer dat Tweakers dit niet heeft gedaan, ze zijn een doorgeefkanaal voor nieuws geworden...
Ze testen daar van alles bij tweakers maar dit testen ze even niet(grapje) 8)7 of gaan dit nog doen omdat het nu zondag is :P .
Maar ik denk niet dat tweakers dit gaat testen omdat deze bug al is door geven aan Apple en dan is het aan Apple om hier mee aan de slag te gaan en dat gaan ze heus wel doen lijk me!
Mijn kritiek hier is misschien wat te fel. Mijn punt was eigenlijk dat ik het prima vind dat nu.nl gewoon doorgeefluik speelt voor tech nieuws, maar van Tweakers verwacht ik wat meer...
Maakt toch niet uit, daar hebben we medetweakers en comments met een moderatiesysteem voor.
Ja, daar heb je gelijk in.
Ik neem aan dat je opmerking dat credentials niet genoeg zijn alleen gaat om netwerken die wel credentials nodig hebben? Als een wifi netwerk deze string in de ssid heeft en een open netwerk is waar je automatisch verbinding mee maakt heb je geen credentials nodig.
Maar "automatisch" verbinding mee maken betekent dat je nog steeds een keer verbinding moet hebben gemaakt. Een iPhone gaat niet automatisch met hotspots verbinden die hij niet kent ook al heeft ie geen creds nodig.

Enige ding wat ik wel tegenkomen is dat een open hotspot verbinding niet per se wordt opgeslagen en doorgezet via iCloud. Bij verwijderen van de SSID op mijn mac wordt er niet aangegeven dat iCloud devices dit dan ook niet meer kunnen.

Lijkt er op dat ik nu dus wel m'n netwerkinstellingen moet resetten :RIP: :'(

Oh, na een reboot doet wifi het echter wel weer gewoon. dus lijkt wel goed gegaan te zijn dan.

edit:
netwerken die wel credentials nodig hebben
Nee met een "credential" bedoel ik de opgeslagen gegevens van het netwerk, of dat dan SSID+passprhase is of alleen SSID, maakt niet uit. Als er iets is wat je dmv syncing kunt verwijderen is het goed.

[Reactie gewijzigd door supersnathan94 op 20 juni 2021 15:30]

Deze bug ging gister al rond op Twitter:
https://twitter.com/envir.../1406209097289109511?s=21

[Reactie gewijzigd door xbeam op 20 juni 2021 17:36]

Ik zie daar alleen de network reset. Verder niet.
After joining my personal WiFi with the SSID “%p%s%s%s%s%n”, my iPhone permanently disabled it’s WiFi functionality. Neither rebooting nor changing SSID fixes it :~)
Inclusief filmpje
Ja de bug dus. Leuk, maar de oplossingen daar zijn direct nogal hard boem doe maar resetten.
Ik heb het toch negens over een oplossing? ik geef alleen aan dat deze bug gister al rond ring en misbruik wordt om de buren te pesten.
Oh. Maar waarom zeg je dat dan tegen mij? Is toch niet relevant voor mijn reactie met oplossing?
Waarschijnlijk verkeerd gereageerd
Je moet er wel verbinding mee maken dus perongeluk erop klikken dus zoveel mensen ga je er niet mee "pesten".
Is het iemand hier die het al gelukt is om iets te schrijven voor deze bug?

[Reactie gewijzigd door Weicool op 21 juni 2021 13:33]

En een open netwerk? Zonder credentials?
Ja die heb ik ook getest. Gaat ook fout, maar kun je wel weer recoveren zonder reset. Tenminste. Bij mij ging dat goed, maar mn mac gaf niet de standaard “dit ding word ook verwijderd voor andere iCloud apparaten” dus ik weet nu niet helemaal of het door die sync goed gaat of door iets anders.
Iedere C programmeur weet zou moeten weten, dat je strings (zoals de ssid) die aangeleverd worden van buiten je programma nooit blind door een van de string-formatting functies moet sturen en al helemaal niet door een functie die niet beveligd is tegen buffer-overrun...

Da's dus 3 fouten tegelijk:
A ) Blind vertrouwen dat 3rd party data geen rare content bevat.
B ) Gebruik van een niet-overrun-safe functie om de string te kopieëren.
C ) En code review die dat ook nog eens compleet heeft gemist.

Goed bezig jongens.

[Reactie gewijzigd door TonnyTonny op 20 juni 2021 14:58]

Iedere C programmeur zou moeten weten
FTFY :Y) Never trust user input. User input moet altijd sanitized of escaped worden.

[Reactie gewijzigd door P1nGu1n op 20 juni 2021 15:20]

jouw kind heet ook Bobby Tables? :+

[Reactie gewijzigd door flippy op 20 juni 2021 21:36]

het lijken net mensen daar bij Apple! ;-)
het lijken net mensen daar bij Apple! ;-)
Dit soort dingen mag niet meer afhangen van individuele mensen. Men moet processen hebben die dit structureel borgen. Wellicht frustrerend voor de individuele ontwikkelaar, maar overduidelijk noodzakelijk.
en je denkt dat dit niet gebeurd? Zelfs met automatische processen kunnen er fouten gemaakt worden.
Gezien het artikel is er meer reden om aan te nemen dat het niet gebeurd dan jouw aanname dat dit wel zo is. Met een CI/CD straat die hier op let, compileert dit gewoon niet op het moment wanneer je deze fout laat voorkomen. Óók wanneer de bug al sinds het begin erin zit, dat moet direct na ingebruikname van je statische analysetools gewoon rode vlaggen opperen.
Sja. Zolang de code niet openbaar is is het gissen. Meteen de conclusie trekken wat de bug is en ook stellen dat het nooit had mogen gebeuren is mijn inziens een erg naieve stelling.
@TonnyTonny stelt geen rare conclusie, hij zegt ook niet exact wat de bug is maar post wel de drie regels die bij C++ ontwikkeling niet heel raar zijn én deze bug 100% had opgelost. Je ziet bij C, ObjC en C++ in grote bedrijven vaker een wildgroei aan voorkeuren en normeringen die dwars op elkaar staan. Dan komen dit soort dingen wel vaker voor ja.

Voorbeeld, je kan er voor kiezen om een helper te introduceren waarmee de string copy veilig wordt afgehandeld. 2 generaties verder kiezen mensen voor een eigen methode omdat het makkelijker is met compileren (importeren enzo gedoe allemaal), kwestie van knippen en plakken. 2 generaties erna worden beide methodes flink door elkaargebruikt en kiest de generatie daarop een veel eenvoudiger combinatie van de twee: gewoon de standaard strcopy, want dat is veel makkelijker, en niemand snapt waarom dat vroeger zo moeilijk moest.
Dat kan wel wezen maar hij gaat er al wel vanuit dat het om de string formatting gaat. Who knows? Misschien gaat iets anders over de zeik, we zullen het niet weten aangezien we de code niet hebben. Al het verdere is zeker goede habbits mbt programmeren in C , maar dat gaat alsnog geen 100% garantie geven imo.

Dus nee: de bug is niet zeker. Dus nee je kunt niet stellen dat de 3 regels de bug hadden opgelost.

En als we het omdraaien: laten we zeggen dat Apple toch enigszins capabele C programmeurs in dienst heeft… en die zullen vast ook de nodige standaarden/werkwijzen hebben../ blijkbaar heeft dat eea niet voorkomen.

Maar goed. Mijn stelling is: mensen maken fouten. En niets is 100% te voorkomen. En achteraf zonder alle kennis is makkelijk praten natuurlijk ;-).
...maar de bug is juist wél zeker, een tweaker heeft 'm hier gereproduceerd: supersnathan94 in 'nieuws: Wifi-systemen iPhones uit te schakelen door te ver...

Het ligt ook wel voor de hand, want % is de escape karakter (zie het als een placeholder) waar je string formatting mee doet. Op die plekken probeert de code de string uit te breiden met bijvoorbeeld een variabele uit de rest van de Wi-Fi code. Bijvoorbeeld (pseudocode):

format("Forget %n”, ssidFullname);

Hier zou dan bijvoorbeeld "Forget Harry's netwerk" uit komen. Het probleem met een ongecontroleerde implementatie hiervan is wanneer je die karakters zelf gaat invoeren als gebruiker. Klaarblijkelijk wordt die input zelf opgeslagen en opnieuw gevoerd aan de klasse (wat mij doet vermoeden dat het een stuk code voor presentatie betreft), dat zou verklaren waarom het ook gelijk niet meer goedkomt totdat er een reset gedaan wordt (wat een dump van die gegevens tot gevolg heeft).
Ik bedoel niet dat het niet duidelijk is hoe het te reproduceren, maar *waardoor* het komt dat het mis gaat.

Weet jij welke library gebruikt wordt om de strings te formatten? Er zijn meerdere.

Ken jij de rest van de implementaties op iOS low level / networking ? Ik niet.

M.a.w, dit zijn allemaal aannames.

Ik kan een beetje C(++) programmeren dus de printf is me bekend, maar het vaststellen dat een string met een % erin betekent dat "dus" printf gebruikt wordt is te kort door de bocht.
Lol, dan moet je wel een test schrijven die hier op let.
Je kan niet alles aftesten/checken wat er kan fout gaan want dan schrijf je minstens 3 maal zo veel code dan uw oorspronkelijke code en die moet je ook onderhouden.
Je mag nog alles zo goed proberen testen of dicht timmeren maar bugs blijven er altijd wel ergens inzitten, zelfs in de code van de testen.
Nou een CI/CD straat laat het netjes compileren hoor. Er zouden daarna wel allerlei toeters en bellen af moeten gaan mbt static code analysis bijvoorbeeld. Iets als Sonar of resharper gaat hier keihard op dan. Dit is echter geen compilatiefout.

Zoals je zegt. De static code analysis moet dan een vlag gaan heisen.
Inmiddels hebben ze hier vast een unit-test voor :+
Zeker, die heet "consument".
Ik mag toch hopen dat ze statische code-checkers hiervoor inzetten, die kunnen dit soort zaken veel structureler.
Dit soort dingen mag niet meer afhangen van individuele mensen. Men moet processen hebben die dit structureel borgen. Wellicht frustrerend voor de individuele ontwikkelaar, maar overduidelijk noodzakelijk.
Inderdaad ! Er moeten processen zijn die structureel borgen dat programmeurs geen fouten maken, en niet per ongeluk bugs in de code stoppen.

En dat is dan niet alleen frustrerend voor de programmeur, maar ook frustrerend voor de manager, die de ontwikkelingskosten van software ziet exploderen, nog afgezien van de salariskosten voor de weinige beschikbare programmeurs die voldoende kennis en ervaring hebben om überhaupt een kans te hebben om dat soort bugvrije software te kunnen schrijven. En frustrerend voor de aandeelhouders die een stagnerend bedrijf zien dat nooit met iets nieuws op de markt komt, en áls ze al met iets komen, is dat achterhaald omdat ze links en rechts reeds door concurrenten zijn ingehaald.

O ja, en alle software die ze inkopen moet natuurlijk ook aan dezelfde eisen voldoen...

Maar dat is allemaal noodzakelijk, in de naam van bugvrije software!
/s
Love the sarcasme ;-)

Bugvrij bestaat niet. (Of we moeten een andere definitie van een bug hanteren..)

Ieder die dat verwacht snapt niet hoe enorm complex de materie snel wordt en/of de enorme moeite die gepaard gaat om “100% bugvrij” software te maken.
Inderdaad ! Er moeten processen zijn die structureel borgen dat programmeurs geen fouten maken, en niet per ongeluk bugs in de code stoppen.
Hoewel je post sarcastisch is ingestoken is dit natuurlijk wel waar goed development om draait. Processen om zoveel mogelijk bugvrije features op te leveren.
Dit is eigenlijk een probleem van veel computer systemen en programma’s. De data wordt niet gevalideerd, maar soms zonder enkele controle als juist beoordeeld.
Of het nu een plaatje of WiFi Ssid is.
Dit is geen fout in data-validatie want de string is gewoon prima, de data wordt überhaupt verkeerd geïnterpreteerd. %s wordt hier als format-string behandeld terwijl het gewoon ongeformatteerd gebruikt had moeten worden.

Nou is dat óók een veelvoorkomend probleem.
Maar dit is in principe gewoon een geldige ssid. Als validatie dit tegen zou houden, zou ik minder blij worden want dan heb ik ineens een apparaat dat niet met mijn wifi verbinden wil en word ik dus gedwongen een andere ssid te gebruiken.
Theoretisch gevalletje, hoor, dat je deze (of een vergelijkbare naam) wilt hanteren.

Je hebt je kind ook '); DROP TABLE students;-- als middelste naam gegeven?
Daar is weinig theoretisch aan. Je string formatten terwijl het zonder formatting bedoeld is, of je string als SQL interpreteren terwijl het als string literal in SQL bedoeld is, betekent dat je je data fundamenteel verkeerd aan het behandelen bent.

Een groot deel van functionele bugs en securitiy-bugs bestaat uit data verkeerd interpreteren. In abstracte zin zou je dat typeringsfouten kunnen noemen. Voeg daar nog een C-achtig memory-model aan toe om meteen ook buffer-overflows te krijgen en het hele ding crasht.

[Reactie gewijzigd door bwerg op 20 juni 2021 15:16]

Volgens mij begrijpen sommigen dingen verkeerd.

Het is theoretisch dat je deze string als
daadwerkelijke SSID wilt gebruiken.

Als hij dus weggefilterd wordt door een validatie/sanitatie is dat juist *niet* erg.
Als hij dus weggefilterd wordt door een validatie/sanitatie is dat juist *niet* erg.
Sanitatie: ja, tuurlijk, dat zorgt er effectief voor dat je formatting gewoon niet gebeurt. Dat is gewoon een legitieme fix. Is een stuk omslachtiger dan gewoon géén formatting aanroepen als je dat überhaupt niet wil, maar het zit in een library, dus wat het handigste is is gissen.

Maar validatie niet erg? Alleen controleren op deze specifieke string is natuurlijk niet goed genoeg want je kan oneindig veel varianten bedenken, een complete analyze van welke variaties wel en niet tot crashes leiden is een ronduit absurde manier van om het daadwerkelijke probleem heenwerken. Los van dat dat veranderlijk is. Wil je waterdichte validatie (en waterdicht is voor het voorkomen van buffer-overflows wel zo handig), dan, zal je dus het complete arsenaal aan speciale string-formatting-combinaties moeten verbieden (%s, %d, %i, ga zo maar door) om veilig te zijn. En met naar schatting zo'n miljard iphone-gebruikers is de kans dat hier gebruikers tegenaan gaan lopen zo'n 100%.

[Reactie gewijzigd door bwerg op 20 juni 2021 16:46]

betekent dat je je data fundamenteel verkeerd aan het behandelen bent.
Klopt natuurlijk, maar het equivalent van bijvoorbeeld:
execute_sql("select password from users where name='"+naam+"';")
(waar in dit geval 'naam' uit een externe - mogelijk niet-te-vertrouwen bron komt)
is vaak véél makkelijker op te schrijven, en vaak ook nog eens leesbaarder, dan het op de juiste manier te doen. De programmertaal stimuleert je dus vaak om het 'fout' te doen... Je moet mensen dus echt opleiden om dit soort fouten niet te maken. En zo zijn er veel meer soorten fouten die je niet moet maken, en dat moet je ook allemaal leren. Niet eenvoudig, zeker als de vraag naar programmeurs groot is, en managers vaak niet geselecteerd worden op hun verstand van programmeren en softwareontwikkeling, en programmeurs, softwareontwikkeling en -testen ook vooral als kostenpost gezien worden.
Ja Bobby tables noemen we hem.

Maar dan nog kun je wel allerlei uitzonderingen in gaan zetten, maar dat neemt niet weg dat je gewoon input sanitization moet doen.
In C- en C-stijl-programmeertalen worden %-tekens gevolgd door een letter geïnterpreteerd als een variabele of een commando
Nogal een verschrikkelijk verkeerde uitleg. Heeft het niks met C of C-stijl-programeertalen talen te maken. Zie: https://en.wikipedia.org/wiki/Printf_format_string
Er wordt hier blijkbaar user input gebruikt als de template voor tekst formattering. Het is verschrikkelijke domme security bug die zo'n beetje elke statische codeanalysetool er uithaalt.
Maar waarschijnlijk zit de bug dieper in de code, op een plek waar de analyzer niet meer herkent dat het van oorsprong een door menselijke input aangeleverde waarde is.
die zo'n beetje elke statische codeanalysetool er uithaalt.
Complete onzin. Statische codeanalysetools gaan echt niet automatisch kunnen bepalen dat een SSID ooit door een user is ingevuld. Het is geen magie.
Resetten van de netwerk instellingen lost het op voor nu. Zou wat zijn als het al problemen gaf bij de aanwezigheid. Wel vaag dat dit soort strings niet gecheckt worden.

[Reactie gewijzigd door berchtold op 20 juni 2021 14:13]

Volgens mij het niet puur input validatie, een SSID is gewoon van type string en dat zit wel goed (anders zou alleen het scannen al problemen geven, maar het gebeurt pas bij verbinden).

Ergens anders in de verwerking crasht er vervolgens iets wat je hele wifi-stack in de war brengt, mogelijk is het iets van je voorkeurenlijst/manager die dusdanig van de kook is. Pas daar wordt er namelijk daadwerkelijk wat met een string gedaan (opslaan in een volgorde). Voor het netwerkgedeelte-zelf is de string niet relevant, behalve als volledige match.
Wie verbindt met zo'n netwerk, zal merken dat de wifi uitgeschakeld wordt en niet meer in te schakelen is, ook niet na een reset. "Zelfs rebooten of de ssid aanpassen helpt niet", zegt hij. Een oplossing daarvoor is er gelukkig wel: wie alle netwerkinstellingen volledig reset, krijgt zijn wifi-functionaliteiten terug.
Dit gedeelte snap ik niet helemaal: wat voor reset wordt er bedoelt in het begin en wat is een volledige wifi reset? is dit het opnieuw opstarten van de telefoon of een factory reset?
Ik denk dat ze de Network Reset bedoelen in Settings > Reset.
Zal dit dan ook niet door middel van NFC te misbruiken zijn? Volgens mij kan je namelijk met een NFC chip scannen en verbinding met een netwerk maken zonder dat je wachtwoorden enzo in hoeft te vullen.
Dat ligt er denk ik heel erg aan of je OS om confirmation vraagt om te verbinden of niet. Ik denk dat er sowieso word gevraagd of je wilt verbinden en waarschijnlijk drukken de meeste mensen de melding weg als je zo'n rare tekst in beeld krijgt. Tenzij de confirmatie ook al die crash veroorzaakt natuurlijk
Met wifi verbinden via NFC tag?
Kan niet in iOS.
"Kan wel" is wel een beetje vergezocht in dit geval, want die NFC doet niets anders dan een website openen waar de code op staat, die je daarna nog zelf moet kopiëren en invullen in de instellingen.

De QR-code-oplossing is een stuk makkelijker en die kan iedereen hier genereren.
Vergezocht is een understatement, hoe ga je een website laden als je geen bereik hebt?
Sommige mensen hebben tegenwoordig zoiets als ..... ik denk dat het 'mobiele data' heet
Dat vage ding genaamd “mobiele data” werkt niet als je, hoe heet het ook alweer, geen bereik hebt. Waar degene waar je op reageert het over heeft.
Zat er ook aan te denken om gewoon die qr code op te hangen. Ik weet alleen niet of iedereen zo’n grap zal waarderen.
Even een verduidelijking: Dit laat op iOS dus een website in, die je de gegevens verteld. Deze verbindt dus niet automatisch met het netwerk.

Dit veroorzaakt de verwarring tussen cmegens & sHELL.
Kan niet, IOS ondersteund het niet. Misschien heeft iemand het op een jailbreak versie voorelkaar gekregen, of een aparte app. Maar onder de appel norm werkt het niet.

(blijkbaar kan het via een URL, maar deze constructie is wel erg :r )

[Reactie gewijzigd door sHELL op 20 juni 2021 14:56]

Maar wel via een QR-code!
Dan krijg je nog altijd een bevestiging prompt en ziet de gebruiker een rare ssid.. meeste mensen zullen dan niet op Ja drukken hoop ik? 8)7 8)7
Behalve op Tweakers is er vrijwel niemand die begrijpt wat een SSID is terwijl er vast mensen zullen zijn die denken hè zo’n plaatje wat ik kan scannen, laat ik dat maar eens ff proberen. Verder ben ik het met je eens dat Apple zeker dingen inbouwt zodat zoiets minder snel impact zal hebben dan met systeem wat automatisch een code omzet in een actie.

[Reactie gewijzigd door jopiek op 20 juni 2021 14:48]

Maar dan zou in principe elke SSID met een % gevolgd door bijvoorbeeld p, s, n etc. volstaan om op iPhones wifi uit te laten schakelen. Wel handig als je op je wifi netwerk iPhones wilt weren ;-)
Dit doet me denken aan de fantastische crossover van de podcasts Reply All en 99% Invisible (en nog enkele anderen), genaamd The Roman Mars Mazda Virus. De aanleiding daarvan was het entertainmentsysteem van iemands Mazda spontaan crashte wanneer er een aflevering van de podcast 99% Invisible werd afgespeeld. Prachtig podcastwerk.
Ik vind het knap dat mensen kunnen uitvogelen dat je deze combinatie nodig heb.

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