Einloggen
[c] [test] [fefe]

/fefe/ – Fefes Kommentarfunktion


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] Bug des Tages: Komisch, wieso sind denn die Bytes in ... Effe ## Mod Tue, 12 Oct 2021 14:08:56 GMT Nr. 61377
    JPG 800×584 152.2k
    Bug des Tages: Komisch, wieso sind denn die Bytes in meinem RSA-Schlüssel alles Nullen? [0]

    You had me at "lass uns Krypto in Javascript machen!1!!"

    [0] https://github.com/juliangruber/keypair/security/advisories/GHSA-3f99-hvg4-qjwj

    https://blog.fefe.de/?ts=9f9b5521
  • [l] Felix Tue, 12 Oct 2021 14:31:36 GMT Nr. 61380
    Sehr vertrauenerweckendes Pflaster:
    var crypto;
    try {
      crypto = require('crypto');
    } catch (_) {}
    

    crypto im Fehlerfall undefiniert statt null, ja?
  • [l] Felix Tue, 12 Oct 2021 14:38:54 GMT Nr. 61381
    >>61377
    Wohlgemerkt nicht die Schlüssel selber, welche wenigstens den Primzahltest bestehen müssen, aber der somit stark eingeschränkte Startwert für den Pseudo-Zufallszahlengenerator.
    247 von 256 möglichen Zeichen führen zu null (weil String.fromCharCode für Nicht-Zahlwerte einfach "\u0000" zurückgibt), nur '1'...'9' werden zu 1 bis 9.
  • [l] Felix Tue, 12 Oct 2021 14:56:48 GMT Nr. 61382
    >>61380
    Das beste ist, dass die Variable crypto davor überhaupt nicht auf etwas anderes außer null (genauso boolesch falsch wie undefined) gesetzt wurde. Ausnutzung des Krypto-Moduls in node.js war offenbar geplant, aber bis dato nie umgesetzt.
    Das heißt, der Code hat immer diesen kaputten PRNG herangezogen, solange er nicht in einem Browser lief, wo stattdessen window.crypto.getRandomValues verfügbar war.
  • [l] Felix Tue, 12 Oct 2021 15:19:14 GMT Nr. 61384
    >>61381
    Naja, ob der Schlüssel jetzt 0 oder Hash(0) ist macht auch nur wenig Unterschied. Machts vielleicht sogar noch schlimmer, da das erste wenigstens schneller auffällt.
  • [l] Felix Tue, 12 Oct 2021 16:20:05 GMT Nr. 61389
    Geht ja schon bei der README.md los:
    https://github.com/juliangruber/keypair/blob/master/README.md
    > Pro Tip: authorized_keys
    > @maxogden found out how to use this module to create entries for the authorized_keys file:

    Ja, ähm, ihr als Entwickler wisst nicht mal, wie eure Software funktioniert? Irgend ein User hat durch Zufall herausgefunden, wie er was mit eurer Software machen kann, oder wie? Ich hab bisher zwar noch nie mit JS gearbeitet, aber die zwei Zeilen reichen mir schon, um mich auch in Zukunft gegen JS zu entscheiden.
  • [l] Felix Tue, 12 Oct 2021 21:48:42 GMT Nr. 61412
    >>61389
    Das ist nur wahr, wenn dein Kottkönnen auf diesem Niveau gipfelt:

    10 PRINT "HOMOFÜRST"
    20 GOTO 10

  • [l] Felix Wed, 13 Oct 2021 05:38:34 GMT Nr. 61423
    >>61381
    Primzahltest ist nur einer von sehr vielen Tests, die ein RSA-Schlüssel durchmachen muß.
  • [l] Felix Wed, 13 Oct 2021 05:47:42 GMT Nr. 61430
    Ich glaube, das Problem von dem Code ist, daß er effektiv String.fromCharCode(String.fromCharCode(next & 0xFF)) statt String.fromCharCode(next & 0xFF) ausführt. Das geht aus der schlechten Beschreibung des Bugs nicht so einfach hervor. Das sieht man aber, wenn man den Commit anschaut.

    https://github.com/juliangruber/keypair/commit/9596418d3363d3e757676c0b6a8f2d35a9d1cb18

    Daß die Zufallszahlen nichts taugen ist auch wahr, aber unabhängig von diesem Bugreport.
  • [l] Felix Wed, 13 Oct 2021 05:50:04 GMT Nr. 61431
    >>61430
    Ich hasse JavaScript, aber sowas hätte in jeder Sprache passieren können. Man stelle sich zum Beispiel vor:
    char_to_string(char_to_string(byte))
    statt
    char_to_string(byte)
    in C.
  • [l] Felix Wed, 13 Oct 2021 08:14:02 GMT Nr. 61435
    >>61431
    >sowas hätte in jeder nicht typsicheren Sprache passieren können.
    Hab das mal fixiert.

    In einer vernünftig konstruierten Sprache würde schon der Kompilierversuch scheitern, wenn einer Funktion, die einen Ganzzahltyp erwartet, eine Zeichenkette übergeben werden soll. Ohne statische Typisierung würde zumindest der Aufruf mit einem Typfehler enden.
  • [l] Felix Wed, 13 Oct 2021 08:26:12 GMT Nr. 61438
    JPG 318×321 26.8k
    >>61412
    >MAMI, DA MAG JEMAND MEINE PHANTASIESPRACHE NICHT!
    Fixiert.
  • [l] Felix Wed, 13 Oct 2021 08:31:15 GMT Nr. 61439
    >>61430
    Schon schade, dass das Security Advisory keinen Abschnitt "Additional Details" hat, wo man die Problematik so kurz zusammengefasst finden könnte.

    >>61431
    Mit C oder jeder anderen stark typisierten Sprache wäre zumindest die Schnittstelle klarer, wie man ein einzelnes Byte an einen Buffer anhängt – wenn man ein char* für einen char- bzw. int-Parameter übergibt, meckert zumindest der Compiler.
    Ansonsten wurde String.fromCharCode nicht für diesen Zweck geschaffen, einen Byte- durch einen Unicode-String hindurch zu schmuggeln. Weil fromCharCode("42") erlaubt ist, kann fromCharCode("*") aus unbekannten Gründen nicht einfach mit einem TypeError o. ä. scheitern. (Laut Quellcode populärer JS-Implementationen verbleibt der dahinterstehende uint16 einfach auf null, wenn die Konvertierung scheitert.)
    Im Übrigen ist das Problem auch mit typisierten Arrays nicht gelöst:
    >> var u = new Uint8Array(100)
    >> u[0] = 42
    << 42
    >> u[0]
    << 42
    >> u[0] = "*"
    << "*"
    >> u[0]
    << 0

  • [l] Felix Wed, 13 Oct 2021 10:59:27 GMT Nr. 61455
    >>61439
    >Weil fromCharCode("42") erlaubt ist, kann fromCharCode("*") aus unbekannten Gründen nicht einfach mit einem TypeError o. ä. scheitern.
    Das ist halt der Javascript-Krebs #1, dass bei allen erdenklichen Operationen immer das rauskommt, was der verantwortliche Frickler vielleicht gemeint haben könnte. Häufig stimmt das halt nicht und du bekommst ein falsches Ergebnis, ohne echte Chance herauszufinden wo der Bug in deinem Kot jetzt ist.
  • [l] Felix Wed, 13 Oct 2021 14:40:01 GMT Nr. 61470
    >>61439
    Das ist korrekt. JavaScript ist hier besonders scheiße, weil es still einfach tut.
  • [l] Felix Wed, 13 Oct 2021 14:53:02 GMT Nr. 61474
    Insbesondere fällt auf, dass selbst als Müll verschriene Sprachen an dieser Stelle inzwischen weiter sind.
    PHP 7.4 hat z. B. chr(keine_zahl) zu einer Warnmeldung hochgestuft (so wie alle eingebauten Funktionen, die einen Zahlwert akzeptieren) und 8.0 zu einem TypeError eskaliert. (Die Unicode-Schwesterfunktion mb_chr gibt hingegen im Fehlerfall nur FALSE zurück, was bekanntermaßen unter den falschen Umständen als 0 interpretiert werden könnte. Aber wenigstens gilt dann mb_chr(FALSE) === ''.)
  • [l] Felix Wed, 13 Oct 2021 15:48:41 GMT Nr. 61482 SÄGE
    >>61474
    Korrektur: mb_chr existiert erst seit PHP 7.2 und hat immer mindestens eine Warnmeldung ausgegeben, wenn kein Zahlwert übergeben wurde.
  • [l] Felix Thu, 14 Oct 2021 09:22:19 GMT Nr. 61514
    >>61474
    >Insbesondere fällt auf, dass selbst als Müll verschriene Sprachen an dieser Stelle inzwischen weiter sind.
    C hat dieses (oder ähnliches) Problem aber auch. Implizite Konvertierung zwischen Typen.
    <https://www.openwall.com/lists/oss-security/2021/07/20/1
    Gut, es ist nicht ganz dasselbe, denn es ist auf der Ebene der Hochsprache kein logischer Fehler, wie in der JS-crypto-Geschichte.
    Aber die beiden Probleme sind doch erschreckend verwandt, ein kleines Itzelchen arkanen Wissens ging verlustig.


[Zurück]
[c] [test] [fefe]