Linus Torvalds hält Grsecurity für Müll

26.06.2017

In der Diskussion um die Stack-Clash-Sicherheitslücke hat sich Linus Torvalds zu Wort gemeldet.

Seit letzter Woche wird viel über die schon länger existierende Stack-Clash-Sicherheitslücke in Linux und anderen Unix-Systemen diskutiert, die darauf beruht, dass der im Speicher "nach unten" wachsende Stack und der Heap von Programmen kollidieren können. Dies sollte eigentlich eine sogenannte Stack Guard Page im Speicher verhindern, aber Security-Experten haben gezeigt, wie sich dieser Schutz umgehen und zur Ausführung von Code verwenden lässt. 

Schuld an der Misere sind bei Linux die Glibc und der Kernel, weshalb auf der Kernel-Mailingliste seither eine angeregte Diskussion stattfindet. Als einer der Entwickler wissen wollte, welchen Stack-Guard-Schutz das Grsecurity-Projekt einsetzte, meldete sich auch Linus Torvalds zu Wort und gab seine Meinung zu besten. Man solle sich nicht mit Grsecurity beschäftigen, da deren Ansatz immer nur gewesen sei, Sicherheit um der Sicherheit willen zu schaffen und sich nicht darum zu kümmern, was dabei alles kaputt gehe. Das ganze Projekt sei ein Witz und die Entwickler seien Clowns. Die Patches seien reiner Müll, so Torvalds in seiner Mail

Brad Spengler vom Grsecurity hatte sich davor in einem Blog-Beitrag über die Ignoranz der Kernel-Entwickler beschwert und den amateurhaften Umgang mit dem Stack-Problem kritisiert, den die Kernel-Entwickler über die Jahre gepflegt hätten. Irgendwann hätte dann Torvalds in einer Nacht-und-Nebel-Aktion einen Patch geschrieben, der das Problem aber gar nicht gelöst hätte. 

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Linus Torvalds regt sich über Intel auf

Der Kernel-Chef ist sehr unzufrieden mit der Art, wie Intel das Spectre-Problem auf Linux zu lösen versucht. 

Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023