Python-ontwikkelaars brengen patch uit voor 'onschuldige' remote code execution

De ontwikkelaars achter Python hebben een update uitgebracht voor de programmeertaal, omdat daar diverse kwetsbaarheden in zaten. Een van de kwetsbaarheden maakte het mogelijk om op afstand code uit te voeren.

De Python Software Foundation raadt ontwikkelaars aan om te upgraden naar versie 3.8.8 of 3.9.2. In die versies worden twee bugs gerepareerd. De eerste daarvan is CVE-2021-23336. Dat is een webcache-bug waarmee aanvallers de separator kunnen veranderen. De andere bug is ernstiger, want daarbij gaat het om een mogelijke remote code execution.

Die tweede bug is CVE-2021-3177. Daarover kwamen volgens de ontwikkelaars veel vragen van gebruikers, terwijl hen dat naar eigen zeggen verbaasde. Ze zeggen dat het vermoedelijk komt doordat de term 'remote code execution' angstbeelden oproept. Volgens de ontwikkelaars is CVE-2021-3177 in de praktijk echter moeilijk uit te buiten en kan er weinig schade in applicaties mee worden aangericht. Er moet aan verschillende voorwaarden op het systeem worden voldaan. Bovendien kan een aanvaller na het uitbuiten niet zoveel; het is hooguit mogelijk een buffer overflow te veroorzaken en een systeem te laten crashen.

Het probleem zit in PyCArg_repr, waar sprintf kan worden aangesproken. Omdat Python op veel Linux- en Windows-versies standaard wordt meegeleverd, is de impact potentieel wijdverspreid. Verschillende fabrikanten hebben inmiddels patches doorgevoerd waarmee de bug wordt gerepareerd, maar ontwikkelaars kunnen het beste zelf ook nog de patch doorvoeren.

Reacties (14)

[True]

Met een NIST base CVSS score van 9,8 kan ik mij inderdaad voorstellen dat gebruikers hier vragen over hebben.

Volgens de ontwikkelaars is CVE-2021-3177 in de praktijk echter moeilijk uit te buiten en kan er weinig schade in applicaties mee worden aangericht. Er moet aan verschillende voorwaarden op het systeem worden voldaan. Bovendien kan een aanvaller na het uitbuiten niet zoveel; het is hooguit mogelijk een buffer overflow te veroorzaken en een systeem te laten crashen.

Gebaseerd op de score haal ik dat er niet uit. Attack Complexity van Low en een Attack Vector die Network based is. Alles behalve moeilijk en onmogelijk, maar wie weet komt de 'REANALYSIS' tot een andere conclusie dan nu naar voren komt.

[Reactie gewijzigd door True op 26 juli 2024 03:40]

[laurxp]

Als je deze onafhankelijke analyse leest, is het wel duidelijk waarom het geen groot probleem is.

Als je bewust een programma schrijft dat een aantal heel onwaarschijnlijke dingen doet én je zet alle standaardbeveiligingen uit, dan is er een kans dat het mogelijk voor een buffer overflow kan zorgen.

Naar alle waarschijnlijkheid is er geen enkele installatie waar deze bug daadwerkelijk voor code execution kan zorgen. Maar goed: het is theoretisch mogelijk, dus je moet het wel patchen.

[DCK]

Deze redenering geeft heel goed aan wat de beperkingen zijn van het CVE-systeem.

Het CVE-systeem gaat altijd een worst case situatie uit. Maar je moet altijd zelf kunnen analyseren in hoeverre je vatbaar bent voor een CVE. Er zijn CVE's met een score van 9.8 die je met een gedegen analyse kunt negeren, en er zijn CVE's met een score van 4.5 die je meteen op moet lossen. Een CVE geeft een worst case analyse, maar je moet altijd zelf je eigen analyse doen over hoe vatbaar je bent.

Er zijn veel processen die worden ingericht die als botte bijl de CVE-score als absolute waarheid voor je eigen prioritering nemen en daar veel energie mee verspillen. Ik begrijp dat op zich wel, want er is weinig andere data waar je vanuit kan gaan, en niet iedereen weet de ins en outs om een gedegen eigen analyse te doen. Maar bij elke kwetsbaarheid waar je kennis van neemt is het altijd goed om tot een prioritering te komen.

[kipppertje]

Mwah. Als het klopt dat je in een onwaarschijnlijk geval hoogstens de server kan laten crashen kom je uit op een score van 5.9. Dus of de cvss score klopt niet, of het is wel degelijk een spoedje.

https://www.first.org/cvs...PR:N/UI:N/S:U/C:N/I:N/A:H

[DCK]

De implicaties van een buffer overflow worden in het CVE-systeem vrijwel altijd uit voorzichtigheid als remote code execution aangemerkt. Zelfs als er omstandigheden zijn die het laten lijken op dat je alleen een crash kunt behalen, kun je dat zelden met enige mate zekerheid aantonen dat de gevolgen echt beperkt zijn. Dan moet je in de "worst case" analyse uitgaan van remote code execution.

[TheRealProcyon]

Het score systeem is CVSS en niet CVE. Het CVSS systeem werkt op basis van aanvals vector, complexiteit van de aanval, de benodigde privilege, of gebruikers interactie nodig is, of de scope veranderd is, de vertrouwelijkheid van de beschikbare data na exploitatie, de integriteit en de beschikbaarheid van de data.

[Bor]

Het gaat hier om een vroege proof of concept. Het is nog onbekend wat eventuele nieuwe exploits teweeg kunnen brengen. De conclusies in de analyse gaan bovendien nogal kort door de bocht. Zo trekt men de remote code execution mogelijkheid indirect in twijfel en stoelen ze hun advies o.a. op de veronderstelling dat dat de kwetsbare componenten niet in Enterprise omgevingen worden gebruikt. Ik zou niet alleen op deze publicatie afgaan to be honest.

[Oyxl]

Het komt ook vreemd op me over, want sinds wanneer zijn buffer overflows onschuldig? Ik ben geen hacker, maar ik heb altijd geleerd dat buffer overflows bij uitstek geschikt zijn om misbruik van te maken...

Dat zijn dan je developers...

[Power2All]

Het ligt er ook een beetje aan in welke context die buffer overflow zit, en of het sowieso opgevangen wordt. Als dat het geval is, hoeft het niet perse schadelijk te zijn, maar hackers gaan altijd verder zoeken waar uiteindelijk wel die buffer overflow meer doet dan in eerste instantie gedacht werd.

[mbb]

Als nieuwe gebruiker zit ik inderdaad vol vragen. Hoe kan iemand op Internet bij je Python? Python staat toch standaard uit? en zelfs als het draait zit er een windows firewall tussen als het goed is.
Ben je alleen vatbaar voor deze bug als je plug-ins voor web scraping en zo gebruikt? Maar dan moet de aanvaller wel toevallig net die site hebben gehackt met deze CVE waar je data vanaf haalt?

Of is dit gat ook in gecompileerde Python code voor programma's die mogelijk wel internettoegang hebben?

Als externe code eenmaal toegang tot je python heeft kan het schijf toegang modules laden, dus hoe kan het dan onschuldig zijn?

[Opperpanter2]

Ik vraag me vooral af waarom 3.8 en 3.9 wel een fix release hebben gekregen, maar 3.6 en 3.7 (nog) niet? De git branches hebben al wel de fix. https://bugs.python.org/issue42938

[laurxp]

3.6.13 en 3.7.10 bevatten de fix, beide van 15 februari.

[Kjoe_Ljan]

https://github.com/python/cpython/compare/v3.6.12...v3.6.13

ctrl+f op '42938'. Zit er inderdaad wel in.

[Energya]

Commotie terecht of onterecht, het is in ieder geval gefixed