1. Foren
  2. Kommentare
  3. OpenSource-Forum
  4. Alle Kommentare zum Artikel
  5. › Linux: Kernel-Hacker müssen…

Sicherheit ist bei sowas wie einem OS nicht moeglich!

  1. Thema

Neues Thema


  1. Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: kim3000 19.06.15 - 15:52

    Wieder mal ein schoenes Beispiel wo keiner der aktuellen Entwickler einen Plan hat, was bestimmter Code ueberhaupt macht.

    Das heisst, es koennen ueble Bugs/Sicherheitsloecher oder gar Hintertueren da drinstecken. Und dass ist dann in JEDEM Linux Kernel seit 1989.

    Als NSA und Co. scheint es mir sehr billig zu sein, in solchem Code nach Sicherheitsluecken zu suchen oder sie gleich selbst durch Sockenpuppen einzuweihen. Wenn man dadurch bei mehreren Milliarden Geraeten auf einmal eine Hintertuer kriegt sind das schon extreme Anstrengugen wert.

    Ist schon irgendwie ernuechternd wenn man das alles so liest. Vor allem, da es sich ja um Open Source handelt usw.
    Bei Assembler ist es natuerlich sehr extrem, aber auch bei C hat man oft Code den kein Schwein mehr begreift. Lustigerweise bleibt solche Code dann oft Jahre und Jahrzehnte unangetastet. Eben weil ihn keiner versteht :)

    Irgendwie sollten wir mal fundamental aendern wie wir Code schreiben. Vor allem Code fuer Betriebssysteme. Vielleicht muss da eine eigene Sprache samt Toolchain her, die einen komplett anderen Fokus hat als alles Sprachen/Toolchains bisher. Alle bisher existierenden Ansaetze und Konzepte scheinen mir jedenfalls mehr als ungeeignet.

  2. Re: Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: spiderbit 19.06.15 - 16:21

    Literate Programming waere solch ein ansatz, allerdiengs erleichtert das auch nur dokumentation zu schreiben das tun muss man trotzdem und kann das natuerlich auch ohne tun.

  3. Re: Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: theonlyone 19.06.15 - 16:28

    Das "Problem" hier ist schlichtweg Legacy code, veraltet und unleserlich.


    Den existierenden Code einfach neu zuschreiben und entsprechende Tests und Dokumentation dazu , schon hat man das "Problem" gelöst.

    Nur damit man das machen kann, muss man erstmal exzessiv testen was der aktuelle Legacy Code tut und welche Features man wirklich braucht.

    Die "Hacks" rauszupoppeln und durch stabilen Code zu ersetzen ist eben durchaus aufwendig, gerade bei extremen Low-Level Code schreibt ja meist genau 1 Person diesen Code und den hat auch keiner gegen gelesen oder sonstwie angeschaut.


    Da braucht es keine neue Sprache, den am Ende wird praktisch alles in Assembler Code umgewandelt.

  4. Re: Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: spiderbit 19.06.15 - 16:33

    Es geht nicht um sprache. Orgmode mit babel unterstuetzt das und kann code von verschiedenen sprachen embedden und dann auch "tangeln" aber schon ueberschriften die auf und zu klappbar sind machen sowas sehr viel uebersichtlicher.

  5. Re: Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: boxcarhobo 19.06.15 - 19:28

    kim3000 schrieb:
    --------------------------------------------------------------------------------
    > Wieder mal ein schoenes Beispiel wo keiner der aktuellen Entwickler einen
    > Plan hat, was bestimmter Code ueberhaupt macht.
    >
    > Das heisst, es koennen ueble Bugs/Sicherheitsloecher oder gar Hintertueren
    > da drinstecken. Und dass ist dann in JEDEM Linux Kernel seit 1989.

    Linux gibt es erst seit Mitte '91. Ja, das ist ein Unterschied.

  6. Re: Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: FreiGeistler 19.06.15 - 21:03

    Code::Blocks kann direkt aus C /C++ -Code Lassy-Schneidermann-Diagramme Generieren.
    Wäre das der Übersicht dienlich?

  7. Re: Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: EWCH 20.06.15 - 10:07

    Das kann man so pauschal nicht sagen. Nimm z.B. ein Software RAID + Block device driver + controller driver.

    Auf Anwendungsebene gibt es dann einen einfachen system call "fwrite" der einfach einen Block an Daten auf die Festplatte sichern moechte. Da die Laenge bekannt ist kann die Gueltigkeit leicht ueberprueft werden. Dannach wird es komplex mit user/system kontext switch, raid6 Checksummen, Ansteuerung der eventuell verschiedenen SAS oder SATA Controller ...
    Aber es fehlt ein Angriffspunkt. Egal welche Fehler z.B. im Controller Treiber stecken, ich kann diese nicht von aussen ausloesen weil der inhalt des Datenblocks voellig irrelevant ist.
    Sicherheitsluecken entstehen ueblicherweise wenn ein Program mit ungueltigen Eingaben (z.B. falschen Laengenangaben) nicht zurecht kommt. Das waere hier nicht der Fall.
    Eine Software kann noch so fehlerbehaftet sein, wenn sie immer genau das gleiche tut und das gut durchgetestet ist dann laeuft sie einwandfrei.

  8. Re: Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: cpt.dirk 21.06.15 - 04:32

    > Aber es fehlt ein Angriffspunkt. Egal welche Fehler z.B. im Controller
    > Treiber stecken, ich kann diese nicht von aussen ausloesen weil der inhalt
    > des Datenblocks voellig irrelevant ist.
    > Sicherheitsluecken entstehen ueblicherweise wenn ein Program mit
    > ungueltigen Eingaben (z.B. falschen Laengenangaben) nicht zurecht kommt.
    > Das waere hier nicht der Fall.
    > Eine Software kann noch so fehlerbehaftet sein, wenn sie immer genau das
    > gleiche tut und das gut durchgetestet ist dann laeuft sie einwandfrei.

    Außer, der besagte, kryptische Code des Treibers beinhaltet eine Funktion, die bei bestimmten Keywords im Datenblock eine Aktion auslöst oder den folgenden Teil als ausführbaren Code annimmt - da Treiber ja meist mit erhöhten Rechten laufen?
    So etwas gibt es ja auch auf Hardware-Ebene, z.B. die "Magic Bytes", welche bei Wakeup on LAN einen Rechner via Netzwerk "aufwecken".

    Und Tests auf Blackbox-Basis werden solche Hidden Features auch kaum aufdecken, da hier i.d.R. positive und negative Standardszenarien abgetestet werden; dazu müsste schon der Code selbst durchforstet und verstanden werden.

  9. Re: Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: SchreibenderLeser 21.06.15 - 09:56

    kim3000 schrieb:
    --------------------------------------------------------------------------------
    > Das heisst, es koennen ueble Bugs/Sicherheitsloecher oder gar Hintertueren
    > da drinstecken. Und dass ist dann in JEDEM Linux Kernel seit 1989.

    Ich hätte meine Zweifel daran, dass zum damaligen Zeitpunkt ein Geheimdienst schon ahnen konnte, welche Geschichte Linux noch bevorsteht.
    Insofern sollte das relativ sicher sein. Aber vielleicht hat sich jemand wirklich eine Hintertür eingebaut, eventuell anfangs nur zum Spaß, die dann später, als das OS bedeutender wurde, eine immer größere Rolle spielte.

    > Bei Assembler ist es natuerlich sehr extrem, aber auch bei C hat man oft
    > Code den kein Schwein mehr begreift. Lustigerweise bleibt solche Code dann
    > oft Jahre und Jahrzehnte unangetastet. Eben weil ihn keiner versteht :)

    Ist ja nicht nur da so. ;-)
    Mangelnde Dokumentation scheint ja ein großes Risiko für ein Softwareprojekt zu sein.

  10. Re: Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: cpt.dirk 29.06.15 - 23:59

    SchreibenderLeser schrieb:
    --------------------------------------------------------------------------------
    > kim3000 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das heisst, es koennen ueble Bugs/Sicherheitsloecher oder gar
    > Hintertueren
    > > da drinstecken. Und dass ist dann in JEDEM Linux Kernel seit 1989.
    >
    > Ich hätte meine Zweifel daran, dass zum damaligen Zeitpunkt ein
    > Geheimdienst schon ahnen konnte, welche Geschichte Linux noch bevorsteht.
    > Insofern sollte das relativ sicher sein. Aber vielleicht hat sich jemand
    > wirklich eine Hintertür eingebaut, eventuell anfangs nur zum Spaß, die dann
    > später, als das OS bedeutender wurde, eine immer größere Rolle spielte.

    Sofern der/die Compiler, mit dem Linux oder Windows (oder ein sonstiges sicherheitsrelevantes Programm) compiliert wurde, selbst Schadcode enthalten sollte/n - u. U. seit vielen Jahren - wäre das denkbar:
    http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a

    Man muss das Problem auch nicht am OS festmachen: ein proprietäres BIOS mit Netzwerk-Stack und die dazugehörige vPRO / DASH Hardware steckt heute in jedem modernen Rechnenschieber. Und das hat auch eine Historie von über 10 Jahren.

  11. Re: Sicherheit ist bei sowas wie einem OS nicht moeglich!

    Autor: spiderbit 30.06.15 - 03:02

    naja man kann aber seine ansprueche stueck fuer stueck erhoehen und nicht umgekehrt, statt der boiling frog zwinge ich lieber die anbieter das wasser nach und nach runter zu kuehlen bis es angenehm wird.

    Bei normalen Handies ists btw der Modemprozessor der ein proprietaeres OS hat und zugriff auf den ram und alles hat. Aber ja auch bios ist ein problem leider nicht das einzige. Das Librem Notebook benutzt z.B. Coreboot aber natuerlich brauchts dafuer von intel nen blob, den sie nicht raus ruecken, daher ist fuer mich Intel zumindest bei der Prozessorreihe gegessen, gut finde auch das librem13 noch zu gross und tastatur und kein mausshit gefaellt mir auch nicht. :)

    Mach da auch abstriche ohne Ende hab nen Windows spielerechner nur hab ich den eben gesondert von meinem arbeitssystem wo ich alles andere mache.

    Amd wird daher auf lange sicht wieder die alternative, wobei die natuerilch auch viel mist machen aber weniger wie Intel.

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT Workplace Administrator (w/m/d)
    RHI Magnesita GmbH, Mainzlar bei Staufenberg
  2. Systemingenieur*in für den Bereich IT-Security (w/m/d)
    Hensoldt, Ulm
  3. Entwicklungsingenieur Bildverarbeitung Python/C/C++ (m/w/d)
    pro-beam GmbH & Co. KGaA, Gilching (bei München),
  4. Anwendungsbetreuer*in Campus Management System (m/w/d)
    Humboldt-Universität zu Berlin, Berlin

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


Tesla Model 3: Die Mechanik ist das Problem
Tesla Model 3
Die Mechanik ist das Problem

Manche Probleme zeigen sich beim Elektroauto erst mit der Zeit. Beispielsweise, wenn Wasser den Bauteilen zusetzt. Bericht eines langjährigen Tesla-Fahrers.
Von Dirk Kunde

  1. Beschwerden über Übertreibungen Tesla senkt in aller Stille die Reichweitenschätzungen
  2. Nur Fremdmarken Kostenlose Ladeaktion bei Tesla
  3. Elektroautos Tesla übertrifft Auslieferungsrekord im Jahr 2023

Science-Fiction-Film Enemy: Liebe in Zeiten der Übertechnologisierung
Science-Fiction-Film Enemy
Liebe in Zeiten der Übertechnologisierung

Wenn man einen Menschen durch ein Roboter-Duplikat ersetzt, was passiert dann mit demjenigen, der ihn liebt? Interessante Frage, leider macht der Film einige Denkfehler.
Eine Rezension von Peter Osteried

  1. Doctor Who Christmas Special eröffnet ein neues Mysterium
  2. Lola Könnte die Vergangenheit unsere Gegenwart verhindern?
  3. Rebel Moon Director's Cut soll "gänzlich anderer Film" sein

Softwareentwicklung: Scrum-Abenteuer auf der grünen Wiese
Softwareentwicklung
Scrum-Abenteuer auf der grünen Wiese

Wie wir anderthalb Jahre lang im Greenfield-Projekt Scrum versuchten, über Bord warfen und völlig deformierten - um dann zu erkennen, dass wir es lebten.
Ein Erfahrungsbericht von Rene Koch

  1. Scrum of Scrums Ein leichtgewichtiges agiles Framework