1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Microsoft IIS: Lücke in Windows…

m( - Wieso packt man sowas auch in den Kernel?

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. m( - Wieso packt man sowas auch in den Kernel?

    Autor: Linuxschaden 15.04.15 - 20:07

    Naja, ich kann sagen, warum: weil MS alles in den Kernel zu packen scheint. Als Kompensation darauf, dass ihre Codebasis scheiße ist. Wieso beispielsweise Updates - nein, machen wir es einfacher: wieso beispielsweise nur die Installation des Microsoft Compilers so unendlich lange braucht und das Ding so unglaublich mies performt, hat man mir bisher außer mit "Nun, da steckt vermutlich 'ne Menge Kompatibilitätskomplexität hinter" auch nicht erklären können.

    Der Fehler wird, so wie ich das sehe, über einen Range-HTTP-Header ausgelöst ... bitte, was? Läuft da ein Check nicht ordentlich durch? Das gehört doch eher zur elementaren Aufgabe eines Servers, zu prüfen, ob die Daten, die angefragt oder referenziert werden, noch im Bereich liegen. Und wenn man dann diesen Check macht, dann auch bitte in dem Typen, in dem später auf den Speicherbereich zugegriffen wird. Weil man dann sonst wieder genau so eine Overflow-Scheiße hat ... Mann Mann Mann.

    Brisanz erhält das Problem ja gerade dadurch, dass der Code IM KERNEL LIEGT. "Code wird mit Systemrechten ausgeführt" hört sich so unschuldig an. Wenn sowas im Userspace passiert, ist das schon schlimm genug, aber wenigstens der Rest des Systems steht noch. Wenn das im Kernelspace passiert ... m(

  2. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Deliven 15.04.15 - 20:51

    Bin jetzt auch nicht der Linux Fanboy, da einige Gameserver Windows benötigen. Klar mit Wine kommt man weit aber bei mir wollte Wine nicht so dolle.

    Ziemlich super muss ich aber sagen, denn so wie es aussieht ist das Problem nicht gerade neu sondern schon uralt.
    Als Server Administrator, sollte ich da schon schnell handeln nur sind sehr viele Leute auf dem Server die den benutzen und ohne neustart wird das nichts.

    Wenn sich das mit Linux bessert was Gameservern auf Linux betrifft, dann werde ich aufjedenfall wechseln.
    Jedenfalls ist aber der Komfort über RDP von Windows Server angenehmer und per Copy Paste kann man auch seine Programme übertragen.
    Unter Linux mit xrdp geht das nicht, da führt also glaube ich kein weg an FTP vorbei :(.

  3. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Linuxschaden 15.04.15 - 21:21

    Deliven schrieb:
    --------------------------------------------------------------------------------
    > Bin jetzt auch nicht der Linux Fanboy, da einige Gameserver Windows
    > benötigen. Klar mit Wine kommt man weit aber bei mir wollte Wine nicht so
    > dolle.

    Wine hat seine ganz eigenen Probleme an der Stelle bei mir:

    1. Dateizugriffe auf Verzeichnisstrukturen, die noch alte DOS-Pfade besitzen (Dateie~1.txt), werden nicht korrekt aufgelöst - hat auch nur eine Woche gebraucht, das rauszufinden. m(
    2. Ihre Vertex-Archtektur unter DX8 und DX9 ist verkackt bis zum Geht-Nicht-Mehr, etliche 3D-Anwendungen haben deswegen kaputte Grafiken oder stürzen auch gerne komplett ab. Das Problem ist seit 6 Jahren bekannt, seit 6 Jahren hocken die auf dem Problem und konnten bisher nicht mal eine Lösung auf Software-Renderingbasis implementieren. Ich will gar nicht mal Hardwarebeschleunigung haben, ich will einfach nur, dass es funzt. DX8 und 9 sind jetzt gar nicht mal so aufwendig an der Stelle, dass man das nicht zur Not auf auf der CPU machen kann. Aber bieten sie das an? Nö. Seit 6 Jahren.

    Außerdem gibt es noch etliche Probleme mit der VBX-Unterstützung ... wenn DosBOX Windows 3.11 und Windows 95 besser emuliert als Wine, dann weißt du, was die Stunde geschlagen hat für diese Schnarchnasen.
    Das einzig gute an der Sache: deren Ranzcode läuft wenigstens nicht im Kernel, Ritchie bewahre.

    > Ziemlich super muss ich aber sagen, denn so wie es aussieht ist das Problem
    > nicht gerade neu sondern schon uralt.
    > Als Server Administrator, sollte ich da schon schnell handeln nur sind sehr
    > viele Leute auf dem Server die den benutzen und ohne neustart wird das
    > nichts.

    Also lieber einen systemweiten DOS riskieren? Oder noch schöner, dass das OS komplett zugehauen wird? Erinnert mich an eine Firma, die drei Monate nach Heartbleed gesagt hat: "Lasst uns mal OpenSSL auf unseren Servern neu ausrollen".

  4. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: derh0ns 15.04.15 - 21:37

    Deliven schrieb:
    --------------------------------------------------------------------------------
    > Jedenfalls ist aber der Komfort über RDP von Windows Server angenehmer und
    > per Copy Paste kann man auch seine Programme übertragen.
    > Unter Linux mit xrdp geht das nicht, da führt also glaube ich kein weg an
    > FTP vorbei :(.

    Das sagst du jetzt einfach, aber wenn du dich erstmal auskennst willst du gar kein GUI mehr nutzen, da es einfach zu lange dauert.

  5. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Super Genie 15.04.15 - 22:10

    Es gab und gibt auch im Linux-Kernel genügend Fehler, die eine Ausführung von Code im Kern ermöglichen oder zumindest die Möglichkeit bieten, sich weitergehende Rechte zu verschaffen. Der Einwand, was denn ein HTTP-Server im Kernel zu suchen hat, ist meines Erachtens nach natürlich äußerst berechtigt. Hier hat Microsoft sich entschieden auf Risiko zu spielen und den Code aus Performance-Gründen im Kern zu belassen. Diese Änderung hat damals soweit ich mich erinnere aber auch einiges an Kopfschütteln hervorgerufen.

    Was Wine angeht? Naja, hier versucht man ja mittels Reverse Engineering eine gigantische Schnittstelle (WinAPI) zu reimplementieren, die a) nicht hundertprozentig dokumentiert ist, b) über jede Menge undefiniertes Verhalten verfügt und c) nicht für die Arbeit mit Unix-artigen Systemen gedacht ist. Die Problematik bei D3D ist ähnlich, außerdem setzt Wine nicht auf eigene Hardware-Treiber (die es von Hardwareherstellern sowieso nicht geben würde) sondern auf OpenGL. OpenGL, besonders die Versionen vor 3.0, hatten nun einmal einige Eigenheiten, die es äußerst schwierig macht Direct3D-Aufrufe dorthin zu übersetzen. Mit Vulkan dürfte das bald kein Problem mehr sein, wobei diese wiederum Hardware erfordern dürfte, die mindestens auf Direct3D 10-Niveau ist. Könnte für ältere Spiele aber dennoch interessant werden.

    Das DOSBOX Windows 3.11 und Windows 95 besser kann als Wine ist klar, denn DOSBOX emuliert ja auch "nur" die DOS API, und nicht die um Längen komplexere Windows API.

  6. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: ioxio 15.04.15 - 23:40

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Naja, ich kann sagen, warum: weil MS alles in den Kernel zu packen scheint.
    > Als Kompensation darauf, dass ihre Codebasis scheiße ist.

    Genau so ist es mein Freund.

    Microsoft verkauft seit Jahren verfaultes NT-Hundshack als Premiumwurst. ES GEHT UM DIE VERPACKUNG.

    Deßhalb wird Windows auch keine höhere Performance liefern.

    PPS: Es ist kein Geheimnis, dass man sich bei Microsoft ganze Abteilungen leistet, um irgendwelche Tasks aus dem Boot-Process zu redeployen, damit das alte Luder schneller "hoch kommt". Diese Features werden dann an die Marketingabteilung weitergeleitet, auch bekannt als "die üblichen Placebos".

  7. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: OdinX 16.04.15 - 00:01

    derh0ns schrieb:
    --------------------------------------------------------------------------------
    > Deliven schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Jedenfalls ist aber der Komfort über RDP von Windows Server angenehmer
    > und
    > > per Copy Paste kann man auch seine Programme übertragen.
    > > Unter Linux mit xrdp geht das nicht, da führt also glaube ich kein weg
    > an
    > > FTP vorbei :(.
    >
    > Das sagst du jetzt einfach, aber wenn du dich erstmal auskennst willst du
    > gar kein GUI mehr nutzen, da es einfach zu lange dauert.

    Das sagst DU jetzt einfach. GUI und Konsole haben beide Vorteile und Nachteile, wenn du denkst, dass die Konsole immer schneller ist, dann hast du absolut keine Ahnung.

  8. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: ioxio 16.04.15 - 00:26

    OdinX schrieb:
    --------------------------------------------------------------------------------
    > ...wenn du denkst, dass die Konsole immer schneller ist, dann hast
    > du absolut keine Ahnung.

    Habe schon mehrfach erlebt, wie sich achso herzhafte "Konsolenritter" als flanschige Pflaumen erwiesen haben und den Schreibtisch räumen mussten.

  9. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: joiha 16.04.15 - 00:26

    OdinX schrieb:
    --------------------------------------------------------------------------------
    > derh0ns schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Deliven schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Jedenfalls ist aber der Komfort über RDP von Windows Server angenehmer
    > > und
    > > > per Copy Paste kann man auch seine Programme übertragen.
    > > > Unter Linux mit xrdp geht das nicht, da führt also glaube ich kein weg
    > > an
    > > > FTP vorbei :(.
    > >
    > > Das sagst du jetzt einfach, aber wenn du dich erstmal auskennst willst
    > du
    > > gar kein GUI mehr nutzen, da es einfach zu lange dauert.
    >
    > Das sagst DU jetzt einfach. GUI und Konsole haben beide Vorteile und
    > Nachteile, wenn du denkst, dass die Konsole immer schneller ist, dann hast
    > du absolut keine Ahnung.

    Das schöne ist doch, dass man Windows auch inzwischen extrem effezient per Powershell bedienen kann. Powershell-Remoting ist bei Windows Server 2012/R2 standardmäßig aktiviert. Mit Server-Core und Windows Server 2016 (Nano Server Variante), zeigt Microsoft sehr deutlich, wohin die Reise geht. "Click-Next"-Admins sind irgendwann dann Geschichte. Davon ab ist die Powershell sogar den Linux Konsolen-basierten durch ihr durchweg objektorientiertes Pipelining sogar diesen überlegen.

    Ja es gibt sicherlich Gründe, Windows per RDP zu bedienen. Mir fallen allerdings keine ein. Ich mach alles per PS-Remoting.

  10. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Linuxschaden 16.04.15 - 07:40

    Super Genie schrieb:
    --------------------------------------------------------------------------------
    > Es gab und gibt auch im Linux-Kernel genügend Fehler, die eine Ausführung
    > von Code im Kern ermöglichen oder zumindest die Möglichkeit bieten, sich
    > weitergehende Rechte zu verschaffen.

    Aber man kommt unter Linux nicht auf die Idee, unnötiges Zeug in den Kernel zu laden. Außer natürlich, es würde Sinn ergeben. Spontan fällt mir bei einem HTTP-Server nur eines ein, was man im Kernel tun kann, was im Userspace nicht geht - die Daten aus dem Übertragunsschichtenprotokoll (TCP/UDP) über DMA direkt in Kernelpages speichern und dann die Validierung machen, damit spart man sich das Kopieren in den Userspace und das eventuell ungewollte Flushen des CPU-Caches mit den HTTP-Daten. Aber wenn das DER Flaschenhals bei der Windows-Implementierung ist, fress ich einen Besen (ein Validierungsdurchlauf, wenn man's nicht richtig macht, kostet auf einem i7 ~3500-4000 Cycles, und ich bin mir sicher, da kann man noch ein bisschen was rauskitzeln). Meine Vermutung ist eher, dass deren TCP-Stack im Eimer ist ... aber das ist jetzt nur eine Vermutung. Es schmeckt halt nur so.

    > Was Wine angeht? Naja, hier versucht man ja mittels Reverse Engineering
    > eine gigantische Schnittstelle (WinAPI) zu reimplementieren, die a) nicht
    > hundertprozentig dokumentiert ist, b) über jede Menge undefiniertes
    > Verhalten verfügt und c) nicht für die Arbeit mit Unix-artigen Systemen
    > gedacht ist.

    1. Warum dann nicht erst mal von klein nach groß? Wie wäre es, wenn man erstmal die Windows 1.0 API ordentlich hinbekommt - und dann die 2.0, dann 3, dann 95? Graduelle Erweiterung, ordentliche Modularisierung. Wenn das Kleine funktioniert, aber das Große nicht, das kann ich ja noch verstehen.
    2. "... nicht für die Arbeit mit Unix-artigen ..." - Maestro, das ist der Sinn und Zweck von Wine. Dass du deine Windows-Umgebung - sogar mehrere, das Konzept finde ich eigentlich sogar ziemlich schlau gelöst, dass du deinen Betriebssystemkontext in einem Ordner hast, mit Architektur und allem Drum und Dran - auf Unix haben kannst. Und sogar die LoadLibrary- und GetProcAddress-Calls haben sie so geändert, dass die auch mit den reellen so-Dateien unter Linux funktionieren. Optional. Und warum fallen die dann wieder wegen so einer Kindergartenkacke wie fehlerhafte Pfadauflösung auf die Fresse?

    Ich verstehe den Einwand, aber mir fehlt die sichtbar fehlende Konzeptionierung hinter dem Ganzen. Wenn du mir nicht glaubst, kannst du dir ja das mal anschauen. d3d10.dll ist weiter als d3dx8.dll - da kann doch was nicht stimmen.

    > Die Problematik bei D3D ist ähnlich, außerdem setzt Wine nicht
    > auf eigene Hardware-Treiber (die es von Hardwareherstellern sowieso nicht
    > geben würde) sondern auf OpenGL. OpenGL, besonders die Versionen vor 3.0,
    > hatten nun einmal einige Eigenheiten, die es äußerst schwierig macht
    > Direct3D-Aufrufe dorthin zu übersetzen.

    Bleibt die Frage, warum man dann nicht mal auf aktuellere APIs wechselt. DeuxEx und Final Fantasy 7 bekommen über DLL-Injection die Übersetzung von DirectX nach OpenGL-Calls übrigens auch relativ gut über die Bühne.

    > Mit Vulkan dürfte das bald kein Problem mehr sein

    Du meinst das gleiche Vulkan, welches diesen Bullet-Point in der Beschreibung hatte?

    > Extensible layered architecture enables innovative tools without impacting production performance while validating, debugging, and profiling

    Das letzte Mal, dass ich von "Extensible layered architecture" gehört habe, war im Zusammenhang mit Xorg, und damit ist genug gesagt und wir breiten den Mantel der christlichen Nächstenliebe über das Thema. Wenn wir Glück haben, wird das nur eine Luftnummer wie die Mantle-API, und im besten Fall haben wir nur Zeit vergeudet.

  11. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: hungkubwa 16.04.15 - 07:52

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Der Fehler wird, so wie ich das sehe, über einen Range-HTTP-Header
    > ausgelöst ... bitte, was? Läuft da ein Check nicht ordentlich durch? Das
    > gehört doch eher zur elementaren Aufgabe eines Servers, zu prüfen, ob die
    > Daten, die angefragt oder referenziert werden, noch im Bereich liegen. Und
    > wenn man dann diesen Check macht, dann auch bitte in dem Typen, in dem
    > später auf den Speicherbereich zugegriffen wird. Weil man dann sonst wieder
    > genau so eine Overflow-Scheiße hat ... Mann Mann Mann.

    Heartbleed lässt grüßen ^^

  12. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Linuxschaden 16.04.15 - 08:05

    hungkubwa schrieb:
    --------------------------------------------------------------------------------
    > Heartbleed lässt grüßen ^^

    Heartbleed war noch mal eine Dummheit höherer Stufe. Weil da die Benutzereingaben überhaupt nicht geprüft wurden und es möglich war, als Pong bis zu ~64 KB vom Server zurückgeben zu lassen, ohne zu prüfen, ob soviel überhaupt von der Gegenseite gesendet wurde. Und aufgrund der Tatsache, dass OpenSSL seinen eigenen Allokator verwendet hat, lagen OpenSSL-Daten immer schön nebeneinander - deswegen waren die Dumps, die man gesehen hat, auch so lecker.

    Das hier ist eher Overflow. Ein großer Wert, der eigentlich nicht passt, wird beim Check abgeschnitten, sodass der richtig große Teil nicht beachtet wird. Aber dieses Abschneiden passiert nicht, wenn auf die Daten zugegriffen werden soll. Gehe ich zumindest stark von aus, ich habe mir dem ASM-Code aber nur oberflächlich angeschaut.

    Und weil das im Kernel läuft, können wir so einen Zugriff in ungemappten Kernelspace initiieren => BSoD.

  13. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Wissard 16.04.15 - 08:37

    Linuxschaden schrieb:
    > > Heartbleed lässt grüßen ^^
    >
    > Heartbleed war noch mal eine Dummheit höherer Stufe.

    Dumm ist an Heartbleed nichts, das ist eine winzig kleine Unachtsamkeit. Es ist hauptsächlich eine Schwäche der C-APIs dass das solche Auswirkungen hat. Position und Länge eines Puffers werden immer getrennt übergeben werden obwohl sie logisch zusammengehören. Da passiert es zwangsläufig dass man irgendwann mal vergisst die Länge zu beachten. Es ist eigentlich verwunderlich, dass das nicht öfter passiert – halt tut es ja…



    2 mal bearbeitet, zuletzt am 16.04.15 08:38 durch Wissard.

  14. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Linuxschaden 16.04.15 - 08:57

    Wisgsard schrieb:
    --------------------------------------------------------------------------------
    >
    > Dumm ist an Heartbleed nichts, das ist eine winzig kleine Unachtsamkeit. Es
    > ist hauptsächlich eine Schwäche der C-APIs dass das solche Auswirkungen
    > hat. Position und Länge eines Puffers werden immer getrennt übergeben
    > werden obwohl sie logisch zusammengehören. Da passiert es zwangsläufig dass
    > man irgendwann mal vergisst die Länge zu beachten. Es ist eigentlich
    > verwunderlich, dass das nicht öfter passiert – halt tut es ja…

    1. C-API? Nix C-API. Die Anzahl der Bytes, die gelesen wurden, kommt vom Kernel, ob du das mit einem C-Call, mit Perl, mit Python oder mit deiner Kristallkugel liest, hat ja mal überhaupt nichts damit zu tun, einen Check zu machen, ob das, was als Payload-Menge angegeben wurde, auch innerhalb des Payloads liegt. Was mich zum zweiten Punkt bringt ...

    [Vernünftiges Verhalten wäre an der Stelle übrigens gewesen, bis zum Timeout auf die Daten zu warten. Hey, wenn der Client sagt, da kommt noch was, dann wartet man auf das "noch was", und wenn da nichts mehr kommt, dann hat er halt Pech gehabt und der Timeout schlägt zu. Wie der Fix dann am Ende ausgesehen hat, weiß ich nicht, ich habe mich ausgeklingt, als die LibreSSL-Leute Checks auf Null-Pointer vor free rausgenommen haben (nicht, dass das fehlerhaft wäre, einen Null-Pointer zu übergeben, aber es macht auch keinen Sinn, extra eine - in den meisten Fällen - dynamisch gelinkte Funktion aufzurufen, um den Code in den Check laufen zu lassen. Das sind ein paar Byte mehr im Binary, dafür hast du dann keinen Overhead durch sinnfreie Calls).]

    2. Eine winzige Unachtsamkeit? Bei einem Internetprotokoll?! Ich hoffe, du bist kein Programmierer, denn mit der Aussage hättest du dich als Dilettanten geouted.

    Diesen Overflow von MS kann ich gerade noch so verstehen. Das ist eine Unachtsamkeit. Implizierte Type-Promotion hat schon bessere Programmierer auf die Fresse fliegen lassen. Wobei ich nicht mal weiß, ob das implizit war. Wenn sie's explizit gemacht haben, sind das Nudelprogrammierer vor dem Herrn. Die eigentliche Würze aber kommt dadurch, dass die das im Kernel haben laufen lassen, es also bewusst darauf haben ankommen lassen, systemweit geownd zu werden. Für was? Damit man in den Benchmarks nicht sehen kann, wie scheiße das alles ist.

    Heartbleed war einfach nur "Ich habe keine Ahnung, was ich hier mache, aber wäre doch total cool, wenn wir das alle hätten".

  15. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Moe479 16.04.15 - 09:08

    du vergisst da etwas, das machen die leute in ihrer freizeit, nach feierabend, eher für sich als für andere, deswegen ist die kompatiblität mit höheren dx-version auch weiter fortgeschritten, weil das die entwickler und community selbst mehr interessiert als hornalte dx7 titel zu unterstützen ...

    und zu mantle, es hat doch ganz klar dazu bewogen dass die apis von anderen auch hardwarenäher wurden, es hat demonstriert, wie man das ereichen kann.

  16. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Wissard 16.04.15 - 09:36

    Linuxschaden schrieb:
    > 1. C-API? Nix C-API.
    Natürlich C-API. Guck dir einfach mal die Signatur von memcopy an. Es ist einfach ein Designfehler Zeiger und Länge getrennt zu übergeben. Das schreit danach, dass da jemand Mist baut.

    > [Vernünftiges Verhalten wäre an der Stelle übrigens gewesen, bis zum Timeout auf die Daten zu warten. Hey, wenn der Client sagt, da kommt noch was, dann wartet man auf das "noch was",
    Das klingt jetzt alles furchtbar schlau was du da schreibst, leider hast du offenbar keine Ahnung wie der Fehler wirklich aussah. An der Stelle an der der Fehler auftrat, gab es weder die Möglichkeit auf mehr Daten zu warten, noch die Notwendigkeit. Der Client hat ein gültiges Paket gesendet, welches an eine untergeordnete Funktion weitergeleitet wurde. Sprich: Wenn die Länge, die der Client angibt, nicht mit der realen Länge übereinstimmt, dann ist klar dass die Daten falsch sind und auch nichts mehr kommt, auf das man warten könnte.

    > 2. Eine winzige Unachtsamkeit? Bei einem Internetprotokoll?! Ich hoffe, du
    > bist kein Programmierer, denn mit der Aussage hättest du dich als
    > Dilettanten geouted.
    Ja es ist eine winzige Unachtsamkeit, die ständig von allen möglichen „Dilettanten“ dieser Welt wiederholt wird. Guck dir einfach mal an was die Ursache von > 90% aller Sicherheitslücken ist, die zur Zeit kursieren. Genau, nicht oder falsch geprüfte Puffer-Längen. Das hat nicht mit Unfähigkeit zu tun, sowas muss rein statistisch einfach passieren und das tut es auch. Das Problem ist, sowas kann jedem passieren, davor die Augen zu verschließen ist kontraproduktiv und führt genau zu solchen Bug, da „das ja nur anderen passiert“.

    > Heartbleed war einfach nur "Ich habe keine Ahnung, was ich hier mache, aber wäre doch total cool, wenn wir das alle hätten".
    Nein Heartbleed war: Wir benutzen einfachmal mal alle diesen sicherheitskritischen Code bezahlen aber niemanden dafür, dass er da mal rüberguckt.

  17. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Linuxschaden 16.04.15 - 11:10

    Wissard schrieb:
    --------------------------------------------------------------------------------
    > Natürlich C-API. Guck dir einfach mal die Signatur von memcopy an. Es ist
    > einfach ein Designfehler Zeiger und Länge getrennt zu übergeben. Das
    > schreit danach, dass da jemand Mist baut.

    1. Heißt die Funktion "memcpy".
    2. Meinst du die Laufzeitumgebung von C, standardisiert seit C89.
    3. Liegt das auch gar nicht an der Funktion. Genauso gut kannst du send vorwerfen, dass man Pointer und Länge separat angeben muss. Genug Speicher ist für den Response ja reserviert worden.

    > Das klingt jetzt alles furchtbar schlau was du da schreibst, leider hast du
    > offenbar keine Ahnung wie der Fehler wirklich aussah. An der Stelle an der
    > der Fehler auftrat, gab es weder die Möglichkeit auf mehr Daten zu warten,
    > noch die Notwendigkeit.

    Falsch, falsch, falsch.
    Der Code, der die Daten vom Socket abgreift, hat nach jedem recv einen Check zu machen, ob nach den Regeln des Protokolls genug Daten vorhanden sind, damit man was damit anfangen kann. Und das heißt: prüfe die Payload-Länge, die der Client übergeben hat, mit den Daten, die du bereits vom Socket hast, und wenn du mehr Daten hast (wegen Pipelining kann das sehr oft vorkommen, in dem Fall hältst du die Daten im Speicher und gehst nach der Bearbeitung wieder in Leseschleife), dann fange mit der Bearbeitung an.

    Und wenn du zwei Protokolle hast - SSL/TLS, welches die Verschlüsselung der Daten übernimmt, und Heartbeat, welches die Verbindung am Laufen erhält - dann musst du beide validieren. "Es gab die Möglichkeit nicht", auf mehr Daten zu warten? Entweder gab es die echt nicht - und dann ist OpenSSL scheiße und kaputt, weil man IMMER in den "les noch mal was vom Socket"-Modus gehen sollen könnte - oder du hast keine Ahnung, wovon du redest. Eine Unachtsamkeit (bei einem INTERNETPROTOKOLL) wäre das jedenfalls in tausend Jahren nicht. Und schon GAR nicht in einer Krypto-Lib.

    > Der Client hat ein gültiges Paket gesendet, welches
    > an eine untergeordnete Funktion weitergeleitet wurde. Sprich: Wenn die
    > Länge, die der Client angibt, nicht mit der realen Länge übereinstimmt,
    > dann ist klar dass die Daten falsch sind und auch nichts mehr kommt, auf
    > das man warten könnte.

    Woran erkennst du, dass es gültig ist? Und für welches Protokoll? Jetzt wird's nämlich spannend.

    Gültig bedeutet: die OpenSSL-Lib hat den verschlüsselten Beat erhalten und korrekt entschlüsselt, alles ist prima. ABER dieser Status "alles ist prima" bezieht sich auf SSL/TLS. Das Heartbeat-Protokoll, was da eigentlich implementiert ist, hat überhaupt keinen Check erhalten. Womit wir wieder am Anfang wären: gehe zurück und warte, bis wieder ein Paket ankommt, und dann prüfen wir wieder. Und wieder. Und wieder. Bis wir so viel haben, wie im Payload drinsteht. Oder bis die Verbindung stirbt.

    Das sind verschiedene Protokolle. Nur weil Protokoll A B beinhaltet und A sicher übertragen wurde, heißt das nicht, dass B ebenfalls sicher ist.

    > Ja es ist eine winzige Unachtsamkeit, die ständig von allen möglichen
    > „Dilettanten“ dieser Welt wiederholt wird. Guck dir einfach mal
    > an was die Ursache von > 90% aller Sicherheitslücken ist, die zur Zeit
    > kursieren. Genau, nicht oder falsch geprüfte Puffer-Längen.

    So, und was heißt das?

    Das diese Programmierer die Finger davon lassen sollten, so etwas kritisches zu implementieren. Weil wir bei Netzwerk UND Krypto keine Dilettanten gebrauchen können. Punkt. Oder die Leute hören auf, sich wegen vollkommen kaputter OpenSource-Krypto in die Hose zu machen, weil - tja, ist ja nur OpenSource.

    > Das hat nicht
    > mit Unfähigkeit zu tun, sowas muss rein statistisch einfach passieren und
    > das tut es auch. Das Problem ist, sowas kann jedem passieren, davor die
    > Augen zu verschließen ist kontraproduktiv und führt genau zu solchen Bug,
    > da „das ja nur anderen passiert“.

    Noch einmal - in einer Krypto-Lib?
    Aber gut, ich verstehe langsam, was du meinst - wer kostenlose Krypto haben will, darf sich nicht wundern, wenn die kaputt ist ... ups .

    > Nein Heartbleed war: Wir benutzen einfachmal mal alle diesen
    > sicherheitskritischen Code bezahlen aber niemanden dafür, dass er da mal
    > rüberguckt.

    Einigen wir uns darauf, dass es beides war.

  18. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: Wissard 16.04.15 - 13:03

    Linuxschaden schrieb:
    > 2. Meinst du die Laufzeitumgebung von C, standardisiert seit C89.
    Nein, ich meine C-APIs im allgemeinen, da man diesen Unsinn überhall hin übernommen hat.
    > 3. Liegt das auch gar nicht an der Funktion. Genauso gut kannst du send
    > vorwerfen, dass man Pointer und Länge separat angeben muss. Genug Speicher
    > ist für den Response ja reserviert worden.
    Ja tue ich.

    > [langer text]
    Die Diskussion spare ich mich jetzt im Detail, aber: Es ist völlig unerheblich wo die Prüfung stattfindet. Wenn sie fehlerhaft ist führt das zum selben Ergebnis.

    > So, und was heißt das?

    > Das diese Programmierer die Finger davon lassen sollten, so etwas kritisches zu implementieren. Weil wir bei Netzwerk UND Krypto keine Dilettanten gebrauchen können. Punkt.

    Nein, das heißt, dass du etwas weniger respektlos sein und von deinem hohes Ross runterkommen solltest. Ich weiß nicht ob es dir klar ist, aber du beschimpft gerade alle, deren Produkte von Heartbleed betroffen waren, als Dilettanten. Und das ist so das who-is-who der IT-Branche ohne Microsoft. Es ist nämlich nicht nur der betreffende Programmierer schuld sondern auch der mangelhafte Review-Prozess und diejenigen die OpenSSL einfach benutzt haben ohne sich über die Qualität zu informieren.

    > Noch einmal - in einer Krypto-Lib?
    Warum sollte die Statistik vor einer Krypto-Lib halt machen? Du hast X Zeilen und davon hast du X-N Zeilen die Fehler enthalten. Ziel ist es dieses N möglichst niedrig zu halten.

    > Aber gut, ich verstehe langsam, was du meinst - wer kostenlose Krypto haben
    > will, darf sich nicht wundern, wenn die kaputt ist ... ups .
    Nein, mein Punkt ist, dass das jedem passieren kann, egal für wie gut du dich selbst hältst. Das muss man erkennen und daraus die Konsequenzen ziehen…



    2 mal bearbeitet, zuletzt am 16.04.15 13:09 durch Wissard.

  19. Re: m( - Wieso packt man sowas auch in den Kernel?

    Autor: the_wayne 24.04.15 - 14:18

    > Nein, mein Punkt ist, dass das jedem passieren kann, egal für wie gut du dich selbst hältst. Das muss man erkennen und daraus die Konsequenzen ziehen…

    Ack! Aber leider gibt es immer wieder Leute, die sich für was besseres halten. Und Fehler machen ja immer nur die anderen.

    Ich habe lange gebraucht um eine Firma zu finden, wo ich nicht mit solchen "Sheldon Cooper" zusammenarbeiten muss. Dieser Typ Mensch ist nämlich leider nur im TV lustig.

  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. Embedded Linux-Programmierer (m/w/d) Entwicklung
    wenglor MEL GmbH, Eching
  2. SAP Job - SAP BW / 4HANA Berater (m/w/x)
    über duerenhoff GmbH, München
  3. Team-Leiter:in (w/m/d) für die Informations- und Kommunikationstechnik
    Hochschule Aalen, Aalen
  4. (Junior) IT Business Partner / Demand Manager - Sales Units (m/w/d)
    Jungheinrich AG, Hamburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 399,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de