Onderzoeker stelt dat Samsungs besturingssysteem Tizen veertig zero-days bevat

Een Israëlische beveiligingsonderzoeker heeft ontdekt dat in Samsungs besturingssysteem Tizen, waar onder andere smartwatches en smart-tv's van de Koreaanse elektronicagigant op draaien, veertig kwetsbaarheden bevat.

Volgens onderzoeker Amihai Neiderman kunnen kwaadwillenden hiermee eenvoudig op afstand apparaten hacken die op Tizen draaien, zonder dat er daarbij fysieke toegang tot de apparaten nodig is. Volgens hem heeft niemand met verstand van beveiliging naar de code gekeken of geholpen eraan mee te schrijven. In een gesprek met Motherboard noemt Neiderman Tizen "misschien wel de slechtste code die ik ooit heb gezien".

De grootste kwetsbaarheid is volgens Neiderman Samsungs TizenStore-app, waarmee apps en updates worden geladen naar toestellen die draaien op het besturingssysteem. Volgens de onderzoeker zit er een fout in het ontwerp waardoor hij elke willekeurige code kon doorvoeren op zijn eigen Samsung-tv. TizenStore maakt weliswaar gebruik van authenticatie zodat alleen software van Samsung kan worden geïnstalleerd, maar Neiderman bleek via een heap-overflow in staat om deze authenticatie te omzeilen.

Een voorbeeld van een andere kwetsbaarheid is de 'strcpy()-functie', waarmee data naar het geheugen kan worden geschreven. Daarbij wordt er echter niet gecontroleerd of er wel genoeg opslagruimte beschikbaar is om de data te kunnen schrijven. Dit kan een bufferoverloop veroorzaken wat aanvallers eenvoudig zouden kunnen misbruiken. Volgens Neiderman maakt vandaag de dag geen enkele programmeur nog gebruik van deze functie, terwijl de programmeurs van Samsung het "overal gebruiken". Ook zou er bij sommige dataverbindingen geen SSL-encryptie worden gebruikt.

Neiderman stelt dat een groot deel van de code van Tizen verouderd is en grotendeels is gebaseerd op voorgaande projecten van Samsung, zoals Bada, een besturingssysteem voor mobiele telefoons waarvan Samsung de ontwikkeling in 2013 heeft gestaakt. De meeste kwetsbaarheden vond Neiderman echter in nieuwe code die specifiek voor Tizen is geschreven.

Neiderman heeft Samsung maanden geleden al gewezen op de kwetsbaarheden, maar kreeg per email enkel een autoreply van Samsung. Samsung zegt nu samen met Neiderman te werken aan het dichten van de lekken. Neiderman heeft bevestigd inmiddels contact te hebben met Samsung.

Reacties (124)

[Verwijderd]

De C programmeertaal is het grote probleem. Omdat arrays geen bounds checking hebben krijg je dit soort fouten. Daarnaast maken de ontwikkelaars ook geen gebruik van moderne technieken zoals STL en garbage collection.

De mensheid had allang moeten overstappen op talen zoals C# en Java. Of op z'n minst had men de fouten in C moeten oplossen, door bijvoorbeeld Pascal arrays te gebruiken.

Bada zelf zat prima in elkaar, maar Tizen is weer gebaseerd op code van LiMo en Meego. In Bada zat vrijwel alleen strncpy() als ik mij goed herinner.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:25]

[BoringDay]

De programmeertaal C is helemaal niet het probleem en ook niet een fout van C, het probleem ligt bij de programmeur zelf als deze de taal en de achterliggende gedachte ervan niet snapt.

[Reactie gewijzigd door BoringDay op 23 juli 2024 11:25]

[84hannes]

Offotpic-discussie maar:
Als je wegen en automobilisten perfect maakt dan heb je bijna geen gordels en airbags meer nodig. Maar niet iedere automobilist is perfect, en niet elke weg is perfect, dus zijn we blij met veiligheidsfeatures. Die features biedt C, in verhouding tot moderne programmeertalen als Rust, niet of nauwelijks. Maar wat blijkt nou? Niet iedere (C) programmeur is perfect.

edit:

Een heleboel boze mensen hieronder.

Als jullie nog nooit een pointer tweemaal hebben geprobeerd te dealloceren, als jullie nog nooit een pointer naar een locale variabele hebben teruggegeven vanuit een functie, als jullie nog nooit een array of een string buiten zijn geheugen hebben laten lopen dan zeg ik: chapeau, jullie zijn geniaal! Maar ik heb die fouten gemaakt en ik ben blij met de unique-pointers van C++11, de lifietime specifiers van Rust en zelfs af en toe met de garbage collection van Java. En ik trek geen moment in twijfel dat er dingen zijn die niet efficiënt kunnen met Java, maar juist àls je een goede (maar geen perfecte) programmeur met kennis van zaken bent kun je met C++/Rust de performance van C halen met veel minder kans op fouten.

[Reactie gewijzigd door 84hannes op 23 juli 2024 11:25]

[BoringDay]

Er valt niks te verwijten aan C, C programmeertaal is heel goed uitgedacht. Dat een Java/C# programmeur niet in C kan programmeren ligt aan hun gebrek aan kennis en niet aan de taal C. Bij C heb je simpelweg meer programmeer kennis nodig. Bovendien zijn die moderne talen praktisch allemaal afgeleid van C.

[Reactie gewijzigd door BoringDay op 23 juli 2024 11:25]

[Verwijderd]

Ik programmeer nu zo'n 28 jaar in C. Ben auteur van diverse open-source projecten.

Ik dacht vroeger ook dat het mogelijk was correct in C te programmeren.

Ik ben er inmiddels van *overtuigd* dat niemand zonder fouten in C kan programmeren, zeker ikzelf niet. Het is onverantwoordelijk om in de huidige tijd nog in een taal als C te programmeren, pointer errors, use-after-free, casting errors, buffer overflows, noem ze maar op - het houdt niet op, niet vanzelf.

Gebruik een taal met garbage collection (C#, Go, etc), of gebruik Rust. Stop met C.

Mike.

[Verwijderd]

Ik volg je tot aan het moment dat je oproept om een taal met garbage collector te gebruiken. Die dingen zijn zelf een bron van heel wat fouten. Te vaak leiden ze tot eindeloos debugging werk. Maar soms zitten ze ook echt fout.

Misschien is D een taal waar jij je in kan vinden? Na je 28 jaar ervaring ben ik er zeker van dat ik jou niet moet uitleggen wat D is. Dat zal je zelf wel uitzoeken.

De programmeertalen C en C++ zijn te moeilijk juist te gebruiken zonder iets dat tussen de programmeur en de compiler staat. De laatste tijd gebruik ik daar, vrij strict, Qt voor. Vroeger gebruikte ik GLib (dus, onder C toen).

Voor de overige 90% van de toepassingen: sure, C#, Go, Rust, Java en zelfs de hype of de fad die vandaag in is. Allemaal goed.

[daan.timmer]

Sorry, ben het niet met je eens.

Als je wel eens met processors (microcontrollers) hebt gewerkt met weinig RAM, weinig FLASH en weinig power (maar een paar MIPS-en, (niet te verwarren met de MIPS architectuur) dan wil je niets anders dan barebone C.

C++ heeft óók zo zijn voordelen op microcontrollers, zolang je je er maar bewust van bent dat je gelimiteerd bent in alle resources. Dus óók geen heap. Dus óók geen memory management en weinig pointers. Meestte objecten statisch gealloceerd at startup.

Je wilt absoluut geen taal gebruiken zoals Java, Python, Go of whatelse je maar kan verzinnen met een garbage collector, heap and whatnot.

Nee, dan liever nog Assembly. Ja, je moet weten wat je doet, maar een Doctor die aan een mens opereert moet ook weten wat hij doet. En ondanks dat het mensenlijk lichaam een hoop complexer is dan een microcontrollertje geschreven in C hoor ik niemand roepen dat we die zeer moeilijke operaties dan maar moeten afschaffen. (ja, rare analogie, ik weet het).

Enfin, ja C is outdated op desktop systemen, maar ook zelfs daar heeft het nog zijn toegevoegde waarde. Zolang het maar bij low level stuff blijft of bij zeer performance kritische zaken.

[Verwijderd]

Microcontrollers worden steeds krachtiger. Je kan tegenwoordig een ARM processor kopen voor hetzelfde geld als een 8-bit AVR en zo'n ding heeft scheepsvrachten DRAM en Flash. Dan hoef je niet meer te bezuinigen op elk bitje en kan je gewoon veilig C++ met STL en GC gebruiken zonder enige performance penalty.

[daan.timmer]

Ja, dat klopt. Maar als je een massa productie doet dan telt elke cent.

En laten die "ietwat krachtigere" CPU's nou ook "ietwat duurder" zijn dan de goedkopere variant wordt er voor massa productie toch liever gekozen voor de wat simpelere, kleinere micro's.

Ik ben nu zeer fijn bezig met een STM32F411RE van ST en een LPC1769 van NXP en allebij worden vrolijk in C++11 (zonder HEAP en GC) geprogrammeerd.

[sspiff]

Ik vind C een prachtige taal, en ik ben nog steeds verbaasd hoe ze met zo'n beperkt aantal primitieve concepten zo'n krachtige taal gemaakt hebben, die al decennia lang dienst doet voor de grootste en meest wijd verspreide software te bouwen.

Maar dat neemt niet weg dat het wel erg moeilijk is om in die grotere projecten geen fouten te laten sluipen die door kwaadwilligen kunnen misbruikt worden.

Je kan natuurlijk ook logica-fouten hebben in veel andere, jongere talen, en de runtimes van veel van die talen zijn bovendien ook nog eens vatbaar voor geheugenfouten, maar er zijn volledige klasses aan fouten waar enkel talen als C en C++ toe in staat zijn.

Deels komt dit natuurlijk door het feit dat vroeger, toen C ontwikkeld werd, dit soort fouten nog niet bekend waren of nog niet zo'n groot probleem vormden, maar nu onze software vaak groter is dan 1 menselijk brein kan omvatten, en we al onze programma's en apparaten verbinden met het Internet en overal mee naar toe nemen, is het misschien wel tijd om iets anders te zoeken.

C heeft zeker nog zijn plaats in de wereld, maar we moeten de tekortkomingen ervan ook niet proberen verdoezelen door het op de "gebrekkige" ontwikkelaar te steken. Elke ontwikkelaar is beperkt in zijn talent, en goeie tools zorgen er voor dat die beperkingen zo goed mogelijk ingedijkt worden.

[Verwijderd]

Verbaas je niet. De reden waarom C met zo'n beperkt aantal primitieve concepten zo'n krachtige taal werd is omdat het zo beperkt is en omgekeerd.

De taal leunt dicht aan bij wat de principes van een computer zijn. En verder niets. Daarna laat het alles over aan de programmeur. Dat maakt het zowel beperkt als krachtig.

M.a.w. met C maak je een F1 wagen. Maar een F1 wagen is niet noodzakelijk waar je je kinderen mee wil vervoeren. Soms wel.

[Zezura]

C krijgt misschien wel weer een grotere belangstelling in de toekomst. Wacht maar af.

[tweaknico]

Wat de taal ook kan het ontslaat de gebruiker niet van input validatie etc.
En daar schort het in het grootste aantal gevallen aan.
ie: als er een 20 byte data element verwacht wordt gebruik dan maximaal 20 bytes en niet meer, ongeacht verdere inhoudelijk specificaties, door overal dit soort zaken WEL te controleren kan zelfs al er een fout in de onderliggende lagen zit er weinig mee bereikt worden.
Helaas die controles ontbreken meestal.

Verder is C een taal die feitelijk alleen CPU control doet op een vrij transparante en overdraagbare manier zonder/met weinig aannames in de omgeving.
De C-runtime library is eigenlijk de interface naar een OS oid.

[BoringDay]

2017 en nog steeds fanboy roepen?
Het feit blijft dat er nog steeds veel C toegepast wordt en wellicht ook met hele goede redenen.

[Verwijderd]

Dit is gewoon onzin, er is 0 correlatie tussen een auto en een programmeertalen.

De claim dat moderne talen per definitie veiliger zijn is niet waar, je geeft een hoop uit handen aan bedrijven als Microsoft en package makers waardoor je meer kunt laten doen door lager opgeleiden en minder ervaren programmeurs dat is het hele punt. Je bent zwaar afhankelijk van een framework. Een gat in dat framework en alle programma's die erop leunen zijn in een klap kapot.

Het is nog steeds mogelijk om zelf buffers aan te maken of om unmanaged code te draaien in alle hogere talen. Een van de grootste problemen met C# is dan ook dat een programmeur het niet voor elkaar krijgt om bepaalde code te debuggen vanwege de permissions en dan maar uit gemak alle permissions erin zet. Zeg maar dag tegen de security features in je framework. Als we jou analogie doorzetten dan zouden we ook een programmeer politie moeten hebben die mensen gaan bekeuren als ze fout code gebruiken (gelukkig hebben meeste bedrijven dat ook in de vorm van externe quality assurance).

De keuze welke taal je gebruikt is sterk afhankelijk van de toepassing. Zo zijn bij realtime toepassingen een hogere taal als C++ al een no-go. De reden daarachter is heel makkelijk, C++ is OO, dat houdt in dat het alles in klassen laadt in het geheugen. De eerste keer dat je een class aanroept moet hij nog worden geladen en dus duurt het wat langer, daarna zal het sneller gaan. Die onvoorspelbaarheid maakt het een onbruikbaar voor zware real-time toepassingen.

Of probeer maar eens een driver of nog erger een hele kernel in hogere taal te programmeren. Nou, succes ermee.

[Verwijderd]

Eh, niet helemaal waar. C++ kan perfect gebruikt worden voor bv. realtime toepassingen. En een C++ class laden wil niet per definitie zeggen dat je malloc (new) moet doen. Je kan C++ classen ook op de stack initializeren.

C gebruiken wil natuurlijk niet zeggen dat geen enkele onderliggende library malloc of realloc zal gebruiken. En uiteraard kan je malloc (en new) gebruiken voor de software in SCHED_RT of SCHED_FIFO gezet wordt.

Voor realtime toepassingen zijn C en C++ beiden bruikbaar. Maar bv. D ook (als je het juist gebruikt). Zolang je de garbage collector maar in bedwang houdt kan je bepaalde virtual machines ook gebruiken. Uiteraard is dat niet zo eenvoudig als het stukje RT code gewoon in C of C++ neer te schrijven.

[Verwijderd]

Jij denkt al veel de groot, C++ is idd goed te gebruiken met moderne embedded processoren. Het probleem wat ik aankaart ligt niet in het gebruikt van de taal maar in het modelleren ervan. C wordt vaak nog gebruikt puur en alleen omdat het voorspelbaar is. Sommige toepassingen vallen ze nog wel eens uit naar assembly puur en alleen omdat je dan exact weet hoeveel tijd een functie nodig heeft.

[Verwijderd]

Je kan natuurlijk altijd gcc met -S gebruiken om het resulterende stukje assembler te weten te komen.

Maar zowel de meeste C++ als de meeste C compilers ondersteunen inline assembler met functies zoals asm().

Zowel een C++ als een C programmeur, die weten wat ze doen, kunnen voorspellen wat hun compiler zal uitbraken. En anders is er -S.

[Verwijderd]

Perfect dat je bekend bent met alle switches en functies (overigens de asm() functie is precies waar ik op doelde), lees eens eerst wat er staat en reageer er dan pas op. Ik heb het over modelleren en jij hebt het over een switch om GCC te laten stoppen op een bepaalde fase. kijkt me twee dingen die niet echt met elkaar te maken hebben.

[Verwijderd]

Maar dus net zoals met C valt C++ voorspelbaar te modelleren. En net zoals bij C is één en ander min of meer voorspelbaar bij C++. En net zoals bij C is er bij C++ desnoods de -S switch (van oa. gcc) om het terug voorspelbaar te maken. Net zoals bij C ondersteunt menig C++ compiler dan ook asm().

Als taal is C++ evenredig aan C. Maar ik geef wel toe dat veel C++ programmeurs als gekken aan de slag gingen en de "omgeving" zo gemaakt hebben dat, inderdaad, de C "omgeving" voorspelbaarder bleef. Met "omgeving" bedoel ik dan vooral de bibliotheken die courant gebruikt worden.

Maar net zoals C blijft C++ voorspelbaar voor en door een mens.

[Verwijderd]

Dat maakt het niet voorspelbaar, dat maakt het alleen controleerbaar. Dat je het resultaat van de compiler terug kan zien wil niet zeggen dat het overeenkomt met je model en je wensen.

[Verwijderd]

Ik blijf bij mijn standpunt dat C++ voorspelbaar (en ook controleerbaar) is. Net zoals C, trouwens (ik heb meerdere jaren ervaring met beide programmeertalen - en ben ook maintainer van opensource projecten geschreven in die twee talen).

[Accretion]

Leuke stropredenering, kan ik ook.

Laatst was er een proef met politieautos die automatisch remmen. Wat blijkt nu, hierdoor konden polities niet meer fatsoenlijk hun werk doen.

Wat blijkt nu, soms moet men risico kunnen nemen om iets beter uit te kunnen voeren.

[Verwijderd]

Dat is een denkfout. Mijn visie is dat een computertaal het moeilijk (zo niet onmogelijk) om dit soort fouten te maken. Mensen maken nu eenmaal fouten, zo simpel is het. En maar roepen dat jij het wel goed kan is klinkklare onzin.

[Armin]

Dat is een denkfout. Mijn visie is dat een computertaal het moeilijk (zo niet onmogelijk) om dit soort fouten te maken.

Opzich eens, maar het punt is dat bepaalde functionaliteit niet te schrijven is in C# omdat de zaken die C/C++ gevaarlijk maken ook soms nodig is om met de hardware te werken of een minimaal performance niveau te halen. Natuurlijk kun je middelware (geschreven in C/C++) maken die functionaliteit abstraheerd en beschikbaar maakt voor C#/Java ontwikkelaars, maar dat is wat de meeste high level SDK's dan ook doen.

Zie ook Windows met C#/.NET en WinRT en Android met Java. Maar uiteindelijk zal de schrijver van het OS die tussenlagen moeten maken, en als die slechte software schrijft ga je alsnog nat. Omdat igv Tizen het lijkt alsof het OS zelf inclusief die middelware fouten bevat, is dat meer een kwestie van gebrek aan aandacht.

Vandaar deels eens, want Tizen zal dus altijd deels in C/C++ geschreven moeten worden. Anderzijds zaken als de Store-app kunnen wel in hogere talen geschreven worden, en juist daar wil je dat ook graag omdat het een potentieel aanvals object is.

[Verwijderd]

Je kan in C# met 'unsafe' code werken, wat hetzelfde werkt als C en je kan er dus alles mee doen wat je met C ook kan, ook hardware benaderen en (function) pointers manipuleren naar hartenlust.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:25]

[Armin]

Onjuist. met unsafe kun je bepaalde veiligheids-elementen uitschakelen, maar in de verste verte niet alles. O.a. speciale CPU instructies kun je niet geven - per definitie - want managed code. En bij unsafe moet je nog steeds een Win32/native C/C++ stukje code hebben om de pointer/hardware toegang te initieren. En ik kan zo nog tientalle voorbeelden geven.

Een OS schrijven in C# gaat bijvoorbeeld niet lukken. Je hebt software lagen tussen OS en C# nodig. En dus "uiteindelijk zal de schrijver van het OS die tussenlagen moeten maken, en als die slechte software schrijft ga je alsnog nat. "

Maar zelfs los daarvan, het feit dat je met 'unsafe' bepaalde veiligheidselementen kunt uitschakelen, is in feit een directe bevestiging van wat ik schreef. Diezelfde aspecten die een taal als C# veiliger maken, maken het ook ongeschikt voor bepaalde taken. Je kunt die dan uitschakelen, maar dan verlies je ook die veiligheidsaspecten.

[miklas]

Het is natuurlijk moeilijker om een fout te maken als de programmeertaal het niet toelaat, maar deze vrijheid is soms nodig. Veiligheidsfeatures zoals bounds checking of features zoals garbage collection zijn natuurlijk niet gratis en al zeker niet op de hardware van bijvoorbeeld een smartwatch. Benchmarks zijn helaas vaak belangrijker voor de verkoopscijfers dan het veiligheid argument.

Echter zijn er gezien de lange geschiedenis van C en C++ genoeg static analyzers te vinden, en kunnen er in debug builds perfect bounds checks & smart pointers gestopt worden, een beetje zoals Rust out-of-the-box doet. _{(Probleem met iets zoals Rust is de beperkte beschikbaarheid van API's en programmeurs)}

[Verwijderd]

In Pascal zit wel bounds checking en ik heb nooit enig verschil kunnen bemerken in performance met C, althans niet in desktop applicaties.

Ik weet niet of Lint et al. de fouten die we nu vaak zien zou hebben opgespoord. Vaak hebben compilers al veel warnings(in verbose mode) die hetzelfde doen, maar waar gewoon niet naar gekeken wordt door ontwikkelaars lijkt het. Daarom vind ik dat de taal het onmogelijk moet maken om foutieve code te schrijven, en laat de performance dan maar een paar procent minder zijn.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:25]

[miklas]

Ik snap je punt, maar ben het er niet mee eens. Het is niet omdat het gevaarlijk is, dat we het niet moeten gebruiken. Anders kunnen we best drank, frietjes en snoep verbieden, want teveel alcohol, vet en suiker zijn gevaarlijk voor de gezondheid.

In mijn sector (video games) zie ik in de builds met safety checks enabled (onder andere bounds checking) toch wel een verschil in performance tov de builds zonder. Vergeet de schaal niet waarop deze paar procent effect kunnen hebben. Ik kan de exacte source niet terug vinden dus neem dit met een korrel zout, maar ik dacht een talk gezien te hebben van performance engineers bij facebook die door de home page 1% sneller te laten laden, ze $100.000 aan energiekosten per maand konden besparen.

In mijn ogen ligt de keuze dan ook bij de programmeurs en het project. Ik ben wel akkoord dat voor te veel projecten C++ gebruikt wordt, terwijl een andere taal mogelijks beter geschikt zou zijn. Maar dat is vrees ik typisch voor een taal die veel (lead) programmers kennen, waar er al een legacy codebase (zoals Bada in dit geval) van bestaat, of waar er al zoveel middleware voor bestaat. Er is nu al een tekort aan programmeurs zodat er op onderwijs, veiligheid en kwaliteit bespaart wordt, laat staan dat bedrijven dan nog tijd willen besteden om die codebase/middleware om te vormen naar een veiligere taal.

[Verwijderd]

Je vergist je, want ik programmeer nog vaak in C en C++. Maar ik ben realistisch genoeg om in te zien dat mensen fouten maken en dat deze talen te weinig belemmeringen hebben om fouten te maken. Alleen C++ kan je zonder problemen gebruiken als je weet wat je doet, maar open-source software wordt vrijwel altijd in C geschreven, wat het kwetsbaar maakt voor fouten en het overnemen van computers.

[BoringDay]

In elke taal kan je fouten maken, ook in moderne talen, dat maakt een taal niet slecht.

[Enai]

Het is inderdaad de taak van de programmeur om geen fouten te maken, net zoals het de taak van een piloot is om niet neer te storten en de taak van een operator van een kerncentrale om niet alle regelstaven uit een reactor te trekken wanneer deze instabiel is en alle veiligheidssystemen en het koelsysteem zijn uitgeschakeld. Maar vliegtuigen storten wel degelijk neer en Chernobyl is in de lucht gevlogen.

Het hele argument tegen kernenergie is dat de mens niet 100% betrouwbaar is en dat we dus limieten moeten stellen aan de verantwoordelijkheid die een persoon op zich draagt. In de softwarewereld krijg je dan Cloudbleed of een neergestorte Marslander van honderd miljoen.

[GamingZeUs]

Slordigheid en haast, daarna onbegrip. Het is met C soms best moeilijk om te weten wat je precies tiept.

Waarom je C gebruikt voor foutgevoelige software ontwikkelt door talloze mensen, dat is iedereen een raadsel.

Zeker als je niet voldoende audits, tests, fuzzing en proofs gaat maken. En welk bedrijf bezuinigt op features voordat ze bezuinigen op veiligheid? Op de uni wordt je ook niet echt gestraft voor je "show stopping bugs", laat staan veiligheids bugs.

Idk pretty obvious dat je C iig vermijd in de praktijk.

[BoringDay]

" dat is iedereen een raadsel."

Blijkbaar niet want het wordt nog heel veel gebruikt (bijv. hardware)

[Stukfruit]

Bada zelf zat prima in elkaar, maar Tizen is weer gebaseerd op code van LiMo en Meego.

..en om die opmerking enigszins te onderschrijven:
https://what.thedailywtf.com/topic/15001/enlightened/4

EFL is onder de motorkap altijd een brak stukje werk geweest en dit is waar Tizen op gebaseerd zou zijn.

In de documentatie van Tizen's framework gebruikt men trouwens ook vrolijk strcmp ipv strncmp:
https://developer.tizen.o..._APPLICATION__MODULE.html

[rjberg]

Misschien een rare suggestie, maar is C niet bedoeld om dicht bij assembly te staan? Om directe toegang te bieden, voor hogere performance?

Het in mijn ogen inderdaad een trade-off met veiligheid, en misschien moeten we voortaan C alleen gebruiken waar het nodig of handig is. Ook zouden we er voor moeten zorgen dat C alleen door programmeurs gebruikt wordt die weten hoe ze er mee om moeten gaan.

Maar het is denk ik verkeerd om te zeggen dat C fundamenteel fout is. Het is nodig, niet ten minste omdat het een taal is die goed naar assembly kan, zonder "tussenlaag" op run-time. Zo'n taal zul je altijd nodig hebben.

Wel ben ik met je eens dat met C gewoon verkeerd wordt omgegaan. Een mogelijkheid die meer benut zou moeten worden is bijvoorbeeld meer gebruik maken van grote toepassings-gerichte bibliotheken. Een vergissing waarvan ik hoor dat het ook voor andere talen geldt.

Bijvoorbeeld: Veel websites, die gebruik maken van "moderne" talen als javascript, krijgen fouten doordat programmeurs steeds opnieuw dezelfde dingen opnieuw doen. (Forums, wachtwoorden, betalingen, etc). Dingen die gewoon in standaardpakketten zitten, op een goed geschreven en geteste manier. Door deze te gebruiken zouden websites een stuk veiliger kunnen.

Ik denk dat het met C hetzelfde is. Gebruik dingen waarvan je weet dat ze veilig zijn, en ga niet zelf het wiel opnieuw uitvinden. Zolang programmeurs echter zelf de dingen doen waar ze eigenlijk niet gekwalificeerd voor zijn gaat het mis. Maar het is ook niet zo gek dat ze dit soort dingen verkeerd doen, als je wel leert programmeren in php en sql maar niet leert wat een SQL-injectie is, dan hou je er ook geen rekening mee. Wel ben ik van mening dat deze strncpy functie moet worden weggehaald of aangemerkt als fundamenteel onveilig.

[cdwave]

strcpy() is al aangemerkt als potentieel onveilig. Er is echter geen 1-op-1 vervanger voor in de C standaard, strncpy() is een wezenlijk andere functie, en de strscpy() die je soms tegenkomt is geen standaard.

Niet elk gebruik van strcpy() betekent automatisch ook een potentieel lek, de meeste instanties in bestaande code zijn gewoon prima in orde.

[tweaknico]

strcpy met veel misten en maren en controles KAN goed gebruikt worden.
Maar de kans op mislukken is groot. Het grootste probleem is de specificatie van strings...
die is content afhankelijk, een bepaalde code in de string geeft het einde aan...
Daarom is strcpy onbetrouwbaar.
Als je eerst strlen() gebruikt en het resultaat daarvan gebruikt (lees maximeert, met een meegegeven lengte) dan heb je een poor mans implementatie van strncpy gemaakt.

Kortom gebruik liever memcopy() (Niet content afhankelijk) of gebruik zinnige strings mbv. bv. een desciptor: (=een startadres + lengte in een structure) en geen content afhanekijl einde.

[BoringDay]

"een bepaalde code in de string geeft het einde aan"
kortom basis kennis, null-terminated string
https://en.wikipedia.org/wiki/Null-terminated_string

[tweaknico]

Welke code het is, is NIET relevant, onder CP/M werd '$' gebruikt in PUT_STRING. De Taal C geeft er ook niet om,
strings zijn een afspraak in de C-runtime library, als jij een library maakt die consequent 0xFF gebruik en de Lex. Scanner ook die 0xFF laat gebruiken dan is na de eerst volgende compiler run de End of string 0xFF.

Met name de str*() functies bepalen hoe een string eruitziet, de rest is ervan afgeleid. Verder is de string definitie alleen van belang in een aantal filesystem functies: open(), create(), unlink(), link().

[Accretion]

Java

C/C++ is nu eenmaal het meest efficiënt, juist omdat het geen garbage collection (of VM of JIT) heeft.
Het klopt overigens wel dat je hier ook een programmeur voor nodig hebt die daadwerkelijk weet wat hij aan het doen is.

[TheGhostInc]

die daadwerkelijk weet wat hij aan het doen is.

Ik ken genoeg programmeurs die geniaal zijn in hun vak, maar een drama in hun domein.

En daar zit de crux. Stel de dosering van een medicijn moet worden bepaald. Heb je dan liever de programmeur die in C dit super snel oplost, maar geen idee heeft of de uitkomst klopt. Of de programmeur die exact weet hoe de berekening & uitkomst moet zijn, maar het in Java oude stijl doet?
DAAROM is Java zo populair, omdat veel Javanen kennis hebben 'van iets anders'. De taal is ondergeschikt aan de domeinkennis. En zonder domeinkennis programmeren is met je ogen dicht rondlopen terwijl iemand anders aanwijzingen roept.... dat gaat even goed, totdat iemand even is afgeleid.

[Accretion]

... Is dit serieus een argument?
Je vergelijkt appels met peren.
Een programmeur, onafhankelijk van taal kan niets zonder domeinkennis.
Hoezo zou een C/C++ programmeur per definitie minder domeinkennis hebben dan een Java programmeur?

De domein kennis komt niet van een taal. Een taal wordt gekozen naar gelang het domein.

Die calculaties voor het medicijn staan compleet los van de programmeertaal.

Voor embedded/efficiënte/realtime/low-level applicaties gebruik je C/C++. JVM draait niet met 1kB RAM en garbage collection is alles behalve realtime. En de JVM laag is leuk, maar hierdoor kun je never nooit niet hardware direct aanspreken en is er inefficiëntie door de vertaalslag.

Voor een backend kan dat ongeveer elke taal zijn. Wellicht zou ik hier zelfs niet zo snel C/C++ voor kiezen, als performance niet kritisch is. (Maar ook iets dat minder afhankelijk is van Oracle, maar afijn).

"Javanen", serieus?

[RayNbow]

Voor embedded/efficiënte/realtime/low-level applicaties gebruik je C/C++. JVM draait niet met 1kB RAM en garbage collection is alles behalve realtime. En de JVM laag is leuk, maar hierdoor kun je never nooit niet hardware direct aanspreken en is er inefficiëntie door de vertaalslag.

Tuurlijk kan een JVM wel draaien met 1 KB RAM.

[Accretion]

Leuk dat het theoretisch mogelijk is.
Wat niet betekend dat het een goede oplossing is.

Qoute:
Execution speed of non time-critical applications is therefore less important.
This observation has led us to actively trade off clock cycles for bytes on the heap, the exact reverse of many optimizations found in desktop and mobile JVMs where memory is available by the megabyte.
When designing our Darjeeling Virtual Machine (DVM) we have chosen not to implement the full Java virtual Machine Specification.

Oftewel significante performance loss en eigenlijk nog steeds geen JVM (voldoet immers niet aan de specificaties).

Ik blijf bij mijn punten: efficient, realtime en low-level.
Natuurlijk kun je JVM herschrijven (in C/C++) voor een microcontroller en ongeveer werkend krijgen. Maar daar wordt het niet meer realtime/efficient van.

[RayNbow]

Leuk dat het theoretisch mogelijk is.
Wat niet betekend dat het een goede oplossing is.

Het betekent ook niet dat het geen goede oplossing is.

De motivatie uit het artikel:

Low-cost embedded systems [...] are deployed in remote or dangerous areas so must run autonomously throughout their complete lifetime, i.e. for several years.

[ApexAlpha]

Linux en Windows zijn toch ook op C gebaseerd?

[Verwijderd]

Daarom kan je ze ook hacken.

Als men een C# of Java native code compiler zou maken en daar een besturingssysteem in zou schrijven dan zou dit vrijwel niet te hacken zijn, je zou echt moeite moeten doen om het hackbaar te maken.

[Tjahneee]

Onzin. Java draait in JVM (Java virtual machine) en die is gewoon in c geschreven. Dus onder water voer je alsnog code in c aan. En ik denk dat C# daar niet veel van afwijkt met zijn framework.

edit;

Tevens als je gaat kijken in de standaard libary van Java zie je vaak de interface "Native" terug komen. Dit betekent dat er woord door verwezen naar code vaak gecompileerd vanuit c/c++. zie; link

[Reactie gewijzigd door Tjahneee op 23 juli 2024 11:25]

[R4gnax]

Onzin. Java draait in JVM (Java virtual machine) en die is gewoon in c geschreven. Dus onder water voer je alsnog code in c aan. En ik denk dat C# daar niet veel van afwijkt met zijn framework.

De huidige generatie C# compilers is in C# geschreven en kunnen zichzelf ook compileren.

Het .NET framework is op bindings naar Windows APIs na in managed code geschreven die op jouw systeem naar native code voor jouw specifieke processor-architectuur geoptimaliseerd wordt via ngen. (Vziw is ook ngen tegenwoordig in C# geschreven.)

Microsoft heeft daarnaast grote delen van Windows zelf ook herschreven naar C#. (De grote reden dat .NET 3.5 een systeem onderdeel van Windows 7 was en dat latere versies die rol in Windows 8 en 10 overgenomen hebben.)

Heleboel Windows vulnerabilities zitten tegenwoordig enkel nog in native code; oude onderdelen van Windows of onderdelen die performance-technisch niet eenvoudig in C# geschreven kunnen worden.

[Verwijderd]

Java is gewoon een computer taal die ook gewoon gecompileerd kan worden naar machinetaal net als elke andere programmeertaal.

De reden dat Java in een JVM draait is omdat het oorspronkelijk bedoeld was om op allerlei apparaten te draaien. Later werd het pas voor webpagina's gebruikt.

[Tjahneee]

Java compileer je naar "bytecode" die je weer in de JVM kan draaien. JVM is beschikbaar op verschillende architecturen (zoals ARM, x86-64 etc) zodat je je "bytecode" op alle systemen kan draaien (Als er een JVM voor is) zonder deze opnieuw te hoeven compileren. C/C++ compileer je direct naar de opgegeven instructieset en kan dan ook alleen op die architectuur draaien.

[Reactie gewijzigd door Tjahneee op 23 juli 2024 11:25]

[Verwijderd]

Veel native C / C++ compilers gebruiken intern ook een soort bytecode voordat ze het naar een backend machinetaal inzetten. Dat is niet veel anders. Een JVM doet die laatste omzetting 'on the fly'.

[BoringDay]

Wat denk je van reflectie/disassembleren? veel plezier ermee

[MatthijsZ]

Onzin.

Linux en Windows zijn niet 'te hacken' omdat ze in C geschreven zijn. Er zitten bugs in omdat het gaat om miljoenen regels code.
Oók in Java en C# kunnen veiligheidsbugs zitten. Sterker nog, in de JRE zitten standaard al veel vulnerabilities.

C kun je prima door een (static-)code-analysis tool halen om fouten als deze eruit te halen. In dit geval zijn ze bij Samsung lui of incompetent geweest.

[84hannes]

Is de JRE in Java geschreven?

[MatthijsZ]

Nee, dat moet ik even verduidelijken
De JRE is inderdaad niet in Java geschreven, maar wat ik bedoel is dat een programma in Java óók vulnerabilities met zich mee brengt. Zelfs als je nog geen regel code hebt geschreven.

[Blue Eyed Devil]

En in welke taal denk je dat de meeste native compilers geschreven zijn?
De meest native compilers hebben hun basis in C en soms zijn daar dan uitbreidingen op gemaakt in Java, C# of andere talen.

C#: Originele compiler geschreven in C.
Java: JVM ea. origineel geschreven in C
Rust: Compiler geschreven in Ocaml waarvan de compiler dan weer origineel in C is geschreven...

En zo kan ik blijven doorgaan

[Verwijderd]

Een compiler kan je in elke taal schrijven.

Er zijn genoeg compilers die geschreven zijn in C# of Java.

[84hannes]

De eerste C compilers waarschijnlijk in Assembly. Zijn alle nadelen van Aasembly daardoor van toepassing op C? Ik zie de relevantie niet.
C is een hele goede taal voor bepaalde toepassingen, dat zie ik niemand ontkennen. Maar hij blinkt niet uit in veiligheid.

[Accretion]

-

[Reactie gewijzigd door Accretion op 23 juli 2024 11:25]

[Anonymoussaurus]

Klopt, maar in combinatie met andere talen. Bovendien gebruik je dan hele andere code als ik het goed heb.

[TheMak]

De taal C blijft nodig, de JVM's zijn veelal zelf ook in C geschreven. De stap van assembly van de processoren naar Java of C#, die geen weet hebben van processoren, is te groot.

[84hannes]

De Rust-compiler is al een tijdje self-hosting. Afgezien van het feit dat er in de voorzienbare toekomst dramatisch weinig support voor is (vanuit hard- en software) zou je hiermee in principe een ecosysteem zonder C kunnen bouwen.

[Verwijderd]

Soms wil je geheugen kunnen serializeren 'zoals het is'. Pascal strings beginnen natuurlijk met de lengte van de string. Dat maakt dat je het geheugen niet één op één kan serializeren.

In C en C++ is het aan de programmeur om een Pascal string zelf te definieeren. M.a.w. moet jij maar zelf dit definieeren:

typedef struct {
int length;
char *str;
} PascalString;

Een programmeertaal zoals C laat dit over aan de programmeur. Er zijn echter veel string typen die vele C en C++ programmeurs gebruiken. Bijvoorbeeld hier, hier en hier.

[Verwijderd]

Er valt echt wel omheen te werken, dus dat vind ik geen argument. En je gaat het niet oplossen als je ontwikkelaars dit soort fouten zelf laat oplossen, want niet iedereen (de meesten) gaan dit doen. Het moet in de taal zelf ingebouwd worden.

[BoringDay]

Dit zijn helemaal geen fouten in de taal C, dit is gewoon eenmaal hoe een taal als C in elkaar zit. Daarbij C is een taal die ontwikkeld is voor Unix om Unix weer te herschrijven in C.

[Reactie gewijzigd door BoringDay op 23 juli 2024 11:25]

[Pep7777]

Het is echt een mindset probleem en geen programmeertaal probleemer zijn al jaren "veilige" varianten om in te coderen.
Bijv. stncpy.

Wel kunnen talen helpen C++(11) heeft een heel goede manier om met geheugen om te gaan. Bijn niks meer handmatig bijhouden (shared_ptr, unique_ptr, std::vector etc. etc.).

Dus volgens mij kies je niet een taal omdat die "veiliger" is maar omdat hij past bij wat je gaat doen.
Java, .Net enzo leveren kleinere binaries op. C/C++ geeft je weer andere mogelijkheden.. maar security doe je bij design!

[Verwijderd]

strcpy is maar een voorbeeld. Strncpy bestaat al vele jaren en toch gebruiken ontwikkelaars het niet altijd.

Het is maar gedeeltelijk een mindset. Je moet gewoon bewust zijn dat mensen fouten maken en dat je dit dus moet ondervangen in de programmeertaal zelf.

[cdwave]

strncpy is geen vervanger voor strcpy.

char buffer[1024];
strcpy(buffer, "Hello world!"); /* Copies 13 bytes (including terminating 0) into buffer */
strncpy(buffer, 1024, "Hello world!"); /* Copies 12 chars and writes 1012 zeroes into buffer */

[Verwijderd]

Het gaat er om dat je het buffer niet kan overschrijven.

Maar ik vind C++ string classes toch wel veel beter omdat je daar nooit een invalide string kan krijgen. Het geheugen wordt automatisch gealloceerd. Met strncpy() kan je een niet null-terminated string krijgen als de source groter is dan het buffer.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:25]

[cdwave]

Of 1024 zou een constante moeten zijn, want als iemand de eerste regel vervangt door "void* buffer=malloc(1024);" dan compileert het nog altijd prima, maar veroorzaakt het juist problemen omdat de inhoud van buffer niet meer nul-terminated is.

Uiteindelijk is het aan de programmeur om het goed te doen. Met eindeloze "coding guidelines" kun je niet alle oplossen.

[Zezura]

C is geen groot probleem,
Het is alleen voor sommige programmeur gewoon niet weggelegd of sommige programmeur snappen het niet.

C is de beste taal in mijn Opinie, is ook de reden waarom game engines geschreven worden in C met een klein beetje C++ voor de user.

C heeft geen checks, nee klopt zijn die nodig dan?, nee ze zijn niet nodig zolang je zelf goed oplet en maatregelen neemt.
Het feit dat er in C Geen onnodige checks inzitten of debug geronslomp maakt het een high performance taal.

C++ debug vs C debug is een heel verschil. Beginners gebruik C++ en ligt aan wat voor applicatie je schrijft. Maar tegenwoordig Met data-driven game engines is het C All-The-Way. Dat zegt toch wel iets.

Maar voor veel andere dingen is C# een betere keus, maar dat wil nog niet zeggen dat C slecht is..

[Verwijderd]

C is niet slecht perse, maar gewoon de minst goede keus nu alle apparatuur op het internet wordt aangesloten. Vroeger boeide het niet als je een verkeerde geheugen allocatie had in je programma als deze alleen lokaal draaide. Nu kan de hele wereld bij jou digitaal inbreken als dit gebeurt. Dit komt allemaal omdat C dit mogelijk maakt.

[Zezura]

Ja, zo zijn er ook in C# dingen te misbruiken als deze niet goed worden geprogrammeerd, punt is. er zullen altijd bugs zijn, en of je nu C schrijft of C# als je er niet je best op doet om het tegen te gaan , zul je vunrable code schrijven, in welke taal dan ook.
C maakt het makkelijker, maar daarom moet niet elke programmeur denken dat ze maar C moeten gaan schrijven, dit moet je bewust doen en overlaten aan mensen die zich bewust zijn van de eingenschappen.

[Verwijderd]

Talen zoals C# zorgt er voor dat fouten niet leiden tot overname van je computer. Je kan natuurlijk nog steeds logische fouten maken (zoals encryptie verkeerd gebruiken of niet gebruiken) maar veel van de fouten die je nu vaak bij C ziet zullen niet meer mogelijk zijn. Dan verklein je het kwetsbare oppervlak met 95%.

[Zezura]

Denk je niet dat de aanvals vector dan de CRT wordt ?. Er blijft een C/assembly native runtime.

[Verwijderd]

Die kan je ook herschrijven in C++ of C#. Het .NET Framework is vergelijkbaar met de CRT en is gewoon in C# geschreven.

[cdwave]

Dagelijks snijden mensen zich in de vinger met een aardappelschilmesje. Laten we aardappelschilmesjes verbieden, en alleen nog volautomatische aardappelschrapmachines toestaan.

[jja2000]

Meego draait zich om in zijn graf

Dit is wel jammer natuurlijk, een toegankelijke package manager + maintained packages hadden de verschillende componenten natuurlijk veel veiliger gemaakt.

[Reactie gewijzigd door jja2000 op 23 juli 2024 11:25]

[PrivacyMind]

Het is wel jammer van Samsung dat ze er pas wat aan doen op het moment dat iemand het nieuws zoekt. Ik snap dan ook waarom de CIA zicht vooral op samsung tv's richte (uit de resente Vault 7 gebleken).

[Reactie gewijzigd door PrivacyMind op 23 juli 2024 11:25]

[LopendeVogel]

Tsja alsof Samsung toen niet al zoiets had van; ej wat is er met onze tv's aan de hand.. Je zou bijna gaan denken of ze niet heel toevallig samenwerken..

[Verwijderd]

[fun intended]
Het bannerlogo klopt wel.. OPENNESS... staat inderdaad open
[fun intended off]

Hopelijk worden ook oude smartwatches en smarttv's gepatcht... blijkt toch wel een dingetje te worden in de toekomst... oude exploits in oudere apparaten die niet gepatcht worden. Hopelijk dit wel.

[innerchild]

Vind eigenlijk de eerste zin erboven nog beter bij passen :

- Connect Everything

Beter kun je het niet zeggen.....

[Verwijderd]

hahaha ja klopt! zelfs wat je niet wilt connecten connect ie

[Verwijderd]

Niet gedacht dat ik dit ooit ging antwoorden. Maar strcpy is niet hetzelfde als strncpy, en strcpy (a, b) is perfect veilig wanneer je zeker bent dat de \0 van b minder veel bytes ver staat als dat a groot is.

Het probleem (met bv. strcpy) is dat veel programmeurs denken dat ze weten wat ze aan het doen zijn, er zelfs van overtuigd zijn, een godgevoel hebben wij alles wat ze maken. Maar de realiteit is dat geen van al die zaken waar is. En dat dit altijd het geval is, bij alle programmeurs. Vooral bij diegene die overtuigd zijn van hunzelf..

M.a.w. strncpy is uiteraard te verkiezen boven strcpy. Maar omdat strncpy(a,b,n) maar n ver kijkt in b om naar a te kopieëren is strncpy niet hetzelfde als strcpy (dat blijft kopieëren uit b tot de \0 byte gevonden wordt). M.a.w. moet je met bv. strlen(b) gaan zoeken naar \0 bytes, wat met strcpy niet altijd moet.

Grotere problemen zie ik met strtok(str, delim) dat NULL bytes schrijft naar haar input. Daarom ook dat de str parameter van strtok char* en niet const char* is. Heel vaak wordt strtok samen gebruikt met een IPC systeem. Dat IPC systeem voert functie-pointers uit (callbacks). Die callbacks hun API is dat de buffer die je binnenkrijgt const * is. Maar de programmeurs die zulke callbacks implementeren gaan dan toch maar strtok op die buffer doen. Dus het bovenliggende IPC moet plots om kunnen met het feit dat de callbacks bytes schrijven naar de input die zij nog moeten parsen. Uiteraard bestaat er strtok_r wat een beter idee is en strdup om te tokken op een kopietje. Maar daar voelen de helden van C zich te vaak te goed voor.

Niettemin allemaal zware securityfouten gemaakt door de helden van C.

Maar goed. Ik zag ook "interessantere" security fouten zoals gewoon system(buffer) uitvoeren op een buffer die a) een buffer overflow had en b) ingevuld kon worden door POST variablen van een Angular website. Dat was bij een grote speler in de markt van WIFI routers. De bug filen kostte me heel wat gepolitiek en gezever met de ontwikkelaar want "dit is geen bug, want die buffer kan maar ingegeven worden nadat er passwoord-authenticatie is gebeurd". Dit was echter niet waar. De buffer kon tot aan die code komen zonder. De strtok van hierboven werd trouwens ook op de buffer gedaan. Maar deze held van de C vond zich toch te goed om één en ander te herstellen.

En zo, beste jongens en meisjes, zit het meeste van de code van jullie routertjes in elkaar. Maar dus ook van jullie slimme foons. En van jullie auto's. Vooral ook de code van jullie slimme teevees.

[Verwijderd]

Gewoon standaard doen i.p.v. strcpy(a, b) in 2 regels:
strncpy(a, b, sizeof(a));
a[sizeof(a) - 1] = 0;

Gedoe met strlen() gaat fout als er geen terminating 0 in de string voorkomt. De laatste regel is overbodig als b korter is dan a maar nodig als b geen 0 bevat (of die verder staat dan sizeof(a).

Als het niet om 0-terminated strings gaat is er memcpy().

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:25]

[Verwijderd]

Ik ben het eens met je. Dat is al wat ik daarop wilde reageren :-)

[R4gnax]

Gewoon standaard doen i.p.v. strcpy(a, b) in 2 regels:
strncpy(a, b, sizeof(a));
a[sizeof(a) - 1] = 0;

Caveat: sizeof(a)-1 is ook niet echt veilig voor alle scenario's met text encodings. Om bijv. UTF-8 te ondersteunen moet je vanuit het einde v/d input terug uit wandelend de positie van de laatste character boundary vinden en daar achter afbreken met een null terminator.

[Reactie gewijzigd door R4gnax op 23 juli 2024 11:25]

[Verwijderd]

Ik ga er in de code vanuit dat er niks met text encodings gebeurt. Als er 16 bit karakters gebruikt worden aijn dat of gewoon 2 bytes, of je krijgt OS afhankelijke code zoals dit gedrocht dat ik ooit voor windows met z'n vieze ALL CAPS types moest schrijven:

const char* UnicodeToAnsi(const void* ustr, char* outbuf, size_t bufflen)
{
if (ustr) {
if (WideCharToMultiByte(CP_ACP, 0, (LPCWSTR)ustr, -1, outbuf, bufflen, NULL, NULL) > 0) {
outbuf[bufflen-1] = 0;
return outbuf;
}
}
return "";
}

LPCWSTR AnsiToUnicode(const char* astr, wchar_t* outbuf, size_t bufflen)
{
if (astr) {
if (MultiByteToWideChar(CP_ACP, 0, (LPCSTR)astr, -1, (LPWSTR)&outbuf[0], bufflen) > 0) {
outbuf[bufflen-2] = 0;
outbuf[bufflen-1] = 0;
return (LPCWSTR)&outbuf[0];
}
}
return L"";
}

Hmpf, kan ik hier code ingeven zodat hij de spaties niet allemaal negeert?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:25]

[Verwijderd]

Mja, ik was daarnet ook aan het denken: strcpy of strncpy gebruiken op een Unicode en/of zelfs een UTF-8 string? Geen goed idee! Dat gaan zowiso richting libICU of libunistring moeten.

Maar goed. Ik wilde de discussie ook niet nodeloos rekken. Het gaat tenslotte om Samsung's security problemen, en niet om Unicode implementatie fouten.

[niki_lauda]

Als dit waar is een behoorlijk probleem voor Samsung.

[Xessive]

Dat kan je wel stellen. Niet echt wat je wilt horen als je zoiets in de markt probeert te zetten.

Edity: typo

[Reactie gewijzigd door Xessive op 23 juli 2024 11:25]

[Verwijderd]

Je wordt zo nog bang om een (Smart) TV aan te schaffen.

Ik wordt echt ziek van al die halfbakken implementaties van software. Tijd voor wetten om de aansprakelijkheid voor fabrikanten en leveranciers op te schroeven zou ik zeggen!

[batjes]

Maar die zijn er al? 40 exploits klinkt als een niet deugdelijk product. Daar is al wetgeving voor.

[Tjahneee]

Heb je de lijst al gezien van Android? Een totaal van 850 beveiligingslekken zie; Link. En er zal er vast wel meer zijn. Hoe meer een bepaald product word gebruikt hoe interessanter het natuurlijk is om op zoek te gaan naar beveiliging's lekken.

[tim-405]

Die van ios is nog groter 1091. link

[batjes]

Dat ze er zijn, oke, maar wat in die lijst staat, is gedicht. Kan me niet heugen dat er ooit een moment was tijdens het bestaan van Android dat daar -zover bekend- gewoon 40+ zero days tegelijkertijd open stonden waar Google niets aan deed.

Hier bij Tizen staan er dus momenteel gewoon 40 zero days open waar nu al een aantal maanden geen bal aan gebeurd is en er pas door Samsung na publicatie wat aan gedaan wordt.

We vergeten ook voor het gemak even dat niet zo heel lang geleden, Google 1 zero day voor Windows gepublished had (die al deels gefixed was door MS), en heel Tweakers stond op de achterpoten van hoe kansloos dat wel niet was van MS om zo'n exploit open te laten staan.

In dit geval is Samsung overduidelijk in gebreke gebleven en lijkt mij dat je gewoon aanspraak maakt op de wet Recht op deudgelijk product, want overduidelijk zijn die Samsung producten dat gewoon niet.

[Accretion]

nieuws: 'CIA gebruikt zero-days in Windows, Android, iOS en Samsung-tv's voor...

Samsung TV's en spionage door CIA blijkt ook een ding, George Orwell 1984, iemand?

Ik heb zelf een Samsung, echter heeft deze alleen een ethernetpoort (laat ik nu net geen ethernet in de buurt hebben) en het is zelfs zo erg dat deze geen "standaard" wifi-modules ondersteund (die wel gewoon werken op iets als een raspberry pi), maar je enkel een "samsung wifiadapter" kunt gebruiken.

Daarnaast, bij smartTV's gebruiken ze vaak minimale hardware om maar net dat OS te kunnen draaien en apps worden niet voor elk type of OS uitgebracht.

Op het moment gebruik ik dan maar een chromecast, al kon ik deze niet eenvoudig installeren/beheren zonder hem te koppelen aan een google-account.
Ik heb ook op een input een custom Kodi box (odroid C2), deze kan zelfs 4K aan, maar draait alleen lokale content. Voel mij qua privacy hier wel een stuk beter bij.

[MatthijsZ]

Enige resultaat van aansprakelijkheidswetten is dat open-source en kleine developers wel kunnen opdoeken.

Grote jongens als Samsung hebben een heel team advocaten in dienst die daar toch wel de mazen in vinden.

[aadv]

Een serieuze vraag:
Ik ben niet zo'n techneut als het merendeel van de lezers, zo schat ik in.
Ik wilde net de Gear S3 aanschaffen. Raden jullie die nu af, of kan ik gewoon het horloge aanschaffen en wachten op de updates?

[wouterg00]

De zero-days heeft de onderzoeker echt niet allemaal openbaar bemaakt .Het horloge kan je prima aanschaffen, op een horloge zal daarom waarschijnlijk niet kwaadaardige code worden uitgevoerd en de updates komen er ook als je hem niet aanschaft.

[Reactie gewijzigd door wouterg00 op 23 juli 2024 11:25]

[Accretion]

"Op een horloge zal waarschijnlijk niet kwaadaardige code worden uitgevoerd"

Ik hoop dat de ontwikkelaars niet dezelfde insteek hebben.
Alles met een internetverbinding is interessant, voor bijvoorbeeld een DDOS of het vergaren van gegevens.

[Bekers]

Samsung en software...

Ik zei het 'toevallig' eerder vandaag nog

Samsung moet geen software maken. Hardware is vaak prima, maar de software weerhoudt me echt om nog eens met dat merk in zee te gaan...

[RAAF12]

Dan maar geen online updates meer ophalen voor mijn Samsung TV en vanaf de officiele site op een USB stick zetten.

[Verwijderd]

Het doet de slogan "openess" wel eer aan