debianforum.de

MSfree hat geschrieben:Dumm nur, wenn irgenwo im verschlüsselten Datenstrom ein Bit umkippt, dann ergeben die Daten nach dem defekten Bit nur noch unsinnigen Blödsinn, während ein einzelnes defektes Bit in einem unverschlüsselten Textdokument nur in einem Schreibfehler resultiert oder ein defektes Pixel eines Digitalfotos erzeugt.

Das ist für alle mir bekannten Festplattenverschlüsslungen falsch:
Zuerstmal können auf festplatten Technik bedingt (crc überprüfung beim lesen.) nie einzelne Bits umkippen immer nur Blöcke (Typischerweise 512Byte. Bei neueren Platten 4kiB bei CDs ~200kiByte DVDs nochmal größer.)
Bei Blockverschlüsslungen im xts oder ecb modus gingen beim umkippen eines Bits (oder einem beliebig großer Teil in einem Block.) imme ein block, bei cbc zwei Blöcke kaputt. Im ctr, ofb oder cfb modus sogar nur das jeweilige Bit. Da kein Verschlüsslungsprogramme größere Blocklängen als 16Byte benuntzt. (Größere Blocklängen sind extrem inperformant. Deswegen wurden die 32Byte blocklängen aus Rijndael auch nicht in AES übernommen.) gingen im worst case also 32Byte verloren.
Da aus Perforancegründen die Crypto-Blöcke immer mit den (um ein vielfaches größeren) Festplattenblöcken aligned sind geht dir also praktisch nie mehr kaputt als eh kaputt ginge. (Einzige Ausnahme ist der cbc Modus. Wenn da 512Byte kaputt gehen geht der nachfolgende CBC Block mit drauf. Also 528 statt 512Byte.

Der Modus bei dem der von dir genannte Effekt auftritt ist PCBC. (Der wird hauptsächlich zum authentifizieren genutzt und ist extra darauf angelegt.) Das hat aber nie jemand für Festplattenverschlüsslung eingesetzt. (Insbesondere auch weil man da logischerweise zum entschlüsseln eines Bytes alle vorherigen lesen muss. (sonst könnte sich das ja nicht auf alle auswirken.) Kannst dir ja mal überlegen wie schön sich sowas auf ner Festplatte anfühlen würde.)

wanne hat geschrieben:Zuerstmal können auf festplatten Technik bedingt (crc überprüfung beim lesen.) nie einzelne Bits umkippen immer nur Blöcke (Typischerweise 512Byte. Bei neueren Platten 4kiB bei CDs ~200kiByte DVDs nochmal größer.)

CRC ist nicht sehr zuverlässig. OK, einzelne umgekippte Bits können erkannt werden, aber sobald 2 Bits in einem Plattensektor umkippen, hat man mit CRC oft verloren. Es ist jedenfalls kein Problem, für einen 1-Bit-Fehler ein zweites Bit zu berechnen, um die gleiche CRC zu bekommen wie mit den intakten Daten. In der Praxis habe ich solche Doppelbitfehler ohne CRC-Änderung jedenfalls schon mehrfach erlebt.

Bei Blockverschlüsslungen im xts oder ecb modus gingen beim umkippen eines Bits (oder einem beliebig großer Teil in einem Block.) imme ein block, bei cbc zwei Blöcke kaputt.

OK, ich war davon ausgegangen, daß die Verschlüsselung pro Datei stattfindet, und daß jedes Byte im Datenstrom von den vorangegangenen Daten abhängt. Vermutlich wird der Verschlüsselungsstrom also pro Dateisystemcluster (typischerweise 4kB oder 16kB) neu aufgesetzt, aber damit würde man dennoch deutlich mehr bei Bitverlusten verlieren als bei unverschlüsselten Daten.

Da kein Verschlüsslungsprogramme größere Blocklängen als 16Byte benuntzt.

16Byte (128Bit) ist aber extrem wenig. Eigentlich lese ich immer wieder was von mindestens 256Bit oder sogar 512Bit und dann wird so ein Cypherblock auch noch 3 mal angewendet, wie bei 3Des. Nun gut, es wird langsam etwas OT.

MSfree hat geschrieben:CRC ist nicht sehr zuverlässig. OK, einzelne umgekippte Bits können erkannt werden, aber sobald 2 Bits in einem Plattensektor umkippen, hat man mit CRC oft verloren. Es ist jedenfalls kein Problem, für einen 1-Bit-Fehler ein zweites Bit zu berechnen, um die gleiche CRC zu bekommen wie mit den intakten Daten. In der Praxis habe ich solche Doppelbitfehler ohne CRC-Änderung jedenfalls schon mehrfach erlebt.

OK. Geschenkt: Mit der Wahrscheinlichkeit 1:65000 gehen dir 32byte statt 2Bit Kaputt. Nimmt man jetzt an, dass im schnitt alle 4GiB ein Bit umkippt (Was eine extrem lausige Festplatte wäre.) Passiert das im Schnitt alle 1:9444732965739290427392 mal. Oder alle 8192 Exabyte. (Das ist um ein vielfaches mehr als je Daten durchs Internet gejagt wurden.) CRCs, die kollidieren gibt es nur bei zeug, dass wirklich große Fehlerraten hat. (Funkverbindungen sind ein bekanntes Beispiel, wo das schon viele schmerzhaft gemerkt haben.)

Verschlüsselungsstrom also pro Dateisystemcluster (typischerweise 4kB oder 16kB) neu aufgesetzt

Nein. Festplattenverschlüsslung sieht typischerweise die Ganze Festplatte als einen einzigen verschlüsselten strom aber damit würde man dennoch deutlich mehr bei Bitverlusten verlieren als bei unverschlüsselten Daten. (Lediglich im CBC mode wird die die Platte in teile zufälliger Länge eingeteilt.) Lediglich die annahme, dass ein einzelnes Bit im Cyphertext den gesamten Klartext verändert ist falsch. Das gilt eben nur im PCBC mode von block-ciphers. Bei stream-ciphers verändert sich immer nur ein Bit.

Eigentlich lese ich immer wieder was von mindestens 256Bit oder sogar 512Bit und dann wird so ein Cypherblock auch noch 3 mal angewendet, wie bei 3Des.

Das sind schlüssellängen. nicht Blocklängen. Prinzipiell könnte man 128Bit auf ~2⁷¹⁶ verschiedene Möglichkeiten verschlüsseln. Eine Verschlüsslung die alles aus 128Bit Blocklänge herausholt hätte also mindestens 717Bit. Defakto sind 128Bit per brute Force nicht zu knacken. (Wenn Moors Law weiter besteht in etwa 100 Jahren. Aber da kommen dann einige Physikalische Grenzen, die nicht so einfach zu überwinden sind.) Mehr Bit werden immer dann genutzt, wenn man sich gegen Angriffe schützen will, die besser als Bruteforce arbeiten. Das ist ganz normal dass man da ein zwei Bit verliert weil irgend jemand was besseres Findet, als nur durchzuprobieren. (Gegene Qutanencomputer auch gerne mal die Hälfte.) Wenn Leute es aber für nötig halten deutlich größere Schlüssel zu nehmen, dann stimmt da eher am Verschlüsslungsalgorithmus nicht. RSA ist so ein Beispiel. Da gibt es massig und immer bessere Angriffe drauf. Siehe https://de.wikipedia.org/wiki/Faktorisi ... ahrhundert . Mangels bewährter alternativen (ECC halten viele nicht für wirklich gebrauchsreif. und ist obendrein noch viel anfälliger gegen Quantenomputer als alles andere.) dreht man jetzt halt dauernd an der Schlüssellänge. Schon zur Einführung von pgp (1991) wurden mindestens 512Bit empfohlen. Das hat sich seither immer weiter erhöht. Ich nutze aktuell für pgp 4096Bit. Außerdem anfällig gegen Shor-Algorithmus. Der macht auf einem Quantencomputer mit 4096QBits aus den 4096Bit ca. 36 (Die aktuell größten Quantencomputer haben 4 oder 5 QBits)

Edit: IBM behautet einen mit 7QBits zu haben.

Und wo wir gerade bei Modi sind: Der letzte Verschlüsslungtrojaner, den ich in die Hand bekommen habe hat ecb genutzt. Da kann man versuchen Tebellen mit den Häufigsten Blöcken anzulegen, um Dateien wiederherzustellen. (Das hat in dem Fall zumindest mit ein paar Dateien funktioniert. Beruhte aber darauf, dass ein Backup von großen teilen der Daten vorhanden war.)

ist es mM vermutlich nur eine Frage der Zeit bis die gleich noch ein Exploit Kit für Linux Rechner mitnehmen...

Solange die Möglichkeit zum Schreiben besteht ist es egal womit ein "Sklave" betrieben wird.
Zur Zeit wird bei diesen Thema recht viel Clickbaiting mit sehr gefährlichen Halbwissen betrieben und damit die Panik so richtig geschürt.

Aluhut:
Die Leidtragenden sind zwar zur Zeit die Lemminge der M$ Welt aber das "Endgame" könnte eine ganz anderes Ergebnis haben. Die ganze Aktion könnte darin hinauslaufen das Opensource insbesondere die freie Verfügbarkeit gewisser Programme beschränkt/überwacht oder sogar aus "Sicherheitsgründen" verboten werden. Siehe "Hackertools"

Evox hat geschrieben:Solange die Möglichkeit zum Schreiben besteht ist es egal womit ein "Sklave" betrieben wird.

Deswegen beschränkt Android Lese- und Schreibzugriffe stark. Auf vielen Linux Servern ist zumindest letzteres auch üblich. (Wenn mein Webserver befallen werden würde, dürfte er genau keine Dateien auf der HDD editieren. Esseiden er legt vorher welche an ) Aber bei weitem nicht überall. Gerade wo PHP läuft, werden die Daten (wie hier im debianforum) ganz gerne vom Webserver angelegt. Entsprechend ist nicht sonderlich verwunderlich, dass gerade PHP so gerne angegriffen wird.
Für Inhalte mit Interaktionen ist da auch nicht anders möglich. Wo Kommentare geschrieben werden, müssen die ja irgend wie geschrieben werden. (Leider kennt Linux ohne Krücken keinen unterschied zwischen ändern und anhängen. Das ist auf anderen Systemen anders.)

Aber bei weitem nicht überall. Gerade wo PHP läuft, werden die Daten (wie hier im debianforum) ganz gerne vom Webserver angelegt. Entsprechend ist nicht sonderlich verwunderlich, dass gerade PHP so gerne angegriffen wird

Mein Prinzip ist, alles Verbieten und nur nach wirklichen Bedarf erlauben.
Aus diesen Grund hat der "Webuser" generell nur eingeschränkte Leserechte gepaart mit noexec. Bei Schreibbedarf wird vorher genau geschaut wo/wann er beschreiben/ändern muss und nur genau dort bekommt er das Recht. Mag für den einen oder anderen nach "Aluhut stinken" oder kompliziert anhören aber der "Aufwand" lohnt sich wirklich.

Für Inhalte mit Interaktionen ist da auch nicht anders möglich.

Auf die hat ers ja auch abgesehen. Der Erpresser hat geringes Interesse daran die Software selbst, welche man einfach neu installieren kann anzufassen. Natürlich gibt es andere Ziele von Angreifern wo das sehr wohl ein Rolle spielt aber darum gehts ja in dem Thread jetzt nicht.

Wo Kommentare geschrieben werden, müssen die ja irgend wie geschrieben werden. (Leider kennt Linux ohne Krücken keinen unterschied zwischen ändern und anhängen. Das ist auf anderen Systemen anders.)

Wobei man da meistens auf Datenbanken setzt welche das sehr wohl bieten. Außerdem könnte Linux das durchaus (wann man das sinnvoll verwenden könnte ist die andere Frage):

CHATTR(1) hat geschrieben:A file with the 'a' attribute set can only be open in append mode for writing. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Man kann aber auch damit nicht alles schützen. Das sinnvollste speziell gegen diese Art von Angriff dürfte immer noch sein Kopien der Daten vorzuhalten (Snapshots,Backups) welche der entsprechende User nicht schreibend zugreifen kann.

Weils mir gerade untergekommen ist: Das schaut auch nicht so falsch aus: http://www.heise.de/security/artikel/Er ... 20956.html