Mal wieder aus der beliebten Reihe Buffer-Overflow.
Wann trennt man sich endlich von diesem unsäglichen C. Offenbar ist es ja selbst für Profis nicht möglich damit halbwegs fehlerfreien Code zu schreiben.
Achja, vergesst nicht nach dem Update den Rechner neuzustarten. Nur so ist ein Reload wirklich garantiert.
Von Lemmy Danger am Mi, 17. Februar 2016 um 16:00 #
Yup, da frägt man sich auch wofür es die ganzen Tools gibt, die einem helfen Buffer-Overflows zu finden. Gerade bei solchen zentralen Libraries ist das mehr als ärgerlich!
Ansonsten sind C/C++ nicht die einzigen Sprachen mit dem Problem.
Dann gibt es ja auch noch so nette Compiler Flags, die einem trotz "perfektem" Code, die Lücken wieder hineinoptimieren. D.h. Code ist ok, Binary ist trotzdem ein Schweizer Käse :/
Von Christian Wetzel am Mi, 17. Februar 2016 um 17:35 #
C selbst hat so gut wie nie Sicherheitsprobleme - ganz im Gegensatz z.B. zur Java VM. Das Problem hier liegt wie so oft daran dass neue Entwickler alten Code aendern den sie nicht zu 100% verstehen, in dem Fall wohl fuer die IPv6 Anpassungen.
Und in was ist die JVM geschrieben? Und schon wieder sind wir bei C. Es ist ja auch nicht das Problem das C selbst Sicherheitsprobleme hat, sondern das es Programmierer so oft zu Sicherheitsproblemen verleitet.
C ist ein toller Hammer mit dem sich Nägel effizient rein schlagen lassen, leider trifft man wenn man nicht aufpasst leicht den eigenen Daumen.
Und welche Traumsprache deckt jetzt alles ab, vom Kernel bis zum Browser? Und ja, die populären Browser setzen auf C++ auf, aber das ist bestimmt auch voll böse, wegen null pointer und so.
Na ja, auf einer deutschen Plattform diskutieren ist auch doof. Wie wäre es mit Esperanto? Keine unregelmäßigen Verben und viel besser entworfen. Ob dann irgendwer noch mitredet?
Und, um von der Metapher wegzukommen, würde irgendwer den tollen Code dieser exotischen Sprache reviewen? Dann doch lieber Leute von Google und Redhat die tatsächlich eingesetzte Software tatsächlich sicherer machen.
Es gibt genügend moderne Programmiersprachen, die besser designed sind als C oder C++. Die dazugehörigen Compiler sind self-hosting und dadurch nicht von den C-Problemen betroffen. Dazu gehören unter anderem C# und Go. Mit beiden lassen sich vollwertige Anwendungen erstellen.
Gibt es diesbezüglich schon Untersuchungen, wie sich diese Sprachen auf die Stabilität der geschriebenen Software auswirken? Handwerkliche Fehler (und dazu zähle ich Pufferüberläufe) sind das eine, aber dann gibt es schließlich auch noch fachliche/logische Fehler. Wie stehen da die Verhältnisse?
Interessant wäre auch, wie viele Entwickler oder Anwender es akzeptieren würden, wenn ohnehin schon knappe Ressourcen abgezogen werden, um alle Tools und Bibliotheken in einer neuen Sprache zu entwickeln. DAS wäre mal ein "Fork". Und am Ende steht man mit einer neuen Sprache da, die dann wieder veraltet ist weil irgendwas Anderes schon wieder ganz schlimm ist und mit der Sprache go++ automatisch vermieden wird.
Ganz davon abgesehen, dass man wohl ohne C nicht auskommieren wird. Schon alleine um mit Standards wie POSIX kompatibel zu sein.
Und wer jetzt erstmal eine neue API entwickeln und standardisieren möchte... oh je.
Ich will gar nicht abstreiten, dass neue Konzepte ausprobiert und neue Sprachen entstehen sollen. Die Abwägung ist hier jedoch entscheidend. Pufferüberläufe sind bekannt, und es gibt statische Analysen. Die sind nicht perfekt, aber es gibt Leute mit Review-Erfahrungen. Und hier wurde immerhin ein Problem behoben.
Naja, vele Embedded Geräte basieren auf einem generischen Linux OS, also kann man Embedded nicht generell auschließen. Aber ja Router verwenden vermulich was kompakteres.
Von Die Hoffnung stirbt zuletzt am Mi, 17. Februar 2016 um 17:09 #
Woher weißt Du, ob die Lücke in einschlägigen Kreisen nicht längst bekannt war und ausgenutzt wurde? Die Profis von der dunklen Seite halten es da wie es der Gentleman hält, er genießt und schweigt.
So ähnlich machen es auch Inhaber betroffener Systeme, nur das sie es nicht genießen.
Ich würde vermuten, dass hier viel Wind um nix gemacht wird. In vielen Fällen sitzt ja ein Router vor dem PC, in vielen Routern wie z.B. DD-WRT sitzt ein dnsmasq dazwischen, der nicht anfällig ist weil auf den Routern kein glibc läuft und somit dem Client dahinter nix passiert, da er seine Anfragen von dnsmasq beantwortet bekommt.
Nur wirst du bald kein DD-WRT auf deinem Router installieren dürfen. Andererseits braucht man keine glibc-Lücke, da die Hersteller genug Bugs in ihrer Firmware haben, und nur schleppened, wenn überhaupt fixen
Ich ueberlege zur Zeit auf meinem Laptop von Debian auf Gentoo, Void oder Alpine Linux umzusteigen. Die relativ schmerzfreie Verwendung der musl clib funktionert zumindest in Void Linux innerhalb von qemu sehr gut.
Wuerde mich freuen wenn jemand seine Langzeiterfahrungen mit einer alternativen clib auf der Workstation teilen wuerde
Sämtliche Slackware-Glibc-Versionen sind übrigens von dem betreffenden Bug erst einmal nicht betroffen, weil diese immer noch einen Patch enthalten, der 2009 von OpenSuse und Fedora aus anderen Gründen übernommen und bisher auch nicht entfernt wurde (!).
Mal wieder aus der beliebten Reihe Buffer-Overflow.
Wann trennt man sich endlich von diesem unsäglichen C. Offenbar ist es ja selbst für Profis nicht möglich damit halbwegs fehlerfreien Code zu schreiben.
Achja, vergesst nicht nach dem Update den Rechner neuzustarten. Nur so ist ein Reload wirklich garantiert.
Gruß
MichaelK
Yup, da frägt man sich auch wofür es die ganzen Tools gibt, die einem helfen Buffer-Overflows zu finden. Gerade bei solchen zentralen Libraries ist das mehr als ärgerlich!
Ansonsten sind C/C++ nicht die einzigen Sprachen mit dem Problem.
Dann gibt es ja auch noch so nette Compiler Flags, die einem trotz "perfektem" Code, die Lücken wieder hineinoptimieren. D.h. Code ist ok, Binary ist trotzdem ein Schweizer Käse :/
C selbst hat so gut wie nie Sicherheitsprobleme - ganz im Gegensatz z.B. zur Java VM.
Das Problem hier liegt wie so oft daran dass neue Entwickler alten Code aendern den sie nicht zu 100% verstehen, in dem Fall wohl fuer die IPv6 Anpassungen.
Und in was ist die JVM geschrieben? Und schon wieder sind wir bei C. Es ist ja auch nicht das Problem das C selbst Sicherheitsprobleme hat, sondern das es Programmierer so oft zu Sicherheitsproblemen verleitet.
C ist ein toller Hammer mit dem sich Nägel effizient rein schlagen lassen, leider trifft man wenn man nicht aufpasst leicht den eigenen Daumen.
Gruß
MichaelK
Und es C sehr einfach macht irre Fehler einzubauen.
Gruß
MichaelK
Und welche Traumsprache deckt jetzt alles ab, vom Kernel bis zum Browser? Und ja, die populären Browser setzen auf C++ auf, aber das ist bestimmt auch voll böse, wegen null pointer und so.
Na ja, auf einer deutschen Plattform diskutieren ist auch doof. Wie wäre es mit Esperanto? Keine unregelmäßigen Verben und viel besser entworfen. Ob dann irgendwer noch mitredet?
Und, um von der Metapher wegzukommen, würde irgendwer den tollen Code dieser exotischen Sprache reviewen? Dann doch lieber Leute von Google und Redhat die tatsächlich eingesetzte Software tatsächlich sicherer machen.
Es gibt genügend moderne Programmiersprachen, die besser designed sind als C oder C++. Die dazugehörigen Compiler sind self-hosting und dadurch nicht von den C-Problemen betroffen. Dazu gehören unter anderem C# und Go. Mit beiden lassen sich vollwertige Anwendungen erstellen.
Gibt es diesbezüglich schon Untersuchungen, wie sich diese Sprachen auf die Stabilität der geschriebenen Software auswirken? Handwerkliche Fehler (und dazu zähle ich Pufferüberläufe) sind das eine, aber dann gibt es schließlich auch noch fachliche/logische Fehler. Wie stehen da die Verhältnisse?
Interessant wäre auch, wie viele Entwickler oder Anwender es akzeptieren würden, wenn ohnehin schon knappe Ressourcen abgezogen werden, um alle Tools und Bibliotheken in einer neuen Sprache zu entwickeln. DAS wäre mal ein "Fork". Und am Ende steht man mit einer neuen Sprache da, die dann wieder veraltet ist weil irgendwas Anderes schon wieder ganz schlimm ist und mit der Sprache go++ automatisch vermieden wird.
Ganz davon abgesehen, dass man wohl ohne C nicht auskommieren wird. Schon alleine um mit Standards wie POSIX kompatibel zu sein.
Und wer jetzt erstmal eine neue API entwickeln und standardisieren möchte... oh je.
Ich will gar nicht abstreiten, dass neue Konzepte ausprobiert und neue Sprachen entstehen sollen. Die Abwägung ist hier jedoch entscheidend. Pufferüberläufe sind bekannt, und es gibt statische Analysen. Die sind nicht perfekt, aber es gibt Leute mit Review-Erfahrungen. Und hier wurde immerhin ein Problem behoben.
Da müsste es ja auch Embedded Systeme betreffen, Oder nicht? wie sieht es da mit den Routern/DSL Boxen aus, z.B. AVM
Gruss
Gruß
MichaelK
Gruß
MichaelK
Danke
Um genau die *glibc* geht's doch
Edit: ignoriert das, habe das "nicht" überlesen.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 19. Feb 2016 um 13:01.Die meisten embedded-Geräte verwenden keine glibc, sondern kleinere Varianten wie uClibc oder Bionic (Android).
Naja, vele Embedded Geräte basieren auf einem generischen Linux OS, also kann man Embedded nicht generell auschließen. Aber ja Router verwenden vermulich was kompakteres.
Hat den Code jemand geprüft? Wer dagt dir denn das die kleineren Varianten nicht den anfälligen Codeteil vom "großem" Bruder verwenden?
und ich wunderte mich schon, weshalb vorgestern ein glibc -Update hereinkam...
schön, das die Lücke erst nach dem Update bekannt wurde
Woher weißt Du, ob die Lücke in einschlägigen Kreisen nicht längst bekannt war und ausgenutzt wurde? Die Profis von der dunklen Seite halten es da wie es der Gentleman hält, er genießt und schweigt.
So ähnlich machen es auch Inhaber betroffener Systeme, nur das sie es nicht genießen.
Ich würde vermuten, dass hier viel Wind um nix gemacht wird. In vielen Fällen sitzt ja ein Router vor dem PC, in vielen Routern wie z.B. DD-WRT sitzt ein dnsmasq dazwischen, der nicht anfällig ist weil auf den Routern kein glibc läuft und somit dem Client dahinter nix passiert, da er seine Anfragen von dnsmasq beantwortet bekommt.
Nur wirst du bald kein DD-WRT auf deinem Router installieren dürfen. Andererseits braucht man keine glibc-Lücke, da die Hersteller genug Bugs in ihrer Firmware haben, und nur schleppened, wenn überhaupt fixen
BTW: http://www.heise.de/newsticker/meldung/Funkregulierung-TP-Link-muss-WLAN-Firmware-sperren-3109847.html
Ich ueberlege zur Zeit auf meinem Laptop von Debian auf Gentoo, Void oder Alpine Linux umzusteigen.
Die relativ schmerzfreie Verwendung der musl clib funktionert zumindest in Void Linux innerhalb von qemu sehr gut.
Wuerde mich freuen wenn jemand seine Langzeiterfahrungen mit einer alternativen clib auf der Workstation teilen wuerde
Wuerde mich freuen wenn jemand..... mit einer alternativen clib ...... teilen wuerde
Wäre halbe -halbe ok?
Sämtliche Slackware-Glibc-Versionen sind übrigens von dem betreffenden Bug erst einmal nicht betroffen, weil diese immer noch einen Patch enthalten, der 2009 von OpenSuse und Fedora aus anderen Gründen übernommen und bisher auch nicht entfernt wurde (!).
Siehe z.B.:
https://sourceware.org/bugzilla/show_bug.cgi?id=7060
Demzufolge gibt es auch noch einige ältere OpenSuse- und Fedora-Glibc-Versionen, die für den hier behandelten Bug nicht empfänglich sind.