Hoe niet te reageren op beveiligingslekken

We maken in de beveiligingswereld een slechte beurt met systemd. De beveiligingsfouten hierin zijn niet het probleem, maar de manier waarop de ontwikkelaars erop reageren…

Tijdens de Black Hat beveiligingsconferentie in Las Vegas werden traditiegetrouw weer de Pwnie Awards uitgereikt in diverse categorieën. Deze prijzen zetten excellente of juist incompetente personen in het domein van informatiebeveiliging in het zonnetje. Een van die incompetente personen die dit jaar met een Pwnie Award naar huis ging, was Lennart Poettering, de hoofdontwikkelaar van ons aller geliefde systemd. Hij ontving volkomen terecht de “Pwnie for Lamest Vendor Response”, die jaarlijks uitgereikt wordt aan de “vendor”, die het spectaculairst een beveiligingskwetsbaarheid heeft mishandeld.

Waaraan had Poettering die eer te danken? De nominatie vermeldt: “Waar je het adres van nullpointers opvraagt, of buiten je grenzen schrijft, of geen volledig gekwalificeerde domeinnamen ondersteunt, of rootprivileges geeft aan elke gebruiker van wie de naam met een cijfer begint, is er geen enkele kans dat het CVE-getal in de changelog of de commitboodschap vermeld wordt.” Het gaat om de issues 5998, 6225, 6214, 5144 en 6237 in de GitHub-repository van het project.

In al deze gevallen was het niet zozeer de fout zelf die beschamend was. Iedereen vergist zich weleens. Maar elke keer was het opvallend hoe afwijzend en wereldvreemd Poettering op rapportages van de kwetsbaarheden reageerde. Het kwam altijd op hetzelfde neer: dit is niet de fout van systemd…

Op de bug report voor fout 5998 (de null pointer dereferencing) antwoordde Ubuntu Security Lead Tyler Hicks dat hij een CVE voor de beveiligingsfout zou aanvragen bij MITRE. Poetterings antwoord? “Deze fout heeft zo’n lage impact dat ik niet inzie wat het voordeel van de bureaucratische inspanningen is… Bureaucratische inspanningen zijn oké als ze iemand helpen, maar je creëert gewoon ruis. En daarmee maak je de upstreamprojecten kwaad waarvan je eigenlijk de samenwerking wilt. Je hebt er nu zelf voor gezorgd dat mijn eigen interesse om je inspanningen te helpen nul is…”

En toen Mikhail Kasimov voorstelde dat de systemd-ontwikkelaars zelf CVE-nummers zouden aanvragen voor beveiligingskwetsbaarheden, die ze oplosten en die nummers ook in de git log zouden opnemen, antwoordde Poettering afwijzend. “Ik ben er vrij zeker van dat het niet onze taak als ontwikkelaars is om CVE-nummers aan te vragen voor elke bug, hoe klein ook, die we tegenkomen.” Waarna hij de discussie sloot.

Toen Christian Rebischke van het Arch Linux Security Team opmerkte dat de fix voor bug 6214 moeilijk te vinden is, omdat geen enkel issue op GitHub het erbij horende CVE-nummer CVE-2017-9445 vermeldt, antwoordde Poettering dat hij die CVE-informatie niet in de documentatie van systemd wilde. Hij had ergens wel een punt, maar ging totaal niet in op de heel zinnige redenen, die allerlei personen gaven om wel de CVE-nummers te vermelden. En wederom sloot hij de discussie.

Dan was er ook nog de fameuze 0day-fout (zie ook de rubriek “Focus op Veiligheid” in dit nummer van Linux Magazine), waarbij een gebruikersnaam die met een cijfer begint in een unit-bestand ervoor zorgde dat de service met rootrechten draait. Poetterings reactie? “Ik denk niet dat er iets in systemd te fixen is. Ik begrijp dat het vervelend is, maar de gebruikersnaam is duidelijk niet geldig.” Waarna nog een hele uitleg kwam over regels over geldige gebruikersnamen en hij de discussie sloot… Geen woord over het feit dat systemd een service als root startte, terwijl dat niet de bedoeling was!

Poetterings gedrag is een open source project onwaardig. En nu GNU/Linux meer en meer in systemd/Linux aan het veranderen is, straalt dat af op de hele Linux-gemeenschap. Ik hoop dat Poettering zijn lesje heeft geleerd en systemd volgend jaar in een heel andere categorie van de Pwnie Awards terechtkomt…