Een van de deelnemers aan de UIUCTF 2025-competitie heeft in detail uitgelegd hoe hij de opdracht heeft uitgevoerd, die vereiste dat hij zijn code op de server uitvoert, enkel door de inhoud van de tekstcommentaar in de code te wijzigen.
De deelnemers konden een netwerkverzoek indienen bij een Python-script, dat een nieuw Python-script met een willekeurige naam aanmaakte, de door de gebruiker ingevoerde gegevens in de tekstcommentaar toevoegde, waarbij de tekens '\n' en '\r' werden verwijderd, en dit script uitvoerde met het commando 'python3 naam.py'. Door alleen de inhoud van de commentaar te controleren, moest de deelnemer een regel uit het bestand '/home/ctfuser/flag' extraheren. Het script werd met de volgende code gemaakt: comment = input('> ').replace('\n', '').replace('\r', '') code = f'''print('hello world!') # Dit is een commentaar. Hier is nog een: # {comment} print('Thanks for playing!')'''
In plaats van '{comment}' werden de gegevens die door de deelnemer waren ingediend ingevoegd, en resulteerde dit in het volgende uitvoeringsscript: print('hello world!') # Dit is een commentaar. Hier is nog een: # Gegevens die door de deelnemer aan de competitie zijn ingediend print('Thanks for playing!')
De opdracht was gebaseerd op een kwetsbaarheid in de CPython-parser, die het nulcode-teken behandelde als een einde van regel (de kwetsbaarheid kon bijvoorbeeld worden gebruikt om schadelijke acties in de tekstcommentaar te verbergen). Het probleem werd opgelost in de versies CPython 3.12.0 en 3.11.4. In de gebruikte parser tijdens de competitie werden alleen de tekens '\n' en '\r' verwijderd, maar bij het gebruik van de kwetsbare versie van CPython kon de deelnemer het teken '\0' als scheidingsteken gebruiken. Niettemin werkte deze truc niet, aangezien er al een gecorrigeerde versie van CPython in de competitie werd gebruikt, in de veronderstelling dat er mogelijk nog andere vergelijkbare fouten in de parser aanwezig konden zijn en dat deelnemers deze zouden kunnen ontdekken.
De deelnemer die succesvol de opdracht voltooide, zocht geen nieuwe kwetsbaarheden in de parser die het mogelijk zouden maken om de string in delen op te splitsen, maar gebruikte de eigenschap van Python om bestanden uit te voeren op basis van hun inhoudstype. Bijvoorbeeld, in plaats van de broncode kan gecached bytecode in een bestand met de extensie '.py' worden geplaatst, en zo'n bestand zal worden uitgevoerd. In de betreffende competitie kon de deelnemer alleen de inhoud in het midden van het bestand beheersen, waardoor hij geen eigen koptekst kon toevoegen om het MIME-type te vervormen.
De uitdaging werd opgelost door gebruik te maken van het feit dat Python, beginnend met versie 2.6, de inhoud van ZIP-archieven kan uitvoeren voor de levering van Python-pakketten in gecomprimeerde vorm. Net als bij bytecode-caching wordt de aanwezigheid van een zip-archief bepaald door de inhoud en niet door de bestandsextensie, dat wil zeggen dat je een zip-archief kunt plaatsen in 'bestand.py' en wanneer je het uitvoert met de opdracht 'python bestand.py', het wordt behandeld als een gecomprimeerd Python-pakket. Bovendien worden ZIP-archieven in Python niet geĆÆndexeerd op basis van de header aan het begin van het bestand, maar op basis van de EOCD-sectie (End of Central Directory Record) aan het einde van het bestand. Als er in het archief een bestand 'main.py' aanwezig is, wordt dit bestand automatisch uitgevoerd wanneer het archief rechtstreeks wordt gestart met het commando 'python archief'.
De wedstrijdopdracht werd opgelost door een vergelijkbaar ZIP-archief te genereren en het in de tekst van de opmerking in te voegen. Om de structuur van het bestand correct te behouden, gegeven dat er aan het einde van het bronbestand de aanroep 'print("Thanks for playing!")' is, werd het bestaan van een commentaargebied in de EOCD-sectie aan het einde benut.
Bron: opennet.ru
