Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Glibc: Fehlerhaftes Null-Byte führt…

Ich glaub, es hackt ...

  1. Thema

Neues Thema Ansicht wechseln


  1. Ich glaub, es hackt ...

    Autor: Linuxschaden 26.08.14 - 11:39

    ... und zwar im wahrsten Sinne des Wortes!
    Da finden die Leute von Project Zero einen Buffer Overflow, und die Entwickler der Glibc diskutieren erst mal rum, ob der sich überhaupt ausnutzen lässt?!

    "Zunächst hatte es Diskussionen darüber gegeben, ob sich das Problem tatsächlich ausnutzen lässt."

    Hallo?! Muss ich ernsthaft mal hierauf verweisen? [https://blog.fefe.de/?ts=adbb8f5f]

    "Die Perspektive von Entwicklern auf Bugs müsste sein: You file it, we fix it. Und zwar sofort. Keine Rückfragen, kein Gezeter, kein Prokrastinieren. Alle Bugs werden sofort gefixt."

    Auf solche Entwickler schiebe ich Hass. Einfach nur Hass.

    EDIT: "Hmm. How likely is that? It overflows in to malloc metadata, and the
    glibc malloc hardening should catch that these days."

    Florian Weimer ... den sollte man auch mal im Auge behalten.



    2 mal bearbeitet, zuletzt am 26.08.14 11:41 durch Linuxschaden.

  2. Re: Ich glaub, es hackt ...

    Autor: Wander 26.08.14 - 11:49

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > ... und zwar im wahrsten Sinne des Wortes!
    > Da finden die Leute von Project Zero einen Buffer Overflow, und die
    > Entwickler der Glibc diskutieren erst mal rum, ob der sich überhaupt
    > ausnutzen lässt?!
    >
    > "Zunächst hatte es Diskussionen darüber gegeben, ob sich das Problem
    > tatsächlich ausnutzen lässt."
    >
    > Hallo?! Muss ich ernsthaft mal hierauf verweisen?
    >
    > "Die Perspektive von Entwicklern auf Bugs müsste sein: You file it, we fix
    > it. Und zwar sofort. Keine Rückfragen, kein Gezeter, kein Prokrastinieren.
    > Alle Bugs werden sofort gefixt."
    >
    > Auf solche Entwickler schiebe ich Hass. Einfach nur Hass.
    >
    > EDIT: "Hmm. How likely is that? It overflows in to malloc metadata, and
    > the
    > glibc malloc hardening should catch that these days."
    >
    > Florian Weimer ... den sollte man auch mal im Auge behalten.

    Ich habe mir die Diskussion der Entwickler nicht angesehen, aber ich halte es für vollkommen legitim und sinnvoll die Dringlichkeit eines Fehlers zu bestimmen. Man hat nicht unendlich viele Resourcen und demzufolge arbeitet man in der Regel zunächst die kritischen Bugs ab - jedoch muss man diese erst einmal als solche identifizieren und deshalb gibt es solche Diskussionen.

  3. Re: Ich glaub, es hackt ...

    Autor: marsie 26.08.14 - 11:53

    Naja, aber wenn der Aufwand, eine Mail an die Mailinglist zu schreiben höher ist, als den Bug zu fixen, dann läuft was falsch. Ich kenne mich nicht mit dem Fehler aus, aber es hört sich nach einer Kleinigkeit an. :-)

  4. Re: Ich glaub, es hackt ...

    Autor: Wander 26.08.14 - 11:55

    marsie schrieb:
    --------------------------------------------------------------------------------
    > Naja, aber wenn der Aufwand, eine Mail an die Mailinglist zu schreiben
    > höher ist, als den Bug zu fixen, dann läuft was falsch. Ich kenne mich
    > nicht mit dem Fehler aus, aber es hört sich nach einer Kleinigkeit an. :-)

    Das stimmt natürlich.

  5. Re: Ich glaub, es hackt ...

    Autor: Linuxschaden 26.08.14 - 11:56

    Wander schrieb:
    --------------------------------------------------------------------------------
    > Ich habe mir die Diskussion der Entwickler nicht angesehen, aber ich halte
    > es für vollkommen legitim und sinnvoll die Dringlichkeit eines Fehlers zu
    > bestimmen. Man hat nicht unendlich viele Resourcen und demzufolge arbeitet
    > man in der Regel zunächst die kritischen Bugs ab - jedoch muss man diese
    > erst einmal als solche identifizieren und deshalb gibt es solche
    > Diskussionen.

    Hättest du das nur getan, dann hättest du nämlich gesehen, dass es nur ein Off-By-One-Fehler war bei der Reservierung des Speichers:

    "it does + 3 instead of + 3 + 1 in the allocation."

    Kurz: zwei weitere Zeichen hätten den Bug verhindert. Da sind vielleicht 5 Minuten Manneskraft hinter, mehr nicht. Mit "Klassifizierung der Dringlichkeit" hat das meines Erachtens nichts zu tun, das war Asscovering.

    Allein schon der Begriff "Buffer-Overflow" reicht in der Regel aus, um Programmierern klarzumachen, dass das (in der Regel, es gibt Ausnahmen, will ich nicht bestreiten) eher ein Zählfehler und daher leicht zu fixen ist.

  6. Re: Ich glaub, es hackt ...

    Autor: Wander 26.08.14 - 12:02

    Wie gesagt ich habe mir die Diskussion und den Fehler nicht angesehen, es ging mir ja auch primär nur darum auf den fragwürdigen Nutzen des von dir zitierten Ratschlags ("Alle Bugs werden sofort gefixt") hinzuweisen. Es ist meiner Ansicht nach eben nicht immer sinnvoll Fehler sofort zu beheben.

  7. Re: Ich glaub, es hackt ...

    Autor: Linuxschaden 26.08.14 - 12:12

    Wander schrieb:
    --------------------------------------------------------------------------------
    > Wie gesagt ich habe mir die Diskussion und den Fehler nicht angesehen, es
    > ging mir ja auch primär nur darum auf den fragwürdigen Nutzen des von dir
    > zitierten Ratschlags ("Alle Bugs werden sofort gefixt") hinzuweisen. Es ist
    > meiner Ansicht nach eben nicht immer sinnvoll Fehler sofort zu beheben.

    Gut, formulieren wir es anders:

    Wenn ein bestimmter Codeblock fundamental kaputt ist und nur durch Beten, viel Klebeband und Compilermagie zusammengehalten wird, und es tatsächlich länger dauert, diesen zu fixen - gut, OK, dauert es länger. Er muss zwar auch gefixt werden, so bald als möglich, aber bei steigender Komplexität der Software dauert das Schreiben dieser auch länger.

    Aber das? Sorry, da fehlen mir die Worte.
    Außerdem war das Zitat von Fefe auf den Heartbleed-Bug bezogen, wo Seggelmann auch das Prüfen der am Socket angekommenen Bytes "vergessen" hat. Hier gab es keine Diskussion vorher, stimmt - aber OpenSSL ist ein zentrales Stück Sicherheitssoftware, und bei I/O (egal ob Netzwerk oder Benutzereingaben) den ankommenden Daten einfach mal zu vertrauen . wir wissen seit 20 Jahren, dass das in die Hose geht.

    Was ich sagen will ist: Weimer hat nicht versucht, den Fehler sofort zu fixen, sondern seinen Hintern - oder den seiner Kollegen - zu bedecken. Dieser Fehler war nicht komplex, er war leicht zu fixen, und doch hat er es nicht getan (oder hat dies nicht in die Wege leiten lassen). Und das geht nicht.

  8. Re: Ich glaub, es hackt ...

    Autor: Wander 26.08.14 - 12:23

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > [...]
    >
    > Was ich sagen will ist: Weimer hat nicht versucht, den Fehler sofort zu
    > fixen, sondern seinen Hintern - oder den seiner Kollegen - zu bedecken.
    > Dieser Fehler war nicht komplex, er war leicht zu fixen, und doch hat er es
    > nicht getan (oder hat dies nicht in die Wege leiten lassen). Und das geht
    > nicht.

    Das ist natürlich richtig, wenn schon absehbar ist, dass die Diskussion mehr Zeit veranschlagt als das Beheben des Fehlers (was hier scheinbar ja der Fall ist) dann macht die Diskussion auch keinen Sinn.

  9. Re: Ich glaub, es hackt ...

    Autor: gboos 26.08.14 - 13:00

    Ich wuerde @Linuxschaden gerne zustimmen. Wer einen Bug "produziert" sollte nicht auch noch darueber entscheiden ob er kritisch ist oder nicht. Das waere ein bisschen das selbe wenn ich einen Unfall produziere und entscheiden darf wer Schuld hat.

    So wie das aussieht, waere der Bug schnell zu fixen gewesen. Bugs passieren, aber ich habe es auch lieber, dass Bugs "sofort" behoben werden wenn sie entdeckt sind, anstatt sie zu klassifizieren. Denn ein Fehler zieht manchmal einen anderen Fehler nach sich ! Man muss sich das nur selbst eingestehen bzw. eingestehen koennen/wollen.

  10. Re: Ich glaub, es hackt ...

    Autor: bongj 26.08.14 - 13:20

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > ... und zwar im wahrsten Sinne des Wortes!
    > Da finden die Leute von Project Zero einen Buffer Overflow, und die
    > Entwickler der Glibc diskutieren erst mal rum, ob der sich überhaupt
    > ausnutzen lässt?!
    >
    > "Zunächst hatte es Diskussionen darüber gegeben, ob sich das Problem
    > tatsächlich ausnutzen lässt."
    >
    > Hallo?! Muss ich ernsthaft mal hierauf verweisen?
    >
    > "Die Perspektive von Entwicklern auf Bugs müsste sein: You file it, we fix
    > it. Und zwar sofort. Keine Rückfragen, kein Gezeter, kein Prokrastinieren.
    > Alle Bugs werden sofort gefixt."
    >
    > Auf solche Entwickler schiebe ich Hass. Einfach nur Hass.
    >
    > EDIT: "Hmm. How likely is that? It overflows in to malloc metadata, and
    > the
    > glibc malloc hardening should catch that these days."
    >
    > Florian Weimer ... den sollte man auch mal im Auge behalten.

    Gut führst du kein SW-Unternehmen, denn das wäre längst pleite. :-) In einer idealen Welt (oder im Rahmen eines Studentenprojekts) mag deine Aussage stimmen - in der Relität sieht das leider anderst aus. Es gibt etliche Rahmenbedinungen (Ressourcen, Technologien, Zeit, existierende Schnittstellen, Kundenwünsche, Architekturvorgaben, Budgetvorgaben, ...) welche die SW Entwicklung beinflussen. Da hat der Entwickler in der Regel wenig zu melden.

    Aber du würdest natürlich heldenfhaft Überstunden schieben, um deine persönliche "Vision Zero" zu verwirklichen, klar doch.

  11. Re: Ich glaub, es hackt ...

    Autor: Zeitvertreib 26.08.14 - 13:24

    Das ist aber mal wieder ein falscher Autovergleich. Im vorliegenden Beispiel entscheidet keiner über die Schuld. Für die interessiert sich nur die Judikative und Kleingeister im Allgemeinen. Was hier entschieden wird ist ob der Unfallverursacher seinen Schaden repariert oder damit weiterfährt. Und das sollte offensichtlich der Entwickler selbst entscheiden können da er den Code am Besten kennt. Wenn man ihm die Fähigkeit abspricht Fehler als kritisch oder unkritisch einzustufen sollte man sich viel eher Gedanken machen warum man diesen Entwickler überhaupt im Team hat. Natürlich wird das bei komplexer Software schwieriger da dort immer mehrere Ebenen betroffen sind und somit auch mehrere Leute ihre Meinung beitragen.

    Grüße

  12. Re: Ich glaub, es hackt ...

    Autor: tomate.salat.inc 26.08.14 - 13:31

    Warum glaubst du Klassifiziert man Bugs? Richtig, die Entwickler sitzen nicht nur da und drehen Däumchen bis einmal die Woche ein Bug reinkommt - nein die sind beschäftigt. Auch wenn eine Sache in 5 Minuten erledigt sein könnte, kann es ewig dauern bis die behoben wird - weil anderes wichtiger ist und länger dauern kann. Jetzt kommt natürlich: "das könnte man doch zwischenrein schieben". Hier gilt aber die Devise 'Kleinvieh macht auch mist' (selbst schon erlebt: dadurch können Monate ins Land ziehen!) und wenn man immer wieder was zwischen rein schiebt, werden Arbeiten an kritischen Stellen nicht fertig. Das einzige, wofür man seine aktuelle arbeit unterbrechen sollte - sind Fehler die eine höhere Priorität haben. Alles andere steht hinten dran.

  13. Re: Ich glaub, es hackt ...

    Autor: Linuxschaden 26.08.14 - 13:38

    bongj schrieb:
    --------------------------------------------------------------------------------
    > Gut führst du kein SW-Unternehmen, denn das wäre längst pleite. :-) In
    > einer idealen Welt (oder im Rahmen eines Studentenprojekts) mag deine
    > Aussage stimmen - in der Relität sieht das leider anderst aus. Es gibt
    > etliche Rahmenbedinungen (Ressourcen, Technologien, Zeit, existierende
    > Schnittstellen, Kundenwünsche, Architekturvorgaben, Budgetvorgaben, ...)
    > welche die SW Entwicklung beinflussen. Da hat der Entwickler in der Regel
    > wenig zu melden.

    Ich habe während meiner Ausbildung immer wieder eingebläut bekommen, dass ich meinen Code länger testen soll, als ich gebraucht habe, ihn zu schreiben. Es kann sein, dass dies eine Ausnahme unter allen anderen Firmen war, aber das habe ich nun mal gelernt. Es kann gut sein, dass es woanders anders zugeht - dessen bin ich sogar sicher - aber das habe ich halt noch nicht kennengelernt. Aber ich bin noch jung, wer weiß, was auf mich zukommt. :)
    Wobei, schau dir mal oben an, was ich über die Komplexität des Fehlers geschrieben habe.

    > Aber du würdest natürlich heldenfhaft Überstunden schieben, um deine
    > persönliche "Vision Zero" zu verwirklichen, klar doch.

    Bei eigenen OSS-Projekten würde ich das machen, klar. Da bin ich aber auch der Chef. :)
    An Weimers Stelle hätte ich das mit dem entsprechenden Entwickler und/oder mit dem Projektleiter besprochen. Wenn die mir gesagt hätten, dass das nicht gefixt wird, hätte ich auf "höhere Stellen" verwiesen, und das Thema wäre ebenfalls abgehakt. Aber doch nicht mit einem Verweis auf Unwahrscheinlichkeit abgetan. So leicht kommt der mir nicht davon.

    Das schöne ist noch, er hat die Verantwortung dann noch auf andere (sprich die Maintainer der jeweiligen C-Laufzeitumgebung, die das malloc zur Verfügung stellt) geschoben. Frei nach "also wenn deren malloc schon so beschissen ist, dass die ihre Metadaten nicht auf Korruption prüfen - also, das ist ja wie einen Canary nicht zu überprüfen". Blöd nur, dass glibc selbst das malloc zur Verfügung stellt. :)

    Insofern ist dieser Fehler nur das Symptom eines schwerwiegenderen Fehlers - den man aber leicht hätte verhindern können, indem man gar nicht erst zu wenig Speicher reserviert.

    tomate.salat.inc schrieb:
    --------------------------------------------------------------------------------
    > Warum glaubst du Klassifiziert man Bugs? Richtig, die Entwickler sitzen
    > nicht nur da und drehen Däumchen bis einmal die Woche ein Bug reinkommt -
    > nein die sind beschäftigt. Auch wenn eine Sache in 5 Minuten erledigt sein
    > könnte, kann es ewig dauern bis die behoben wird - weil anderes wichtiger
    > ist und länger dauern kann. Jetzt kommt natürlich: "das könnte man doch
    > zwischenrein schieben". Hier gilt aber die Devise 'Kleinvieh macht auch
    > mist' (selbst schon erlebt: dadurch können Monate ins Land ziehen!) und
    > wenn man immer wieder was zwischen rein schiebt, werden Arbeiten an
    > kritischen Stellen nicht fertig. Das einzige, wofür man seine aktuelle
    > arbeit unterbrechen sollte - sind Fehler die eine höhere Priorität haben.
    > Alles andere steht hinten dran.

    Dieser Vergleich ist Schwachsinn, tut mir Leid, das so deutlich sagen zu müssen.
    Allein schon Vermutungen darüber zu äußern, wie wahrscheinlich es ist, so einen Bug zu fixen, dauert länger, als es zu tun. Und der Schreiber der Mail konnte offensichtlich programmieren und bearbeitete gerade Mails -> war also gerade nicht mit anderen Sachen beschäftigt UND wusste von der Problematik. Wenn keine Antwort auf die Eingangsmail erfolgt wäre, oder er auf die Komplexität, oder auf ein Verbot von höherer Stelle verwiesen hätte - hätte ich alles verstanden (keine Programmierresourcen vorhanden|dauert halt länger, aber wir wissen Bescheid|kann ich nichts machen, ist so nicht gewünscht - alles in dieser Reihenfolge), aber das nicht.



    1 mal bearbeitet, zuletzt am 26.08.14 13:44 durch Linuxschaden.

  14. Re: Ich glaub, es hackt ...

    Autor: Nephtys 26.08.14 - 14:09

    bongj schrieb:
    --------------------------------------------------------------------------------
    > Linuxschaden schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ... und zwar im wahrsten Sinne des Wortes!
    > > Da finden die Leute von Project Zero einen Buffer Overflow, und die
    > > Entwickler der Glibc diskutieren erst mal rum, ob der sich überhaupt
    > > ausnutzen lässt?!
    > >
    > > "Zunächst hatte es Diskussionen darüber gegeben, ob sich das Problem
    > > tatsächlich ausnutzen lässt."
    > >
    > > Hallo?! Muss ich ernsthaft mal hierauf verweisen?
    > >
    > > "Die Perspektive von Entwicklern auf Bugs müsste sein: You file it, we
    > fix
    > > it. Und zwar sofort. Keine Rückfragen, kein Gezeter, kein
    > Prokrastinieren.
    > > Alle Bugs werden sofort gefixt."
    > >
    > > Auf solche Entwickler schiebe ich Hass. Einfach nur Hass.
    > >
    > > EDIT: "Hmm. How likely is that? It overflows in to malloc metadata,
    > and
    > > the
    > > glibc malloc hardening should catch that these days."
    > >
    > > Florian Weimer ... den sollte man auch mal im Auge behalten.
    >
    > Gut führst du kein SW-Unternehmen, denn das wäre längst pleite. :-) In
    > einer idealen Welt (oder im Rahmen eines Studentenprojekts) mag deine
    > Aussage stimmen - in der Relität sieht das leider anderst aus. Es gibt
    > etliche Rahmenbedinungen (Ressourcen, Technologien, Zeit, existierende
    > Schnittstellen, Kundenwünsche, Architekturvorgaben, Budgetvorgaben, ...)
    > welche die SW Entwicklung beinflussen. Da hat der Entwickler in der Regel
    > wenig zu melden.
    >
    > Aber du würdest natürlich heldenfhaft Überstunden schieben, um deine
    > persönliche "Vision Zero" zu verwirklichen, klar doch.


    Lies and Slander!

    Für so etwas gibt es Code-Einsichten und vor allem Tests. Man mag ja für vieles keine Tests schreiben, aber zumindest für die Grenzwerte doch wohl!
    Ein Unternehmen, das so etwas nicht rigoros betreibt ist schnell Pleite, denn für solche Bugs sind sie dann direkt haftbar.

  15. Re: Ich glaub, es hackt ...

    Autor: mnementh 26.08.14 - 14:13

    bongj schrieb:
    --------------------------------------------------------------------------------
    > Gut führst du kein SW-Unternehmen, denn das wäre längst pleite. :-) In
    > einer idealen Welt (oder im Rahmen eines Studentenprojekts) mag deine
    > Aussage stimmen - in der Relität sieht das leider anderst aus. Es gibt
    > etliche Rahmenbedinungen (Ressourcen, Technologien, Zeit, existierende
    > Schnittstellen, Kundenwünsche, Architekturvorgaben, Budgetvorgaben, ...)
    > welche die SW Entwicklung beinflussen. Da hat der Entwickler in der Regel
    > wenig zu melden.
    >
    Das mag erst einmal rational aussehen. Aber das ist einfach das Setzen falscher Prioritäten. Sicherheit wird niedrig priorisiert. Das ist auch relativ klar, weil bei der Abnahme sieht man solche Probleme nicht.

    Aber diese Haltung ist ein generelles Problem in der Softwareentwicklung und sorgt dafür dass Software schlecht ist. Ja ich kenne das auch, ich arbeite als Programmierer und ich weiß dass mein Chef nachfragt wenn ich mehr Zeit mit Bugfixing zubringe.

    Aber vergleichen wir das mal mit anderen Sachen: beim Hausbau könnte man auch statische und Materialprüfungen sein lassen. Denn das neue Hochhaus muss termingerecht und mit möglichst wenig Aufwand fertig sein. Wenn es fünf Jahre später zusammenbricht und 100 Menschen sterben, dann ist das nebensächlich, Hauptsache ich konnte am Billigsten anbieten. Beim Auto welches ich produziere ist es nebensächlich auf Sicherheit zu achten. Hauptsache ich spare Arbeitszeit und damit Geld.

    Bei diesen Beispielen gibt es in der Realität eine hohe Haftbarkeit. Auch in so manchen anderem Bereich wird bei Fehlern durch die Hersteller oft auf eigene Kosten das Produkt zurückgerufen. Dagegen ist ein 'You file it, we fix it' echt billig. Wir sollten unsere Kultur ändern.

    Und ja, dass heißt Software wird teurer oder Kunden verzichten auf Features. Und die Entwicklung dauert länger. Aber angesichts der Schäden die durch fehlerhafte Software (nicht nur Sicherheitsprobleme) ganz real entstehen, würde ich das für die bessere Variante halten. Aber ja, so wie der Markt ist, würde man mit einer solchen Haltung totkonkurriert werden.

    > Aber du würdest natürlich heldenfhaft Überstunden schieben, um deine
    > persönliche "Vision Zero" zu verwirklichen, klar doch.
    Es ist nicht mein Problem als Entwickler. Da sind entweder die Kunden oder der Staat (mit einer allgemeingültigen Haftungsregelung) gefragt.

  16. Re: Ich glaub, es hackt ...

    Autor: bongj 26.08.14 - 14:58

    Ich muss noch ergänzen, ich die Realität keineswegs immer gut heisse: Ich würde mir auch wünschen, dass mehr Augenmerk auf Qualität statt Quantität gesetzt wird. Aber dies bringt halt kurzfristig gesehen (und die Weitsicht vieler Konzerne reicht ja oft nur ins nächste Quartal) keine Gewinne.

    Lieber Kosten drücken, bis alles auseinanderfällt - bis die Tragweite bewusst wird, sind die Verantwortlichen bestimmt schon in einer anderen Firma und stellen dort ihr Können unter Beweis :-)

  17. unverstandene Fehler fixen...

    Autor: Anonymer Nutzer 26.08.14 - 15:50

    ...führt zu so peinlichen Mehrfachreparaturen wie wir es schon häufig bei z.B. Microsoft gesehen haben. Man kann keinen Fehler beheben dessen Ursache und Auswirkung nicht vollständig bekannt ist.

  18. Re: Ich glaub, es hackt ...

    Autor: SelfEsteem 26.08.14 - 20:29

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > EDIT: "Hmm. How likely is that? It overflows in to malloc metadata, and
    > the
    > glibc malloc hardening should catch that these days."
    >
    > Florian Weimer ... den sollte man auch mal im Auge behalten.

    Najaaaa, mal Ball flach halten.
    Ich habe die Diskussion nicht gelesen, aber ... die Frage nach der Wahrscheinlichkeit einer Ausnutzung ist sehr wohl wichtig.
    Der Fix muss so oder so kommen, keine Frage, aber dann gehts noch darum, wie man mit dem Fix umgeht.
    Wird er z.B. in die kommende Version einfliessen? Gibts ein sofortiges Update? Wird in alle Versionen der letzten 10 Jahre rueckportiert?
    Die Frage sollte man sich schon stellen und nicht "nur blind fixen" ;)

  19. Re: Ich glaub, es hackt ...

    Autor: Anonymer Nutzer 27.08.14 - 00:07

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > ... und zwar im wahrsten Sinne des Wortes!
    > Da finden die Leute von Project Zero einen Buffer Overflow, und die
    > Entwickler der Glibc diskutieren erst mal rum, ob der sich überhaupt
    > ausnutzen lässt?!
    >
    > "Zunächst hatte es Diskussionen darüber gegeben, ob sich das Problem
    > tatsächlich ausnutzen lässt."
    >
    > Hallo?! Muss ich ernsthaft mal hierauf verweisen?
    >
    > "Die Perspektive von Entwicklern auf Bugs müsste sein: You file it, we fix
    > it. Und zwar sofort. Keine Rückfragen, kein Gezeter, kein Prokrastinieren.
    > Alle Bugs werden sofort gefixt."
    >
    > Auf solche Entwickler schiebe ich Hass. Einfach nur Hass.
    >
    > EDIT: "Hmm. How likely is that? It overflows in to malloc metadata, and
    > the
    > glibc malloc hardening should catch that these days."
    >
    > Florian Weimer ... den sollte man auch mal im Auge behalten.


    Ich bin da ja grundsätzlich bei dir,aber weder du noch fefe, haben Ideen für funktionierende Präventivmaßnahmen.
    Den das erwähnte "You file it, we fix",behebt Probleme auch erst,wenn der Baum unter Umständen schon längst abgefackelt ist.
    Und es muss ihn ja auch erstmal geben,denjenigen der sagt "Hey,dein Code ist Scheiße."

  20. Re: Ich glaub, es hackt ...

    Autor: Endwickler 28.08.14 - 08:38

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > ... und zwar im wahrsten Sinne des Wortes!
    > Da finden die Leute von Project Zero einen Buffer Overflow, und die
    > Entwickler der Glibc diskutieren erst mal rum, ob der sich überhaupt
    > ausnutzen lässt?!

    Nun, ich stimme dir voll und ganz zu: Probleme müssen sofort beseitigt werden und jedes Einholen von Informationen dazu sollte verboten werden.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Computacenter AG & Co. oHG, verschiedene Standorte
  2. BWI GmbH, Berlin, München, Nürnberg, Rheinbach
  3. BWI GmbH, Meckenheim
  4. ManpowerGroup Deutschland GmbH & Co. KG, Kiel

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 127,99€ (Bestpreis!)
  2. 114,99€ (Release am 5. Dezember)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Super Mario Maker 2 & Co.: Vom Spieler zum Gamedesigner
Super Mario Maker 2 & Co.
Vom Spieler zum Gamedesigner

Dreams, Overwatch Workshop und Super Mario Maker 2: Editoren für Computerspiele werden immer mächtiger, inzwischen können auch Einsteiger komplexe Welten bauen. Ein Überblick.
Von Achim Fehrenbach

  1. Nintendo Akku von überarbeiteter Switch schafft bis zu 9 Stunden
  2. Hybridkonsole Nintendo überarbeitet offenbar Komponenten der Switch
  3. Handheld Nintendo stellt die Switch Lite für unterwegs vor

Transport Fever 2 angespielt: Wachstum ist doch nicht alles
Transport Fever 2 angespielt
Wachstum ist doch nicht alles

Wesentlich mehr Umfang, bessere Übersicht dank neuer Benutzerführung und eine Kampagne mit 18 Missionen: Das Schweizer Entwicklerstudio Urban Games hat Golem.de das Aufbauspiel Transport Fever 2 vorgestellt - bei einer Bahnfahrt.
Von Achim Fehrenbach

  1. Mordhau angespielt Die mit dem Schwertknauf zuschlagen
  2. Bus Simulator angespielt Zwischen Bodenschwelle und Haltestelle
  3. Bright Memory angespielt Brachialer PC-Shooter aus China

Projektorkauf: Lumen, ANSI und mehr
Projektorkauf
Lumen, ANSI und mehr

Gerade bei Projektoren werden auf Plattformen verschiedener Onlinehändler kuriose Angaben zur Helligkeit beziehungsweise Leuchtstärke gemacht - sofern diese überhaupt angegeben werden. Wir bringen etwas Licht ins Dunkel und beschäftigen uns mit Einheiten rund um das Thema Helligkeit.
Von Mike Wobker


    1. Windows 10: Windows-Defender-Dateien werden als fehlerhaft erkannt
      Windows 10
      Windows-Defender-Dateien werden als fehlerhaft erkannt

      Der System File Checker in Windows 10 markiert neuerdings Dateien des Windows Defender als fehlerhaft. Der Bug ist auch Microsoft bekannt. Das Problem: Die neue Version des Defenders verändert im Installationsimage verankerte Dateien. Der Hersteller will das mit einem Update von Windows 10 beheben.

    2. Keystone: Mechanische Tastatur passt Tastendruckpunkte den Nutzern an
      Keystone
      Mechanische Tastatur passt Tastendruckpunkte den Nutzern an

      Die auf Kickstarter finanzierte Keystone ist eine mechanische Tastatur mit Hall-Effekt-Schaltern. Diese können die Druckstärke registrieren. Eine Software ermöglicht es der Tastatur, das Tippverhalten der Nutzer zu analysieren und Druckpunkte entsprechend anzupassen.

    3. The Witcher: Erster Netflix-Trailer mit Geralt, Ciri, Triss und Striegen
      The Witcher
      Erster Netflix-Trailer mit Geralt, Ciri, Triss und Striegen

      Netflix stellt den ersten Trailer seiner Serie The Witcher vor. Henry Cavill als Geralt von Riva kämpft dabei gegen Monster und Menschen und verwendet Hexerzeichen, Pirouettenkampf und Zaubertränke. Einige Szenen erinnern an Passagen aus den Büchern.


    1. 13:00

    2. 12:30

    3. 11:57

    4. 17:52

    5. 15:50

    6. 15:24

    7. 15:01

    8. 14:19