MIT maakt tool die automatisch crash-bugs repareert

Onderzoekers van MIT hebben een tool ontwikkeld die crash-bugs in software automatisch moet kunnen oplossen door functionaliteit te 'lenen' van andere software. Dergelijke bugs zijn niet alleen vervelend, maar vormen ook een beveiligingsrisico.

De tool, CodePhage gedoopt, kan security checks van andere software overnemen. Door die functionaliteit te implementeren in de eigen code, kunnen crash-bugs automatisch worden opgelost, zonder dat er een ontwikkelaar aan te pas komt. Vervolgens analyseert de software automatisch of de crash-bug daadwerkelijk is opgelost.

De tool werkt door de input die crashes veroorzaakt te 'voeren' aan een ander softwareproject, de donor. Dat gebeurt samen met input die niet voor crashes zorgt. Vervolgens analyseert CodePhage de stappen die de software uitvoert, en op welk punt het 'donorproject' de input anders behandelt dan het eigen project. Vervolgens kan die andere behandeling worden geïntegreerd in het 'eigen' project.

Opvallend is dat CodePhage niet bij de bron van software hoeft te kunnen om de implementatie te lenen; het analyseren van de uitvoering van de software is voldoende. Ook hoeft het softwareproject waarvan de code wordt geleend niet in dezelfde taal te zijn geschreven. Als de code van een ander softwareproject is geleend, analyseert CodePhage of de crash-bug is opgelost. Zo niet, dan probeert de tool andere functionaliteit van het donorproject te lenen om de bug toch op te lossen.

Volgens MIT bestaat meer dan 80 procent van de code van softwareprojecten inmiddels uit security-checks. Door die checks te automatiseren, zouden ontwikkelaars daar minder tijd aan hoeven te besteden. Het uiteindelijke doel is dat een programmeur niet meer iets hoeft te programmeren dat al eerder is geprogrammeerd.

Reacties (37)

[Bliep]

De hamvraag: Is je software nog consistent hierna? Prima als 1 randgeval wordt opgelost, zolang de rest dan ook maar blijft werken.

Lijkt me wel ontzettend handig om als developer een bugreport te krijgen met direct een mogelijke oplossing erbij. Zou op z'n minst al tijd schelen bij oudere projecten waar je eerst in de codebase gaat lopen zoeken hoe dat ook alweer zat.

[MSalters]

Deze tool produceert geen oplossing waar je als developer iets mee kunt. Aangezien er geen source code "nodig" is, wijst dat op een assembly transformatie. Daar kan vrijwel geen developer iets mee.

Sowieso vind ik het wat dubieus. Stel dat mijn C++ programma als donor wordt gebruikt om een buffer overflow in een C programma op te lossen. C heeft geen expliciete string lengtes, vandaar dat buffer overflows gangbaar zijn. In mijn C++ std::string klasse zit de string lengte direct voor de pointer zelf. Als je die C++ code leent voor het C programma, dan lost dat dus niets op. Die string lengte wordt simpelweg niet voor de pointer opgeslagen.

En dan heb ik het nog over twee talen die op elkaar lijken. Java draait in een JVM, en genereert code Just In Time. Code Phage zou die assembly dan moeten patchen in de microseconde tussen het aanmaken en het uitvoeren.

[roy-t]

Dit vroeg ik me ook af.

Stel mijn programma crashed bij het saven van data. Dan kan ik het me niet voorstellen dat dit programma die crash op zo'n manier repareert dat de volgende keer het programma niet crashed en de data goed opgeslagen wordt.

[MrEddy]

Naast een mooie oplossing voor een vervelend probleem, zie ik ook een potentieel risico. Als een software pakket een grote fout heeft, neemt CodePhage dat over. Als dat geautomatiseerd gebeurt op duizenden software omgevingen is het voor een hacker mogelijk de "master" software te kraken, en zo masaal andere software open te zetten.

_{edit: typo}

[Reactie gewijzigd door MrEddy op 22 juli 2024 18:38]

[djexplo]

“We have tons of source code available in open-source repositories, millions of projects, and a lot of these projects implement similar specifications,”.... , they frequently have subcomponents that share functionality across a large number of projects.”

Het basis idee is dus als de software b.v. crashed. op System.IO.Path.CreateFolder('test') , er in een grote verzamling van (opensource) software word gezocht naar vergelijkbare code die niet crashed op de zelfde input, b.v. omdat er try-catch() omheen staat.

Als een hacker deze (opensource) verzamling manipuleert, kan hij inderdaad moedwillig een nieuw beveiliging lek toevoegen. Maar in het geval van opensource is die kans natuurlijk kleiner.

[Reactie gewijzigd door djexplo op 22 juli 2024 18:38]

[MSalters]

En dan? Stel dat de buggy code een tijdelijke folder aanmaakt, onhouden, en die later delete. Het gaat fout, en nadat CodePhage een try-catch toeveogt wordt er gewoon doorgegaan. In plaats van een "rm -rf /tmp/test/*.*" doe je vervolgens een "rm -rf /*.*". Ouch.

Dit is overigens niet theoretisch, ik heb die "doorgaan met verkeerde pad" bug zelf zien gebeuren. Testers mochten twee PC's herinstalleren.

[Gomez12]

Als adviesmedium op source code lijkt het me perfect, mits je dan maar bijv projecten bewust kan insluiten en uitsluiten.

Maar als fix-medium lijkt het me echt dramatisch, of dat ding moet de complete uitvoering 100% gaan nazoeken of er is een kans dat de hele afhandeling verandert en dat je nog verder van huis bent.

[Rob Coops]

Software patenten is iets dat meteen bij mij opkomt en ook gelijk als een groot probleem blijft hangen als ik hier langer over na denk. Ik vraag me heel erg af of dit ooit echt mogelijk zal zijn buiten een lab omgeving.

[H!GHGuY]

Niet patenten, maar licenties zijn hier een potentieel probleem.

Stel dat je een stuk software onder de GPL licentie patcht met een stuk software die onder een GPL-incompatibele licentie valt. Dan mag je het eindresultaat niet distribueren.

Daarnaast vind ik het maar een bizarre en enorm generieke claim. Ik kan me niet inbeelden dat je bvb door gnutls en openssl en s2n dynamische te inspecteren bij eenzelfde input, zonder verder instrumentatie/stappen, zomaar even de checks kan overnemen.
Next thing: even de bron opzoeken en bekijken want dit lijkt me er eentje van het vat 'too good to be true"...

Update:
Als ik het goed begrijp, bouwen ze van het donor-proces voor zowel de goede als slechte input, een volledige symbolische beschrijving op van wat er gebeurt (op machine-niveau).
Waarschijnlijk komt dit neer op het instructie-per-instructie uitvoeren van de code en telkens opslaan van waar de data komt en aan welke randvoorwaarden die data voldoet.
Wanneer dan bij de donor de 2 codepaden afwijken, gaan ze proberen om die afwijking in het nieuwe process te stoppen om dan te zien of dit het probleem oplost. Tijdens die stap gaan ze ook proberen om alle checks die de ontvanger wel al deed over te slaan, om zo enkel de relevante code te proberen overzetten. Hiervoor hebben ze diezelfde analyse stap ook al laten lopen op het ontvangende proces.

Er moeten dus wel enkele voorwaarden voldaan zijn: 100% reproduceerbaar (geen race condities enz), ik vermoed dat multi-threading ook uit den boze is en liefst heb je 2 inputs die slechts marginaal afwijken van elkaar - maar dan kun je dus even goed broncode gaan lezen.

Ik denk dat het nut voorlopig eerder beperkt is. Beter zou zijn om aan de developer de constraints over te maken die relevant zijn. Bovendien los je hiermee enkel de crash op, het zegt niets over de correctheid van de patch en het uiteindelijk resultaat.

[Reactie gewijzigd door H!GHGuY op 22 juli 2024 18:38]

[kimborntobewild]

Tijdens die stap gaan ze ook proberen om alle checks die de ontvanger wel al deed over te slaan, om zo enkel de relevante code te proberen overzetten.

Alleen relevante code? Bedoel je niet relevante uitkomst (en dan de code-met-bug overslaan).

[H!GHGuY]

Nee, ze voegen checks toe. Maar in plaats van zomaar alle checks over te zetten, proberen ze ook om de checks die al in de ontvangende code aanwezig te zijn te filteren.
Zo worden enkel de extra checks toegevoegd.

[Iblies]

Ik denk dat dit langzaam de nieuwe realiteit wordt. Bij apps zie je dat er op commercieel niveau je met bepaalde 'blokken' soort van software kunt uitbrengen.
Je gebruikt een aantal standaard-functies waarbij je zelf kunt kijken in hoeverre je zelf extra functies cq code toevoegt, ja of te nee.

Er bestaat hartstikke veel software en er bestaan genoeg regels code om bepaalde functies over te nemen zonder dat er sprake is van patent-breuk. Die worden zelfs vaak aangeboden door een ontwikkelaar.
Een voorbeeld kan een game-engine zijn als Unreal. Die is wat ouder, en bepaalde problemen kunnen allang gedocumenteerd zijn, en de daarbij horende oplossing dus ook.

[CivLord]

Dat hoeft geen probleem te zijn, wanneer de tool alleen naar software uit het eigen bedrijf kijkt.
Microsoft zou de tool bv. kunnen gebruiken, waarbij alleen Microsoft software gebruikt wordt. Een probleem dat al eens is opgelost, kan dan zo worden overgezet.
Maar het lijkt me niet dat Microsoft zoiets toe zou willen passen. Dit soort ongedocumenteerde wijzigingen in je software is het laatste dat je als softwaremaker wilt.

In aangepaste vorm lijkt het me wel een goede methode voor mallware om zichzelf na elke nieuwe besmetting te vermommen, maar ik geloof niet dat we daar echt op zitten te wachten.

[gimbal]

"Volgens MIT bestaat meer dan 80 procent van de code van softwareprojecten inmiddels uit security-checks"

Ik weet niet wat voor software er gemaakt wordt in deze moderne wereld, maar die van mij bestaat voor 80% uit business logic en niet uit security checks Waar gaat dit in vredesnaam over?

[Jaahp]

Aangezien ze op de uitvoering van programma's letten, en de broncode niet eens nodig hebben, zal het waarschijnlijk om gecompileerde code (assembly) gaan. Een laag waar je als ontwikkelaar door abstractielagen vaak buiten staat.

Dan nog vind ik 80% heel veel.

[EpicEraser]

80% security checks, 20% comments

Nee, wellicht dat ze kijken hoeveel procent van een enkele trace bestaat uit security checks. Dan klinkt 80% ietsje aannemelijker.

[FrankHe]

Mee eens, die 80% voelt voor mij ook aan als een heel ongeloofwaardig getal. Voor software die in en derde generatie taal wordt geprogrammeerd zou zoiets echt van den zotte zijn.

Wel is het zo dat vierde generatie talen doorgaans hele zware programmatuur oplevert vanwege gegenereerde code die alle mogelijke ingebouwde foutafhandelingen bevat. Als je dergelijke try catch blokken inclusief alle inhoud laat vallen onder de definitie security-checks dan kom je met een beetje duwen en trekken mogelijk richting die 80% maar dan heb je wel een hele flinke overhead aan je fiets hangen.

In dat geval kan een dergelijke vorm van automatische reparatie bijzonder welkom zijn.

[MSalters]

Nergens over. "for i = 0; i < string.size, ++i" voert wel heel vaak een "string length check" uit, maar dat is natuurlijk veel meer dan een security check. Dat is basisfunctionaliteit.

[cdwave]

Ik denk dat ze een heel losse definitie van "security-checks" hebben. Waarmee elke "if (i<string.length)..." automatisch gezien wordt als security check en niet als gewone flow condition.

[jj71]

Het klinkt heel futuristisch allemaal. Dus ze hebben een programma wat zelf programma's kan aanpassen? Ik vraag me af hoe dit dan precies werkt en wat de beperkingen zijn.

Volgens MIT bestaat meer dan 80 procent van de code van softwareprojecten inmiddels uit security-checks.

Dat is lang niet bij alle softwareprojecten zo, dus ik vraag me af wat hier precies bedoeld wordt met "softwareprojecten".

[BCC]

Virussen muteren hun eigen code al tijden om zo virusscanners te ontlopen, dus nieuw is muterende software niet. Wel nieuw is zelfreparerende software, wat een logische stap voorwaarts is.

[begintmeta]

Volgens mij had men in ieder geval bij de universiteit van Utah in het verleden ook het een en ander gedaan in het kader van een DARPA-project, CRASH (Clean-Slate Design of Resilient, Adaptive, Secure Hosts) Volgens mij loopt het onderzoeksprogramma nog steeds

[Verwijderd]

Volgens mij werkt het oplossen alleen als er al een oplossing geschreven is voor het probleem bij andere software. Deze oplossing wordt dan overgenomen en toegepast op het betreffende lek met de nodige controle stappen.

[Gomez12]

Dat is lang niet bij alle softwareprojecten zo, dus ik vraag me af wat hier precies bedoeld wordt met "softwareprojecten".

Simplistisch gezegd, hoe hoger de taal hoe meer security checks...

Een C# en een C++ kennen in principe net zo goed buffer-overflows als C, enkel bevatten de 1e 2 talen security checks in zichzelf / de compiler zodat je het als programmeur niet meer ziet.

[codebeat]

Resultaat: "Nog 'luiere'/slordige programmeurs en nog meer inefficiënte software" onder het motto "het gaat toch wel goed, het wordt toch wel gefixed als het fout gaat'. Handig maar niet goed, steeds minder programmeurs weten van de hoed en de rand en dat is toch wel essentieel als je voor een apparaat een programma moet maken. De programmeur moet blijven nadenken wat er eventueel fout kan gaan.

[kamerplant]

Maar als het werkt is het toch ook gewoon goed?

[codebeat]

Je lijkt wel een klant. Nee natuurlijk niet, dat het werkt hoeft nog niet te betekenen dat het goed is of beter gezegd robuust is. "Als het werkt" klinkt een beetje als 'erin hacken', een kunstje doen, ik weet niet wat ik doe maar het werkt. Dat is dan wachten op problemen, zeker wanneer de software ouder wordt.

Weet wel dat tegenwoordig geld boven hoe het wordt gemaakt staat, hoe sneller hoe beter. Maar sneller is niet altijd beter, qua inkomsten wel maar qua onderhoud op langer termijn niet. De klant laten betalen voor jou slordigheid of nalatigheid vind ik ronduit smerig, vooral de grotere ICT-boeren doen dit.

Het moet niet zomaar werken, het moet goed in elkaar zitten en de programmeur moet snappen wat er gebeurd en waarom. Wanneer je gaat leunen op een tool van MIT is nog niet de garantie dat het allemaal goed gaat. Het is gewoon niet de juiste insteek om problemen op te lossen. Volgens mij krijg je dan een opeenstapeling van fouten, waarschijnlijk blijft de applicatie draaien maar werkt helemaal niet goed omdat een afhankelijkheid niet gelukt is. Dan heeft het in de lucht houden van de app geen enkele zin.

-------
Dat is ook een nadeel van bijvoorbeeld een framework, handig als je de basis begrijpt maar tegenwoordig leren 'programmeurs' alleen het framework en niet de grondbeginselen waarop het framework leunt.. De meeste snappen niet wat er onder dat framework gebeurd. Naar mijn smaak beheers je dan de materie niet, zonder dat framework kun je dan niets, dat is gewoonweg niet goed.

[Reactie gewijzigd door codebeat op 22 juli 2024 18:38]

[kamerplant]

Dat je framework "gebruikers" hebt, die niet perse alles weten van hoe het onder de motorkap werkt, en "framework ontwikkelaars" hebt, dat onderscheid is toch prima?
Als ontwikkelaar hoef je toch ook niet altijd te weten hoe een browser de CPU aanstuurt ofzo?

[codebeat]

Natuurlijk hoef je niet allés te weten, kan ook niet (alhoewel). Om jou voorbeeld aan te houden, je kunt altijd wel duidelijk zie of een programmeur of een webdesigner een website heeft gemaakt. Als je jezelf in kunt denken wat er in zo'n browser allemaal gebeurd dan programmeer je anders. Als ik mijzelf als voorbeeld neem, ik heb programma's gemaakt dat hardware aanstuurt. Dan denk je anders en zorg je ervoor dat het zo efficiënt mogelijk gaat.

Dat is ook met websites zo. een website is geen pagina meer maar een programma. Vind ik ook wel mooi van Google Chrome, de makers ervan zien een website als software en dat compleet juist want dat is het ook. Vandaar ook het SpeedTest programma en hameren ze op efficiënt resource gebruik. Dat houdt in feite in dat je een webpagina zo efficiënt mogelijk opbouwt. Ik kan je vertellen, dat kan gigantisch veel schelen, bijvoorbeeld laadtijd. Daarnaast heb je bij een website te maken met twee kanten, de client kant en de server. Dus wanneer je een website maakt moet je ook de serverkant niet vergeten, ik heb er ook een stukje over geschreven, zie dit artikel (dit is een reactie op een hele discussie):
Deze: http://tweakers.net/reacties/bekijk/7734671/
En deze: http://tweakers.net/reacties/bekijk/7735260/

Iedereen kan een website maken maar kan iedereen ook een technisch correcte website maken, nee, de meeste kunnen dat niet helaas. Het begint veelal bij het gebruik van plaatjes, daar valt zoveel te halen.

Dus ja, om een goede robuuste en snelle website te maken is het wenselijk om meer te weten. Dit geldt natuurlijk ook voor andere apps, hoe meer je weet over het systeem, hoe meer rekening je ermee kunt houden om het zo optimaal mogelijk te laten werken. Ik maak waarschijnlijk andere keuzes omdat ik weet wat er in die browser gebeurd dan iemand die dat niet weet. Niet om om te scheppen maar over het algemeen zijn er weinig fouten (errors, exceptions) in mijn software, dat is verder denken dan alleen "het werkt".

[Reactie gewijzigd door codebeat op 22 juli 2024 18:38]

[jaapzb]

Het uiteindelijke doel is dat een programmeur niet meer iets hoeft te programmeren dat al eerder is geprogrammeerd.

Daarvoor gebruik je toch gewoon frameworks en wrappers? Als het toch gaat om checks die veel voorkomen dan is er waarschijnlijk ook wel een goede open-source tool voor die het al voor je doet.

[PdeBie]

Maar wat nou als er een fout in zo'n framework zit? Dan dien je als ontwikkelaar er toch voor te zorgen dat je de laatste versie van het framework gaat gebruiken (met de nodige gevolgen van dien op je eigen software). Deze tool zorgt ervoor dat dat dus niet nodig is.

[Eelco.L.]

Is dit misschien de eerste echte stap naar Artificial General Intelligence?

[Reactie gewijzigd door Eelco.L. op 22 juli 2024 18:38]

[muppet99]

Ja want dat zijn wel stappen om te leren. Als dit niet werkt, kijk ik bij een ander af hoe het wel moet. Vervolgens voer ik datzelfde kunstje ook uit. Skynet is coming

[Fabbie]

Mmm. Vertrouwen op een tool die security checks moet doen en daardoor zelf geen aandacht daaraan besteden waardoor en nog minder bewustzijn ontstaat hoe belangrijk security wel niet is? "Want daar hebben we een tool voor. Dus ik hoef dat niet te zijn..."

Ik weet niet of dit nu wel zo'n goede ontwikkeling is. Wellicht als hulpmiddel, maar niet "in plaats van" fatsoenlijk programmeren.

[Rudie_V]

Kan deze hele tool dan niet aan de ontwikkelomgeving worden toegevoegd om de fouten eruit te halen voordat de software wordt verspreid en zo kan de broncode ook worden aangepast.