Menü
Avatar von Daelach
  • Daelach

mehr als 1000 Beiträge seit 11.05.2004

Re: Immer diese Scriptsprachen.

MetaCircularEvaluator schrieb am 16.04.2018 21:45:

Hä? Also soweit ich den Thread hier verfolge:

Daß ich eval erwähnt habe, war hier:

https://www.heise.de/forum/heise-Security/News-Kommentare/Drupalgeddon-2-Angreifer-attackieren-ungepatchte-Drupal-Webseiten/Re-Immer-diese-Scriptsprachen/posting-32219866/show/

Und da schrieb ich, Hervorhebung hinzugefügt:

Und um das noch weiterzuschlagen: was glaubst Du eigentlich, wieso bei Javascript inzwischen mit Content Security Policy auf unsafe eval geschossen wird?

Strukturell liegt dem ja dieselbe Problematik zugrunde. Ich hab da nur einen kleinen Bogen zu anderen Sprachen geschlagen. Deswegen auch die Erwähnung des NX-Bits bei C, um dem Vorposter deutlich zu machen, daß "die Programmierer sind schuld" keine akzeptable Lösung ist, und daß man dasselbe Problem anderswo inzwischen technisch angeht, wenigstens im Nachhinein.

Das war doch auf PHP und das aktuelle Drupal Problem bezogen?

Ja, die generelle Ausführung zu Daten und Strings, die ja beim konkreten PHP-Problem losging.

Nur das Zeug auf der Platte, oder das Zeug aus dem Netz, sind auch für einen Harvard Computer erst mal Daten. Um da irgendwas auszuführen, müssen diese Daten zu Code werden. Da führt einfach kein Weg dran vorbei.

Zustimmung. Dazu sollte es dann aber ein geordnetes Interface geben, das so etwas tut, und NUR dieses Interface. Im Beispiel mit Code auf der Platte wäre das der Loader des Betriebssystems - nicht jedoch die Anwendung in C, die das mit Buffer Overflow, Nop-Rutsche und Shellcode aus Versehen selber tut. Der Anwendung sollte das gar nicht erst möglich sein - und das geht auch, wenn man den Stack mit no-execute versieht. GCC unterstützt das zumindest.

Die Buffer Overflows sind dann immer noch ätzend, weil das Programm sich seine Daten zermarmelt und dann kein definiertes Verhalten mehr hat. Aber zumindest führt das nicht gleich zur Codeausführung, das ist ja auch schonmal was.

Um genau zu sein, ich wüsste z.B. nicht mal wozu R/W/X gut sein sollte. Man kann ja etwas schreiben (nur W), es dann validieren (nur R), und dann erst X hinzuschalten.

Naja, X enthält automatisch R, sonst kann der Code ja nicht laufen. Typisch sind RX für Code und RW für Daten als Kombinationen. RWX braucht man also, wenn man in einen Speicherbereich selber was reinschreiben und dann ausführen will - also genau die übliche unbeabsichtigte Sicherheitslücke.

Allerdings, wenn ein Controller sein Flash reprogrammiert, beispielsweise als Bootloader, der ein Firmware-Image umkopiert beim Update, dann geht das meist nicht, wenn er aus dem Flash läuft, das reprogrammiert werden soll, also muß der Code ins RAM kopiert und dann angesprungen werden. Manchmal muß man auch Code ins RAM kopieren, weil der aus dem Flash-ROM direkt ausgeführt wegen der Waitstates zu langsam wäre.

Das sind aber schon Lowlevel-Sonderfälle, und selbst in C-Programmierung ist das dermaßen die Ausnahme, daß man dafür keinen generellen Freibrief braucht, in der Anwendung irgendwas ausführbar irgendwohin zu werfen.

Eine "Configware" die eine Hardware beschreibt, die dann erst in der Lage ist ein konkretes Problem zu lösen, ist auch durchaus etwas ganz anderes wie heutige Software, imho.

Wahrscheinlich eher sowas wie deklarative Sprachen, wenn damit Logikbausteine anwendungsspezifisch reprogrammiert werden können.

Denn das Vorbild für solche Systeme ist nämlich selbst ein rekonfigurierbares System!

Das heißt nicht unbedingt etwas. Das Vorbild zum Fliegen war auch der Vogel, und mit den Flügeln schlagen hat sich nicht als effektive technische Lösung erwiesen. Aber Neuronetze leisten diese Rekonfigurierbarkeit ja auch, halt über die Gewichte. Die werden denn auch nicht über if-then-else-C-Sprachen abgearbeitet - das geht zwar, ist aber ineffektiv.

Bewerten
- +
Anzeige