VS: belangrijke opensourceprojecten gemaakt met 'memory unsafe' talen
Veel belangrijke opensourceprojecten zijn gemaakt met 'memory unsafe' programmeertalen en bevatten mogelijk 'memory safety' kwetsbaarheden, zo stellen de FBI, de Amerikaanse geheime dienst NSA, het Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) en cyberagentschappen van Australië, Canada, Nieuw-Zeeland en het Verenigd Koninkrijk in een nieuw rapport (pdf).
De diensten deden onderzoek naar 172 belangrijke opensourceprojecten en ontdekten dat 52 procent van de projecten code bevat die door middel van een 'memory unsafe' programmeertaal is geschreven. Als voorbeelden van memory unsafe programmeertalen worden C en C++ genoemd. Dergelijke talen kunnen leiden tot memory safety kwetsbaarheden, die op grote schaal in hedendaagse software voorkomen. Het gaat dan bijvoorbeeld om buffer overflows of een use-after-free, waardoor een aanvaller in het ergste geval willekeurige code op systemen kan uitvoeren.
Begin dit jaar deed het Witte Huis een oproep aan programmeurs en softwareleveranciers om 'memory safe' programmeertalen te gebruiken. Om te zien hoe groot het probleem van memory unsafety in opensourcecode is, voerden de eerder genoemde diensten het onderzoek uit. Zo blijkt dat 55 procent van alle regels code voor alle projecten in een memory-unsafe programmeertaal is geschreven.
De grootste projecten zijn disproportioneel vaak in memory-unsafe talen geschreven, aldus het onderzoek. Zelfs projecten die in een memory-safe taal geschreven zijn blijken door dependencies kwetsbaar te zijn. Drie in memory-safe talen geschreven projecten bleken allemaal afhankelijk te zijn van onderdelen die in een memory-unsafe taal waren geschreven.
"We stellen vast dat de meeste belangrijke onderzochte opensourceprojecten, zelfs die in memory-safe talen zijn geschreven, mogelijk memory safety kwetsbaarheden bevatten. Dit kan worden veroorzaakt door direct gebruik van memory-unsafe talen of externe afhankelijkheid van projecten die memory-unsafe talen gebruiken", aldus de diensten.
Volgens de diensten is het belangrijk om de omvang van memory-unsafety risico's in opensourcesoftware te begrijpen en verwelkomen ze aanvullend onderzoek. Daarbij merken ze op dat hoewel memory-safety kwetsbaarheden de meestvoorkomende klasse van kwetsbaarheden zijn, het belangrijk is om ook andere systemische klasse kwetsbaarheden te verminderen.
Reacties (29)
26-06-2024, 17:36 door
Anoniem
Heeft natuurlijk niets te maken met dat Linux kernel en 90% van de apps in C zijn geschreven... oorlog aan linux?
want daar kun je cryptografie met een sudo apt install binnen 2 seconden installeren?
want daar kun je cryptografie met een sudo apt install binnen 2 seconden installeren?
26-06-2024, 17:44 door
Anoniem
Overigens is Microsoft Windows in C++ geschreven en Apple is een Linux clone, dus ook C...
Expliciet open source noemen klinkt dan weer erg spijkers op laag water gooien.
Expliciet open source noemen klinkt dan weer erg spijkers op laag water gooien.
26-06-2024, 18:03 door
Anoniem
Ja? En? Zelfs het gebruik van memory-safe talen ontslaat een ontwikkelaar niet van zijn verantwoordelijkheid. Ook met een taal die geen memory-safety heeft ingebouwd, kan je applicaties zonder memory-safety problemen schrijven.
26-06-2024, 18:06 door
Anoniem
Wat. Een. Geleuter.
En hoeveel niet-opensourxe projecten zijn er in een memory-unsafe programmeertaal geschreven? Het zegt werkelijk helemaal niets. Is het weer komkommertijd?
En hoeveel niet-opensourxe projecten zijn er in een memory-unsafe programmeertaal geschreven? Het zegt werkelijk helemaal niets. Is het weer komkommertijd?
26-06-2024, 18:10 door
Anoniem
Rewrite in rust!
26-06-2024, 18:34 door
Anoniem
Ook dit is de NSA... Want de adviezen zijn welkom
E.a. info van de us Intel community die ons zouden kunnen helpen
E.a. info van de us Intel community die ons zouden kunnen helpen
26-06-2024, 19:16 door
Anoniem
Uiteindelijk moet ook een memory-safe programmeertaal naar assembly worden vertaald. Ook hogere programmeertalen zelf kunnen soms assembly broncode fragmenten bevatten in bijvoorbeeld tijdkritische routines of om met hardware te praten.
Assembly is zo ongeveer de minst memory-safe taal die je kunt bedenken. En er is geen alternatief voor voor de huidige CPU's. CPU's werken natively niet in Python.
Goede kans dat je videokaartdriver ook niet memory-safe is geprogrammeerd maar gewoon in C of zoiets. Of de Management Engine in je Intel processor.
Assembly is zo ongeveer de minst memory-safe taal die je kunt bedenken. En er is geen alternatief voor voor de huidige CPU's. CPU's werken natively niet in Python.
Goede kans dat je videokaartdriver ook niet memory-safe is geprogrammeerd maar gewoon in C of zoiets. Of de Management Engine in je Intel processor.
26-06-2024, 19:53 door
Anoniem
zucht.... closed source ook. good luck getting THAT changed...
26-06-2024, 20:08 door
MathFox
We hebben meer dan 60 jaar ervaring met het schrijven van applicaties in 'memory unsafe' programmeertalen, gewoon omdat er niets anders was. Java, de belangrijkste 'memory safe' programmeertaal van vandaag is nog geen 30 jaar oud.
En ik zou graag van de onderzoekers weten hoe ze denken de kernel van een besturingssysteem in een 'memory safe' taal te schrijven. (En hoe memory safe is 'memory safe' in de context van hardware die Direct Memory Access doet?)
En ik zou graag van de onderzoekers weten hoe ze denken de kernel van een besturingssysteem in een 'memory safe' taal te schrijven. (En hoe memory safe is 'memory safe' in de context van hardware die Direct Memory Access doet?)
26-06-2024, 21:01 door
Anoniem
Door MathFox: We hebben meer dan 60 jaar ervaring met het schrijven van applicaties in 'memory unsafe' programmeertalen, gewoon omdat er niets anders was. Java, de belangrijkste 'memory safe' programmeertaal van vandaag is nog geen 30 jaar oud.)
ja, memory safe, alleen die prut die eruit komt niet
26-06-2024, 21:41 door
Anoniem
Door Anoniem: Overigens is Microsoft Windows in C++ geschreven en Apple is een Linux clone, dus ook C...
Expliciet open source noemen klinkt dan weer erg spijkers op laag water gooien.
Expliciet open source noemen klinkt dan weer erg spijkers op laag water gooien.
Mijn herinnering en meerdere bronnen op het internet vertellen dat macOS gebaseerd is op bsd. (Free)bsd is een Unix variant en geen Linux. De meeste unixen zijn geschreven in de taal C aangezien de ontwerpers van Unix ook de programmeertaal C hebben bedacht.
26-06-2024, 22:08 door
Anoniem
Door Anoniem: Overigens is Microsoft Windows in C++ geschreven en Apple is een Linux clone, dus ook C...
Expliciet open source noemen klinkt dan weer erg spijkers op laag water gooien.
Apple is geen Linux-kloon, het is op BSD gebaseerd en een gecertificeerde Unix-variant¹, wat Linux niet is. Linux is juist een Unix-kloon (maar geen Apple-kloon), de Linux-kernel bevat geen originele Unix-code en de basis-programma's eromheen zijn voor een belangrijk deel de GNU-software van de Free Software Foundation (vandaar: GNU/Linux).Expliciet open source noemen klinkt dan weer erg spijkers op laag water gooien.
¹ https://www.opengroup.org/openbrand/register/
26-06-2024, 22:34 door
Anoniem
Door Anoniem: Ja? En? Zelfs het gebruik van memory-safe talen ontslaat een ontwikkelaar niet van zijn verantwoordelijkheid. Ook met een taal die geen memory-safety heeft ingebouwd, kan je applicaties zonder memory-safety problemen schrijven.
Het punt is dat dat zoveel moeilijker goed te doen is dat het veel te vaak niet goed gaat. Het is niet voor niets dat er tegenwoordig zoveel interesse is in memory-safe talen, die voegen wat toe.Door MathFox: En ik zou graag van de onderzoekers weten hoe ze denken de kernel van een besturingssysteem in een 'memory safe' taal te schrijven. (En hoe memory safe is 'memory safe' in de context van hardware die Direct Memory Access doet?)
Er zijn tegenwoordig memory-safe talen die snelle, efficiënte code opleveren en een mogelijkheid hebben voor de onveilige low-level code die bijvoorbeeld een besturingssysteem nodig heeft zonder dat meteen alles die onveiligheid heeft. Als het aandeel code waarin dit soort fouten moeilijk te vermijden is kleiner gemaakt kan worden dan gaat er minder op die manier mis, en het is een heel belangrijke categorie van fouten. Het is niet voor niets dat er tegenwoordig zoveel interesse is in memory-safe talen, die voegen wat toe.Ik zie dit rapport niet als een aanval op open source, zoals sommigen hierboven het kennelijk zien, maar als een indruk van waar we staan. En het is echt geen verrassing, het is bekend dat de Linux-kernel voor het grootste deel in C is geschreven en dat er een hoop applicaties in C en C++ bestaan. Dat is echt niet zomaar even weggewerkt, en dat is echt geen verrassing. En dat het bij andere besturingssystemen ook niet zomaar even weggewerkt is is net zo min een verrassing.
Het overhaast wegwerken zou overigens een slecht idee zijn, in al die besturingssystemen, omdat een hoop van die code beter getest is door jarenlang gebruik dan iets wat opnieuw geschreven wordt; je verkleint de kans op een bepaalde categorie fouten maar dat moet je niet doen ten koste van wat er nog meer fout kan gaan. Maar het andere uiterste, doen alsof er helemaal geen probleem is en door blijven stomen met alleen maar talen waar dit soort fouten wel heel makkelijk te maken zijn is ook niet het beste idee van de wereld.
Dat dat soort talen er tegenwoordig zijn, ook voor het soort code waar C en C++ meestal wordt gebruikt, is een interessante ontwikkeling die niet genegeerd moet worden. En bij dat niet negeren hoort nou eenmaal dat je dit soort rapporten ziet verschijnen. Ik vind dat geen probleem.
27-06-2024, 00:06 door
Anoniem
Door Anoniem:
¹ https://www.opengroup.org/openbrand/register/
Linux is een POSIX implementatie.Door Anoniem: Overigens is Microsoft Windows in C++ geschreven en Apple is een Linux clone, dus ook C...
Expliciet open source noemen klinkt dan weer erg spijkers op laag water gooien.
Apple is geen Linux-kloon, het is op BSD gebaseerd en een gecertificeerde Unix-variant¹, wat Linux niet is. Linux is juist een Unix-kloon (maar geen Apple-kloon), de Linux-kernel bevat geen originele Unix-code en de basis-programma's eromheen zijn voor een belangrijk deel de GNU-software van de Free Software Foundation (vandaar: GNU/Linux).Expliciet open source noemen klinkt dan weer erg spijkers op laag water gooien.
¹ https://www.opengroup.org/openbrand/register/
27-06-2024, 00:54 door
Anoniem
Door MathFox: We hebben meer dan 60 jaar ervaring met het schrijven van applicaties in 'memory unsafe' programmeertalen, gewoon omdat er niets anders was. Java, de belangrijkste 'memory safe' programmeertaal van vandaag is nog geen 30 jaar oud.
We zien wel een voortdurende ontwikkeling van talen die typische programmeursfouten uitsluiten of moeilijk maken, in die jaren.
'strongly typed' is ook een taalkenmerk om klassen van bugs moeilijker te maken, en dat heel veel ouder dan Java .
Ada is ook een taal met als design doel om code met heel weinig bugs te krijgen, en is nu 44 jaar oud.
Binnen de niches waar het gebruikt werd heeft het zich, vzviw ook aardig goed bewezen.
En ik zou graag van de onderzoekers weten hoe ze denken de kernel van een besturingssysteem in een 'memory safe' taal te schrijven. (En hoe memory safe is 'memory safe' in de context van hardware die Direct Memory Access doet?)
Het scheelt al zo ontzettend veel als je 'unsafe access' kunt beperken tot de paar noodzakelijke gebieden waar het echt nodig is, en daar als programmeur heel erg expliciet voor moet kiezen.
Het is toch belachelijk dat een willekeurig stukje code dat wat strings knipt en plakt by default UNSAFE is ?
De kernel is jarenlang bezig geweest om strcpy() om te zetten naar veiliger versies , om maar een berucht voorbeeld te noemen.
In userland roepen alle 'experts' hier dat je alleen als root/admin moet werken als het nodig is, en meteen er weer uit als het noodzakelijke superuser-werk klaar.
Maar voor development is het dan blijkbaar een prima idee om overal, nodig of niet, code te schrijven die alle mogelijkheden heeft en waar een 1-letter fout een enorme bug kan zijn.
27-06-2024, 06:53 door
Anoniem
Door MathFox: We hebben meer dan 60 jaar ervaring met het schrijven van applicaties in 'memory unsafe' programmeertalen, gewoon omdat er niets anders was. Java, de belangrijkste 'memory safe' programmeertaal van vandaag is nog geen 30 jaar oud.
En ik zou graag van de onderzoekers weten hoe ze denken de kernel van een besturingssysteem in een 'memory safe' taal te schrijven. (En hoe memory safe is 'memory safe' in de context van hardware die Direct Memory Access doet?)
Rust wordt tegenwoordig in de Linux-kernel toegelaten. Rust is memory safe zonder runtime overhead, en heeft een En ik zou graag van de onderzoekers weten hoe ze denken de kernel van een besturingssysteem in een 'memory safe' taal te schrijven. (En hoe memory safe is 'memory safe' in de context van hardware die Direct Memory Access doet?)
unsafe
keyword waaronder blokken code kunnen worden ondergebracht die onveilige dingen moeten kunnen. Zo'n taal is geschikt voor kernel-code en maakt het mogelijk om daarbij memory unsafe code tot een minimum te beperken.En met Java zou je trouwens ook nog een heel eind kunnen komen op een bepaalde groep processoren:
https://en.wikipedia.org/wiki/Java_processor
27-06-2024, 07:18 door
Anoniem
Door Anoniem: Uiteindelijk moet ook een memory-safe programmeertaal naar assembly worden vertaald.
Naar machinetaal, bedoel je. Assembler is een voor mensen bedoelde notatie van die machinetaal, die hoeft niet gebruikt te worden. Assembly is zo ongeveer de minst memory-safe taal die je kunt bedenken.
Natuurlijk, maar de machinecode die uit een memory-safe programmeertaal wordt geproduceerd bevat al die mogelijke fouten niet, dat is het punt. Als je redeneert alsof het niet uitmaakt dan kan je alle voordelen van hogere programmeertalen wegredeneren en heeft het geen zin om iets anders dan assembler te gebruiken. Machinetaal kent geen objectoriëntatie dus werkt objectoriëntatie niet. Machinetaal ondersteunt het functionele paradigma niet dus werken functionele programmeertalen als Haskell en Erlang niet. Machinetaal (behalve die van mainframe-processoren) ondersteunt geen decimale getallen dus werken decimale getallen in programmeertalen niet. Alleen is het niet zo dat je al die voordelen kan wegredeneren, die zijn wel degelijk echt, omdat ze de programmeur juist afschermen van al dat foutgevoelige low level-geneuzel en werkelijk fouten voorkomen. Dat geldt ook voor memory-safe talen.
27-06-2024, 09:57 door
Anoniem
Door Anoniem:
En met Java zou je trouwens ook nog een heel eind kunnen komen op een bepaalde groep processoren:
https://en.wikipedia.org/wiki/Java_processor
Door MathFox: We hebben meer dan 60 jaar ervaring met het schrijven van applicaties in 'memory unsafe' programmeertalen, gewoon omdat er niets anders was. Java, de belangrijkste 'memory safe' programmeertaal van vandaag is nog geen 30 jaar oud.
En ik zou graag van de onderzoekers weten hoe ze denken de kernel van een besturingssysteem in een 'memory safe' taal te schrijven. (En hoe memory safe is 'memory safe' in de context van hardware die Direct Memory Access doet?)
Rust wordt tegenwoordig in de Linux-kernel toegelaten. Rust is memory safe zonder runtime overhead, en heeft een En ik zou graag van de onderzoekers weten hoe ze denken de kernel van een besturingssysteem in een 'memory safe' taal te schrijven. (En hoe memory safe is 'memory safe' in de context van hardware die Direct Memory Access doet?)
unsafe
keyword waaronder blokken code kunnen worden ondergebracht die onveilige dingen moeten kunnen. Zo'n taal is geschikt voor kernel-code en maakt het mogelijk om daarbij memory unsafe code tot een minimum te beperken.En met Java zou je trouwens ook nog een heel eind kunnen komen op een bepaalde groep processoren:
https://en.wikipedia.org/wiki/Java_processor
Allemaal waar maar je gaat niet even alle code omschrijven naar een andere taal. Als je dat al wil kost dat vele jaren. Java in de kernel lijkt me niet zo'n beste optie. Rust lijkt mij de betere optie. Neemt niet weg dat de meeste kernels van OSen nog vele jaren gebaseerd zullen zijn op memory unsafe code.
En dan vergeten we nog even alle applicaties die dan nog omgeschreven moeten worden.
27-06-2024, 10:44 door
Anoniem
Het is allemaal voortbordurend op werk van de Open Source Security Foundation. Als onderdeel van de Linux Foundation werkt de OpenSSF aan verschillende technische en educatieve initiatieven om de beveiliging van het open-source software-ecosysteem te verbeteren. Een uitstekend initiatief: [1] Zie ook [2]
Verder snap ik de ophef wel want er moet iets uitgelegd [3] worden:
• About 70 percent of Microsoft common vulnerabilities and exposures (CVEs) are memory safety vulnerabilities (based on 2006-2018 CVEs)
• About 70 percent of vulnerabilities identified in Google’s Chromium project are memory safety vulnerabilities
Uitkomst is op zich logisch want memory safety kost performance en flexibiliteit. Daarnaast ook even relativeren want projecten gemaakt met een memory safe taaltje zoals php levert ongelooflijk veel security problemen (bv wordpress). Daarnaast hebben die talen afhankelijkheden van unsafe memory bibliotheken. Vergeet verder niet dat Somewhere underneath every programming language stack and dependency graph, memory-unsafe code is written and executed.
Acknowledgements:
The U.S., Australian, Canadian, UK, and New Zealand cybersecurity authorities would like to
acknowledge Microsoft for their contributions to this guidance.
[1] https://openssf.org
[2] https://github.com/ossf/wg-securing-critical-projects/tree/main/Initiatives/Identifying-Critical-Projects
[3] https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf
Verder snap ik de ophef wel want er moet iets uitgelegd [3] worden:
• About 70 percent of Microsoft common vulnerabilities and exposures (CVEs) are memory safety vulnerabilities (based on 2006-2018 CVEs)
• About 70 percent of vulnerabilities identified in Google’s Chromium project are memory safety vulnerabilities
Uitkomst is op zich logisch want memory safety kost performance en flexibiliteit. Daarnaast ook even relativeren want projecten gemaakt met een memory safe taaltje zoals php levert ongelooflijk veel security problemen (bv wordpress). Daarnaast hebben die talen afhankelijkheden van unsafe memory bibliotheken. Vergeet verder niet dat Somewhere underneath every programming language stack and dependency graph, memory-unsafe code is written and executed.
Acknowledgements:
The U.S., Australian, Canadian, UK, and New Zealand cybersecurity authorities would like to
acknowledge Microsoft for their contributions to this guidance.
[1] https://openssf.org
[2] https://github.com/ossf/wg-securing-critical-projects/tree/main/Initiatives/Identifying-Critical-Projects
[3] https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf
27-06-2024, 11:44 door
Anoniem
Uiteraard is de toekomst weggelegd voor een memory-safe programmeertaal als Rust.
Maar je complete wagenpark vervangen van een taal als C/C++ naar Rust gaat wel een hele tijd duren.
En wat als er straks nog een taal wordt uitgedacht, die nog een domein aan security-problemen voor is?
Moeten dan alle Rust-programma's weer omgeschreven worden naar die taal?
Maar je complete wagenpark vervangen van een taal als C/C++ naar Rust gaat wel een hele tijd duren.
En wat als er straks nog een taal wordt uitgedacht, die nog een domein aan security-problemen voor is?
Moeten dan alle Rust-programma's weer omgeschreven worden naar die taal?
27-06-2024, 13:48 door
Anoniem
Hier ga je voorlopig dus niks aan doen, 'we' kunnen nog niet eens Cobol uitfaseren laat staan C[++]. Wat je wel kan doen is goede memory management libraries ontwikkelen (en open-source maken) en developers verplichten deze aan te roepen i.p.v. dat ze zelf links en rechts hun eigen memory management implementeren. Een beetje hetzelfde wat je al met encryptie doet, dat ga je ook niet zelf ontwikkelen.
27-06-2024, 13:57 door
Anoniem
Door Anoniem: Hier ga je voorlopig dus niks aan doen, 'we' kunnen nog niet eens Cobol uitfaseren laat staan C[++]. Wat je wel kan doen is goede memory management libraries ontwikkelen (en open-source maken) en developers verplichten deze aan te roepen i.p.v. dat ze zelf links en rechts hun eigen memory management implementeren. Een beetje hetzelfde wat je al met encryptie doet, dat ga je ook niet zelf ontwikkelen.
Zelf ontwikkelen met te weinig mankracht doen vooral die closed source bedrijven want die OSS libs includen mag niet altijd.
27-06-2024, 14:01 door
Anoniem
Door Anoniem:
Allemaal waar maar je gaat niet even alle code omschrijven naar een andere taal. Als je dat al wil kost dat vele jaren. Java in de kernel lijkt me niet zo'n beste optie. Rust lijkt mij de betere optie. Neemt niet weg dat de meeste kernels van OSen nog vele jaren gebaseerd zullen zijn op memory unsafe code.
En dan vergeten we nog even alle applicaties die dan nog omgeschreven moeten worden.
JavaOS, waar MS zo bang voor was, heeft Sun al jaren gelden geprobeerd maar is niks geworden. Veel te traag ook. Ik kan mij wordperfect herschreven in java ook wel herinneren. Wat was dat traag. Het worden nu webapps geschreven in PythonDoor Anoniem:
En met Java zou je trouwens ook nog een heel eind kunnen komen op een bepaalde groep processoren:
https://en.wikipedia.org/wiki/Java_processor
Door MathFox: We hebben meer dan 60 jaar ervaring met het schrijven van applicaties in 'memory unsafe' programmeertalen, gewoon omdat er niets anders was. Java, de belangrijkste 'memory safe' programmeertaal van vandaag is nog geen 30 jaar oud.
En ik zou graag van de onderzoekers weten hoe ze denken de kernel van een besturingssysteem in een 'memory safe' taal te schrijven. (En hoe memory safe is 'memory safe' in de context van hardware die Direct Memory Access doet?)
Rust wordt tegenwoordig in de Linux-kernel toegelaten. Rust is memory safe zonder runtime overhead, en heeft een En ik zou graag van de onderzoekers weten hoe ze denken de kernel van een besturingssysteem in een 'memory safe' taal te schrijven. (En hoe memory safe is 'memory safe' in de context van hardware die Direct Memory Access doet?)
unsafe
keyword waaronder blokken code kunnen worden ondergebracht die onveilige dingen moeten kunnen. Zo'n taal is geschikt voor kernel-code en maakt het mogelijk om daarbij memory unsafe code tot een minimum te beperken.En met Java zou je trouwens ook nog een heel eind kunnen komen op een bepaalde groep processoren:
https://en.wikipedia.org/wiki/Java_processor
Allemaal waar maar je gaat niet even alle code omschrijven naar een andere taal. Als je dat al wil kost dat vele jaren. Java in de kernel lijkt me niet zo'n beste optie. Rust lijkt mij de betere optie. Neemt niet weg dat de meeste kernels van OSen nog vele jaren gebaseerd zullen zijn op memory unsafe code.
En dan vergeten we nog even alle applicaties die dan nog omgeschreven moeten worden.
27-06-2024, 14:34 door
Anoniem
Door Anoniem:
En dan vergeten we nog even alle applicaties die dan nog omgeschreven moeten worden.JavaOS, waar MS zo bang voor was, heeft Sun al jaren gelden geprobeerd maar is niks geworden. Veel te traag ook. Ik kan mij wordperfect herschreven in java ook wel herinneren. Wat was dat traag. Het worden nu webapps geschreven in Python
En dan vergeten we nog even alle applicaties die dan nog omgeschreven moeten worden.
Leerpunt : praktisch alle Android apps worden in Java of Kotlin (wat sterk van Java afgeleid is, en ook op de jvm draait).
Verder is Java in allerlei backend omgevingen waanzinnig veel gebruikt. (uh, google bijvoorbeeld)
Je blik 'is niks geworden' is duidelijk alleen bepaald door desktop enduser applicaties. (waar het inderdaad nogal mislukte).
27-06-2024, 15:23 door
Anoniem
Door Anoniem:
Leerpunt : praktisch alle Android apps worden in Java of Kotlin (wat sterk van Java afgeleid is, en ook op de jvm draait).
Verder is Java in allerlei backend omgevingen waanzinnig veel gebruikt. (uh, google bijvoorbeeld)
Je blik 'is niks geworden' is duidelijk alleen bepaald door desktop enduser applicaties. (waar het inderdaad nogal mislukte).
Je hebt gelijk ik bedoelde vooral de desktop end user. Toch zie ik aan de serverkant wel de opmars van de Python WSGI HTTP Server (gunicorn)Door Anoniem:
En dan vergeten we nog even alle applicaties die dan nog omgeschreven moeten worden.JavaOS, waar MS zo bang voor was, heeft Sun al jaren gelden geprobeerd maar is niks geworden. Veel te traag ook. Ik kan mij wordperfect herschreven in java ook wel herinneren. Wat was dat traag. Het worden nu webapps geschreven in Python
En dan vergeten we nog even alle applicaties die dan nog omgeschreven moeten worden.
Leerpunt : praktisch alle Android apps worden in Java of Kotlin (wat sterk van Java afgeleid is, en ook op de jvm draait).
Verder is Java in allerlei backend omgevingen waanzinnig veel gebruikt. (uh, google bijvoorbeeld)
Je blik 'is niks geworden' is duidelijk alleen bepaald door desktop enduser applicaties. (waar het inderdaad nogal mislukte).
27-06-2024, 19:36 door
Anoniem
Door Anoniem:
Door Anoniem: Uiteindelijk moet ook een memory-safe programmeertaal naar assembly worden vertaald.
Naar machinetaal, bedoel je. Assembler is een voor mensen bedoelde notatie van die machinetaal, die hoeft niet gebruikt te worden.Machinetaal klinkt als iets uit de film The Matrix. En een assembler klinkt als iets dat iets in elkaar zet van verschillende onderdelen. Daarom kies ik voor de term assembly. Dat is duidelijk voor iedereen.
Assembly is zo ongeveer de minst memory-safe taal die je kunt bedenken.
Natuurlijk, maar de machinecode die uit een memory-safe programmeertaal wordt geproduceerd bevat al die mogelijke fouten niet, dat is het punt. Als je redeneert alsof het niet uitmaakt dan kan je alle voordelen van hogere programmeertalen wegredeneren en heeft het geen zin om iets anders dan assembler te gebruiken.Helemaal waar, maar dan heb je meteen geen discussie meer :-)
Mijn punt is dat er altijd mensen nodig zullen zijn die machinecode kunnen schrijven en begrijpen, zodat de hogere programmeertalen kunnen werken. Misschien is het mogelijk een nieuwe programmeertaal in machinecode te schrijven, en dan die nieuwe programmeertaal te gebruiken om zichzelf memory-safe in de nieuwe programmeertaal te compileren. Dan is de compiler memory-safe, maar ik twijfel of toch niet hier en daar machinecode nodig is om alles te laten werken. Dus memory-unsafe talen blijven altijd bestaan en nodig. Bovendien is assembler leuker als high level vind ik persoonlijk. Als de complexiteit van je probleem dit toelaat want je moet heel gestructureerd programmeren in assembler en goed weten wat je wilt en waar je mee bezig bent. Het is GOTO considered harmful maar dan nog een slagje erger.
Assembler heeft een plaats in programmacode voor mij. En debuggers zijn leuk en krachtig naar mijn mening. Neem bijvoorbeeld deze code in pseudo C:
unsigned char c;
for(c=0; c<=255; c++)
{
printf("%c", c);
}
for(c=0; c<=255; c++)
{
printf("%c", c);
}
Dit is om een ascii-tabel te printen. Waar het fout gaat is dat als c==255, deze het ascii teken voor 255 print, dan c ophoogt naar 256, maar dit kan niet dus het wordt 0. Waarna dit simpele programma nooit termineert.
Met een debugger kan je dit zo zien gebeuren, maar in een hogere programmeertaal is dit heel moeilijk om op te lossen omdat het menselijk brein niet zo werkt.
Anoniem 19:16
28-06-2024, 11:01 door
Anoniem
Door Anoniem:
Machinetaal klinkt als iets uit de film The Matrix. En een assembler klinkt als iets dat iets in elkaar zet van verschillende onderdelen. Daarom kies ik voor de term assembly. Dat is duidelijk voor iedereen.
Helemaal waar, maar dan heb je meteen geen discussie meer :-)
Mijn punt is dat er altijd mensen nodig zullen zijn die machinecode kunnen schrijven en begrijpen, zodat de hogere programmeertalen kunnen werken. Misschien is het mogelijk een nieuwe programmeertaal in machinecode te schrijven, en dan die nieuwe programmeertaal te gebruiken om zichzelf memory-safe in de nieuwe programmeertaal te compileren. Dan is de compiler memory-safe, maar ik twijfel of toch niet hier en daar machinecode nodig is om alles te laten werken. Dus memory-unsafe talen blijven altijd bestaan en nodig. Bovendien is assembler leuker als high level vind ik persoonlijk. Als de complexiteit van je probleem dit toelaat want je moet heel gestructureerd programmeren in assembler en goed weten wat je wilt en waar je mee bezig bent. Het is GOTO considered harmful maar dan nog een slagje erger.
Assembler heeft een plaats in programmacode voor mij. En debuggers zijn leuk en krachtig naar mijn mening. Neem bijvoorbeeld deze code in pseudo C:
Dit is om een ascii-tabel te printen. Waar het fout gaat is dat als c==255, deze het ascii teken voor 255 print, dan c ophoogt naar 256, maar dit kan niet dus het wordt 0. Waarna dit simpele programma nooit termineert.
Met een debugger kan je dit zo zien gebeuren, maar in een hogere programmeertaal is dit heel moeilijk om op te lossen omdat het menselijk brein niet zo werkt.
Anoniem 19:16
Omdat het daar zo eenvoudig fout kan kaan, hoef je in Rust geen for-lus meer te schrijven.Door Anoniem:
Door Anoniem: Uiteindelijk moet ook een memory-safe programmeertaal naar assembly worden vertaald.
Naar machinetaal, bedoel je. Assembler is een voor mensen bedoelde notatie van die machinetaal, die hoeft niet gebruikt te worden.Machinetaal klinkt als iets uit de film The Matrix. En een assembler klinkt als iets dat iets in elkaar zet van verschillende onderdelen. Daarom kies ik voor de term assembly. Dat is duidelijk voor iedereen.
Assembly is zo ongeveer de minst memory-safe taal die je kunt bedenken.
Natuurlijk, maar de machinecode die uit een memory-safe programmeertaal wordt geproduceerd bevat al die mogelijke fouten niet, dat is het punt. Als je redeneert alsof het niet uitmaakt dan kan je alle voordelen van hogere programmeertalen wegredeneren en heeft het geen zin om iets anders dan assembler te gebruiken.Helemaal waar, maar dan heb je meteen geen discussie meer :-)
Mijn punt is dat er altijd mensen nodig zullen zijn die machinecode kunnen schrijven en begrijpen, zodat de hogere programmeertalen kunnen werken. Misschien is het mogelijk een nieuwe programmeertaal in machinecode te schrijven, en dan die nieuwe programmeertaal te gebruiken om zichzelf memory-safe in de nieuwe programmeertaal te compileren. Dan is de compiler memory-safe, maar ik twijfel of toch niet hier en daar machinecode nodig is om alles te laten werken. Dus memory-unsafe talen blijven altijd bestaan en nodig. Bovendien is assembler leuker als high level vind ik persoonlijk. Als de complexiteit van je probleem dit toelaat want je moet heel gestructureerd programmeren in assembler en goed weten wat je wilt en waar je mee bezig bent. Het is GOTO considered harmful maar dan nog een slagje erger.
Assembler heeft een plaats in programmacode voor mij. En debuggers zijn leuk en krachtig naar mijn mening. Neem bijvoorbeeld deze code in pseudo C:
unsigned char c;
for(c=0; c<=255; c++)
{
printf("%c", c);
}
for(c=0; c<=255; c++)
{
printf("%c", c);
}
Dit is om een ascii-tabel te printen. Waar het fout gaat is dat als c==255, deze het ascii teken voor 255 print, dan c ophoogt naar 256, maar dit kan niet dus het wordt 0. Waarna dit simpele programma nooit termineert.
Met een debugger kan je dit zo zien gebeuren, maar in een hogere programmeertaal is dit heel moeilijk om op te lossen omdat het menselijk brein niet zo werkt.
Anoniem 19:16
Dat gaat gewoon met ranges en iterators:
for i in 0..=255 {
println!("{}", i);
}
28-06-2024, 13:33 door
Anoniem
Door Anoniem:
[knip - lol van low-level code etc]
Assembler heeft een plaats in programmacode voor mij. En debuggers zijn leuk en krachtig naar mijn mening. Neem bijvoorbeeld deze code in pseudo C:
Dit is om een ascii-tabel te printen. Waar het fout gaat is dat als c==255, deze het ascii teken voor 255 print, dan c ophoogt naar 256, maar dit kan niet dus het wordt 0. Waarna dit simpele programma nooit termineert.
Met een debugger kan je dit zo zien gebeuren, maar in een hogere programmeertaal is dit heel moeilijk om op te lossen omdat het menselijk brein niet zo werkt.
[knip - lol van low-level code etc]
Assembler heeft een plaats in programmacode voor mij. En debuggers zijn leuk en krachtig naar mijn mening. Neem bijvoorbeeld deze code in pseudo C:
unsigned char c;
for(c=0; c<=255; c++)
{
printf("%c", c);
}
for(c=0; c<=255; c++)
{
printf("%c", c);
}
Dit is om een ascii-tabel te printen. Waar het fout gaat is dat als c==255, deze het ascii teken voor 255 print, dan c ophoogt naar 256, maar dit kan niet dus het wordt 0. Waarna dit simpele programma nooit termineert.
Met een debugger kan je dit zo zien gebeuren, maar in een hogere programmeertaal is dit heel moeilijk om op te lossen omdat het menselijk brein niet zo werkt.
Het gaat ook alleen maar fout wanneer je een 'portable assembler' zoals C gebruikt.
Je kiest (en krijgt) een datatype met een beperkte range waarbij de overflow een wrap-around doet, laat dat gebeuren - en compiler en runtime doen er niks aan want het werkt gewoon zoals het hoort. (of mag zo werken wegens 'undefined behaviour') .
In een beetje hogere taal bestaan deze fouten niet omdat het compile time (liefst) afgevangen wordt, en anders run time.
'out of range error' , of zo iets moet je krijgen.
Deze 'stijl' van code gedrag is ook zo ontzettend vaak de bron van bugs met al dan niet security impact - zoals het schrijven voorbij gealloceerde ruimte door strcp() of allerlei andere code .
Nu - bij sommige - programmeurs werkt het brein inderdaad zo dat ze precies de data layout in het geheugen zien die ze willen hebben, en met weinig moeite hun (C) code zo schrijven dat de compiler dat geeft . Een mentale check dat er een overflow op 256 (of 2^32) gebeurt gaat bij hen totaal vanzelf.
Het is aardig om die denktrant van , bijvoorbeeld , Linus zo af en toe te lezen op de kernel list als hij wat hints of commentaar geeft op voorgestelde patches in de core-kernel onderdelen, of een stukje bug-analyse geeft.
Bijzonder indrukwekkend ook hoe vaak zijn 'untested uncompiled PoC' voorstel uiteindelijk de beste oplossingsrichting blijkt.
Maar goed - er is enorm veel code waarin de enorme vrijheid van object-code generatie die een taal als C by default geeft niet nodig is , en het aantal programmeurs dat hiervoor geschikt is, is ook maar een kleine fractie.
Gisteren, 11:27 door
Anoniem
Er zijn niet veel mensen meer die echt gestructureerd kunnen programmeren, net als er velen zijn de spelling van het Nederlands niet op orde hebben, of zelfs matig begrijpend kunnen lezen.
Een hogere programmeertaal biedt dan voorlopig uitkomst en is ook nodig. AI zal dit wel gaan oplossen als het goed wordt gevoed en getrained.
Echter, gaat er nu ook met een hogere programmeertaal ook veel mis, want programmeren is ook een denkwijze cq kunst. Ik zie een vergelijking met het memory gebruik. In de tijd van de 640k DOS geheugen limiet (Bil dacht dat het genoeg was voor iedereen), leerden programmeurs efficiënt omgaan met RAM geheugen. Nu rijst het de pan uit, omdat het kan.
Een hogere programmeertaal biedt dan voorlopig uitkomst en is ook nodig. AI zal dit wel gaan oplossen als het goed wordt gevoed en getrained.
Echter, gaat er nu ook met een hogere programmeertaal ook veel mis, want programmeren is ook een denkwijze cq kunst. Ik zie een vergelijking met het memory gebruik. In de tijd van de 640k DOS geheugen limiet (Bil dacht dat het genoeg was voor iedereen), leerden programmeurs efficiënt omgaan met RAM geheugen. Nu rijst het de pan uit, omdat het kan.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Security Specialist Malware
NCSC
Zit cybersecurity diep in je DNA? Heb jij het in je om op het moment dat het er echt toe doet samen met je collega’s tot de juiste (technische) oplossing te komen? Als security specialist malware bij het Nationaal Cyber Security Centrum (NCSC) doe jij er alles aan om de impact van digitale dreigingen te verminderen en incidenten tegen te gaan.
Information Security Officer
Grijp deze unieke kans voor carrière-ontwikkeling in informatiebeveiliging! Bij Esri bouw je vertrouwensrelaties op en help je zowel ons als onze klanten veiligere technologie te gebruiken. Ben jij de ervaren Security Officer die energie krijgt van werken in 'twee werelden'? Solliciteer dan nu!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
No more ransomware!
De nieuwe Ransomware Awareness Experience training biedt een realistische maar vooral leuke introductie in de wereld van ransomware. De deelnemers ervaren hoe eenvoudig een organisatie het slachtoffer kan worden van ransomware en leren meteen hoe een besmetting kan worden voorkomen!