Quote from: Code29 on November 02, 2020, 06:13:12 PM

Quote from: bob123 on November 02, 2020, 02:37:09 PM

Keine Möglichkeit den Code zu verifizieren

Warum?

Weil Webseiten im Gegensatz zu herkömmlicher Software nicht vom Entwickler signiert sind und keine deterministischen Builds vorhanden sind.
Es hat keinen Sinn sich den Source Code auf Github etc. anzusehen, wenn du beim herunterladen der Website keine Garantie dafür hast, dass es sich tatsächlich um diesen Code handelt.

Hinzu kommen dann noch alle anderen Probleme die existieren wenn keine Signaturen vorhanden sind bzw. überprüft werden: Das herunterladen einer bösartigen Version (z.B. via DNS hijacking auf einen bösartigen Server umgeleitet).

Quote from: Code29 on November 02, 2020, 06:13:12 PM

Quote from: bob123 on November 02, 2020, 02:37:09 PM

Bösartige Manipulation des Codes (z.B. Zufallszahlengenerator)

Und bei anderer Software ist das nicht möglich?

Ist es.
Da die Builds aber deterministisch sind (ich rede hier ausschließlich von Open Source Software wie z.B. electrum), lässt sich einerseits so eine Änderung im Source code schnell entdecken und andererseits, falls nur die Binärdatei geändert wurde, herausfinden, dass Source Code und Binärdatei nicht übereinstimmen.

Bei Webseiten lässt sich das nicht so einfach herausfinden.

Quote from: Code29 on November 02, 2020, 06:13:12 PM

Quote from: bob123 on November 02, 2020, 02:37:09 PM

Code wurde bei der Übertragung oder auf deinem Rechner manipuliert

Ich kann auch eine Applikation austauschen.

Kannst du, natürlich.
Aber beim überprüfen der Signatur fällt sofort auf, dass was nicht stimmt und du kannst damit die Applikation verwerfen.
Bei einer Website fehlt dieser Kontrollmechanismus komplett.

Quote from: Code29 on November 02, 2020, 06:13:12 PM

Quote from: bob123 on November 02, 2020, 02:37:09 PM

Veraltete Bibliotheken wurden genutzt (können u.a. Schwachstellen bei Keygenerierung enthalten)

Das trifft sicherlich auf viele zu, muss aber nicht allgemein gelten. Ich bezweifel einfach mal, dass du jeden Generator daraufhin überprüft hast. Zumal wäre interessant um welche Schwachstellen es sich hier handelt. Oft sind diese Schwachstellen keine reelle Bedrohung. Das ist so wie wenn man über Schwachstellen bei Trezor liest und am Ende heißt es, dass ein Angreifer damit nur etwas anfangen kann wenn er 1. im Besitz des Trezors kommt und 2. kein Passwort gesetzt ist.

Natürlich habe ich nicht jeden Generator überprüft.
Aber bei sensitiven Operationen (Schlüsselgenerierung etc.) sollten niemals Javasacript verwendet werden. Gerade diese Bibliotheken sind oft sehr fehlerhaft und enthalten Schwachstellen welche unter anderem den Schlüsselraum einschränken und in der Tat eine reelle Bedrohung darstellen.
Gab auch schon einen Fall, in dem eine Javascript Bibliothek manipuliert wurde um BTC zu stehlen.

Zudem unterschätzt du glaube ich die Schwachstelle von Trezor.
Die Mehrheit der Nutzer verwendet kein zweites Passwort (BIP39 passwort-geschützten Seed). Die meisten verlassen sich auf die Hardware + Pin + Fakt, dass der Seed nach X Versuchen gelöscht wird.

Mit der Hardware Schwachstelle lässt sich jedoch der verschlüsselte Seed mittels Powerglitching vom Trezor extrahieren. Daraufhin kann die bis zu 9 Zeichen lange Pin gebruteforced werden.
Da hilft es nur noch zusätzlich ein BIP39 Passwort zu verwenden.
Das Problem beim Trezor One ist unter anderem, dass das Passwort über den Rechner (potentiell kompromittiert) eingegeben werden muss. Mit "verwendbar mit kompromittierten Geräten" hat das dann auch nicht mehr sehr viel zu tun.

Natürlich handelt es sich hierbei um eine lokal ausnutzbare Schwachstelle und keine, die über das Netzwerk (Internet) ausgenutzt werden kann. Dennoch sollte man sich dem bewusst sein.

Quote from: Code29 on November 02, 2020, 06:13:12 PM

Ganz so einfach ist es dann auch nicht. Aber ja, eine VM ist nicht unbedingt sicher wenn der Host kompromittiert ist. Eine VM ist dafür gedacht den Host vor der VM zu schützen und nicht umgekehrt, und selbst das ist nie garantiert (es könnte z.B. Schwachstellen in der Gasterweiterung bei VirtualBox geben).

Eine VM sollte nie als sicher angsehen werden, falls der Host kompromittiert ist.
Zu deinem 2. Punkt: Das stimmt. Es müsste sogar nicht mal eine Schwachstelle in der Gasterweiterung sein, gab auch schon kritische Schwachstellen in der Virtualisierung (wie u.a. auch in Browsern schon vorgekommen).