1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Glibc: Ein Geist gefährdet Linux…

Heap Overflow

  1. Thema

Neues Thema Ansicht wechseln


  1. Heap Overflow

    Autor: carsti 27.01.15 - 18:55

    Heap Overflow :(

    Die einzige Loesung ist die Menge an nativem Code bei einem OS mit jedem Release zu verkleinern.

    Es MUSS eine basis aus C-Code geben - keine Frage. Aber diese Basis sollte so klein wie moeglich sein und permanent ge-reviewed werden. Bei allem sonstigen OS-Code und auch Anwendungs-Code sollte nur "managed" Code zugelassen werden! Keine Heap Overflows oder sonstigen Spaesse moeglich.

    Ich weiss. Ich bin der Anti-Christ.

  2. Re: Heap Overflow

    Autor: gadthrawn 27.01.15 - 19:55

    Welcome to Singularity. Oder zu Cosmas - da ist OS basteln echt einfach.

  3. Re: Heap Overflow

    Autor: grorg 27.01.15 - 20:45

    Rust könnte das lösen.

  4. Re: Heap Overflow

    Autor: pythoneer 27.01.15 - 20:50

    grorg schrieb:
    --------------------------------------------------------------------------------
    > Rust könnte das lösen.

    +1 Rust
    -1 Managed Code

  5. Re: Heap Overflow

    Autor: QDOS 27.01.15 - 23:55

    grorg schrieb:
    --------------------------------------------------------------------------------
    > Rust könnte das lösen.
    Jede Sprache die es ermöglicht einen Buffer nicht fixer größer zu verwenden, würde das lösen…

  6. Re: Heap Overflow

    Autor: zilti 28.01.15 - 06:15

    Jau, lasst den Sprachenkampf beginnen! Ich bin für Scheme!
    Übrigens können auch managed-Sprachen solche Fehler verursachen, bloss i.d.R. mit schlimmeren Auswirkungen...

  7. Re: Heap Overflow

    Autor: elgooG 28.01.15 - 10:23

    gadthrawn schrieb:
    --------------------------------------------------------------------------------
    > Welcome to Singularity. Oder zu Cosmas - da ist OS basteln echt einfach.

    Um genau zu sein gibt es bei Singularity keinen sicherheitsrelevanten nativen Code. Ein paar Zeilen Assembler und der Rest ist praktisch nur mehr managed.

    Natürlich ist das keine Lösung für alle Sicherheitslücken. Es würde wohl auch schon reichen, wenn alle sicherheitsrelevanten Anwendungen einen automatisch verwalteten Speicher verwenden würden. Die wenigsten Anwendungen profitieren überhaupt von nativen Code.

    Kann Spuren von persönlichen Meinungen, Sarkasmus und Erdnüssen enthalten. Ausdrucke nicht für den Verzehr geeignet. Ungelesen mindestens haltbar bis: siehe Rückseite

  8. Re: Heap Overflow

    Autor: carsti 29.01.15 - 19:16

    zilti schrieb:
    --------------------------------------------------------------------------------
    > Jau, lasst den Sprachenkampf beginnen! Ich bin für Scheme!
    > Übrigens können auch managed-Sprachen solche Fehler verursachen, bloss
    > i.d.R. mit schlimmeren Auswirkungen...

    Geb halt mal ein explizites Beispiel.

  9. Re: Heap Overflow

    Autor: carsti 29.01.15 - 19:20

    elgooG schrieb:
    --------------------------------------------------------------------------------
    > gadthrawn schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Welcome to Singularity. Oder zu Cosmas - da ist OS basteln echt einfach.
    >
    > Um genau zu sein gibt es bei Singularity keinen sicherheitsrelevanten
    > nativen Code. Ein paar Zeilen Assembler und der Rest ist praktisch nur mehr
    > managed.
    >
    > Natürlich ist das keine Lösung für alle Sicherheitslücken. Es würde wohl
    > auch schon reichen, wenn alle sicherheitsrelevanten Anwendungen einen
    > automatisch verwalteten Speicher verwenden würden. Die wenigsten
    > Anwendungen profitieren überhaupt von nativen Code.

    Genau. Du sprichst mir aus der Seele. Mir klappt oft die Kinnlade runter fuer was fuer Programme nativer Code verwendet wird. Das sollte eine reine Nischenloesung sein! Absolut unnoetig sowas.

    Wenn alle Entwicklungs-Resourcen nicht endlich waeren waer das ja alles kein Problem. Aber ich sehe bei solchen Anwendungen dann immer ein haufen Baustellen weil einfach die Zeit fehlt.
    Das tollste finde ich auch oft, dass es dann nicht fuer eine Parallelisierung der CPU-intensivsten Codebereiche gelangt hat. Damit ist dann der native Code deutlich langsamer. Wobei schon bei Single-Thread Performance native nicht zwangsweise schneller sein muss als die nicht-native Konkurrenz.

  10. Re: Heap Overflow

    Autor: zilti 30.01.15 - 01:22

    Auch in .NET (an dieser Stelle Gruss an Singularity), der JVM und bei JavaScript-Implementationen gab es schon ganz üble Sicherheitslücken, die zum Ausführen von beliebigem Code missbraucht werden können. Bzw. gibt es ja immer wieder einmal.

    (Zudem, nativer Code ist nicht immer komplett ersetzbar, es gibt nicht nur Performancegründe, auf nativen Code zu setzen, aber das nur noch so am Rande)

  11. Re: Heap Overflow

    Autor: carsti 31.01.15 - 00:59

    Also theoretisch nicht ersetzbar oder nicht ersetzbar weil zuviel Aufwand? Zum Beispiel haette auch keiner daran gedacht mal eben Glibc in Linux durch was anderes zu ersetzen weil zu aufwaendig. Google hats dann aber doch gemacht.

    Und ja, zugegebenermassen gibt es Teile die auch theoretisch nicht ersetzt werden koennen. Wenn du meinen initialen Post liest meine ich ja auch, dass es nicht komplett ersetzt sondern minimiert werden sollte.
    Singularity zeigt, dass wenig geht. Koennte sogar noch weniger sein.

    Die Sicherheitsluecken von denen du in .NET, Java, JavaScript usw. sprichst sind uebrigens bei vielen schwerwiegenden Fehlern eben doch im nativen Unterbau zu finden. Uebrigens ist der native Unterbau bei .NET und Java sehr hoch! Beispielsweise ist Apache Harmony da sehr viel zurueckhaltender gewesen als Sun/Oracle.

  1. Thema

Neues Thema Ansicht wechseln


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. Marc Cain GmbH, Bodelshausen
  2. operational services GmbH & Co. KG, verschiedene Standorte
  3. Hornbach-Baumarkt-AG, Bornheim bei Landau
  4. Deutsche Bundesbank, Frankfurt am Main

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. Gigabyte Radeon RX 6800 Gaming OC 16G für 878,87€)
  2. (u. a. MSI GeForce RTX 3070 VENTUS 2X 8G OC für 749€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Elektromobilität 2020/21: Nur Tesla legte in der Krise zu
Elektromobilität 2020/21
Nur Tesla legte in der Krise zu

Für die Autoindustrie war 2020 ein hartes Jahr. Wer im Homeoffice arbeitet und auch sonst zu Hause bleibt, braucht kein neues Auto. Doch in einem schwierigen Umfeld entwickelten sich die E-Auto-Verkäufe sehr gut.
Eine Analyse von Dirk Kunde

  1. Elektromobilität Akkupreise fallen auf Rekord von 66 Euro/kWh
  2. Transporter Mercedes eSprinter bekommt neue Elektroplattform
  3. Aptera Günstige Elektrofahrzeuge vorbestellbar

Data-Mining: Wertvolle Informationen aus Datenhaufen ziehen
Data-Mining
Wertvolle Informationen aus Datenhaufen ziehen

Betreiber von Onlineshops wollen wissen, was sich verkauft und was nicht. Mit Data-Mining lassen sich aus den gesammelten Daten über Kunden solche und andere nützliche Informationen ziehen. Es birgt aber auch Risiken.
Von Boris Mayer


    IT-Security outsourcen: Besser als gar keine Sicherheit
    IT-Security outsourcen
    Besser als gar keine Sicherheit

    Security as a Service (SECaaS) verspricht ein Höchstmaß an Sicherheit. Das Auslagern eines so heiklen Bereichs birgt jedoch auch Risiken.
    Von Boris Mayer

    1. Joe Biden Stellenanzeige im Quellcode von Whitehouse.gov versteckt
    2. Sturm auf Kapitol Pelosis Laptop sollte Russland angeboten werden
    3. Malware Offenbar Ermittlungen gegen Jetbrains nach Solarwinds-Hack