Sorry, aber ist das deren Ernst?

[erlenmayr]

> Run the following in your terminal, then follow the onscreen instructions.
> curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
https://rustup.rs/

Sowas kommt mir auf keine produktive Kiste!

[Vanger]

erlenmayr schrieb:
--------------------------------------------------------------------------------
> > Run the following in your terminal, then follow the onscreen
> instructions.
> > curl --proto '=https' --tlsv1.2 -sSf sh.rustup.rs | sh
> rustup.rs
>
> Sowas kommt mir auf keine produktive Kiste!

curl --proto '=https' --tlsv1.2 -sSf -o rustup.sh https://sh.rustup.rs
vim rustup.sh
sh rustup.sh

Ich kann aber ehrlich gesagt kein Problem erkennen. Solange du nicht jede Codezeile auf deinem System tatsächlich immer selbst prüfst - auch bei Updates - läuft die Diskussion letztendlich darauf hinaus, wem du vertraust. Vertraust du allen Package Maintainern deiner Distribution? Wir sprechen da schnell über hunderte Menschen - und da unterstellen wir schon, dass Package Maintainer immer den Code prüfen würden. Tatsächlich kaskadiert das Vertrauen bis runter zum einzelnen Entwickler. rustup.rs ist die offizielle Quelle und nicht irgend ein Stack Overflow Thread. Das Skript durchläuft die exakt gleichen Prozesse wie Rust selbst auch - und dadurch, dass HTTPS erzwungen wird, ist auch der Transport sicher. Woher kommen also die Bedenken? Mal davon abgesehen, dass man möglicherweise keine Software abseits der Paketverwaltung installieren möchte um den Vermüllungs-Effekt zu reduzieren, aber das ist eine gänzlich andere Diskussion.

[MarcusK]

Vanger schrieb:
--------------------------------------------------------------------------------
> erlenmayr schrieb:
> ---------------------------------------------------------------------------
> -----
> > > Run the following in your terminal, then follow the onscreen
> > instructions.
> > > curl --proto '=https' --tlsv1.2 -sSf sh.rustup.rs | sh
> > rustup.rs
> >
> > Sowas kommt mir auf keine produktive Kiste!
>
> curl --proto '=https' --tlsv1.2 -sSf -o rustup.sh sh.rustup.rs
> vim rustup.sh
> sh rustup.sh
>
> Ich kann aber ehrlich gesagt kein Problem erkennen. Solange du nicht jede
> Codezeile auf deinem System tatsächlich immer selbst prüfst - auch bei
> Updates - läuft die Diskussion letztendlich darauf hinaus, wem du
> vertraust. Vertraust du allen Package Maintainern deiner Distribution? Wir
> sprechen da schnell über hunderte Menschen - und da unterstellen wir schon,
> dass Package Maintainer immer den Code prüfen würden. Tatsächlich
> kaskadiert das Vertrauen bis runter zum einzelnen Entwickler. rustup.rs ist
> die offizielle Quelle und nicht irgend ein Stack Overflow Thread. Das
> Skript durchläuft die exakt gleichen Prozesse wie Rust selbst auch - und
> dadurch, dass HTTPS erzwungen wird, ist auch der Transport sicher. Woher
> kommen also die Bedenken? Mal davon abgesehen, dass man möglicherweise
> keine Software abseits der Paketverwaltung installieren möchte um den
> Vermüllungs-Effekt zu reduzieren, aber das ist eine gänzlich andere
> Diskussion.

Es reicht schon wenn durch einen dummen Fehler die Domain in falsche Hände kommt, da hilft auch ein TLS. (Dafür gab es schon beispiele).

Und Böswillige könnte wieder mal ins Routing eingreifen und schnell auch ein passenden Zertifikat anlegen - alles nicht wirklich ein Problem.

Da ist ein Signierte Paket wo die Schlüssel bei den wirklichen Autoren sind, doch deutlich sicherer.

[Vanger]

MarcusK schrieb:
--------------------------------------------------------------------------------
> Es reicht schon wenn durch einen dummen Fehler die Domain in falsche Hände
> kommt, da hilft auch ein TLS. (Dafür gab es schon beispiele).

Das exakt gleiche Problem hast du bei Paketen aus der Paketverwaltung auch: Der Source Code muss ja irgendwie auf das Build System kommen.

> Und Böswillige könnte wieder mal ins Routing eingreifen und schnell auch
> ein passenden Zertifikat anlegen - alles nicht wirklich ein Problem.

Aha. Das musst du jetzt aber schon erklären wie das funktionieren soll. Das wäre nämlich neu. Die mediale Aufmerksamkeit wäre dir auch sicher, dann hättest du nämlich bewiesen, dass wir HTTPS abschalten können.

> Da ist ein Signierte Paket wo die Schlüssel bei den wirklichen Autoren
> sind, doch deutlich sicherer.

Wer sind denn die "wirklichen Autoren"? Tatsächlich sprichst du von den Package Maintainern, was uns letztendlich nur wieder zur Diskussion "Wem vertraust du" zurück bringt. Nochmal: rustup.rs ist die offizielle Webseite des Projekts. Kein Stack Overflow Thread.

[Wuestenschiff]

Ja so läuft das heutzutage.. Seufz...

Aber mal ehrlich beser als die meisten.. Oft hats da dann noch ein sudo im command

[aa]

erlenmayr schrieb:
--------------------------------------------------------------------------------
> Sowas kommt mir auf keine produktive Kiste!

forge [.] rust-lang [.] org [/] infra/other-installation-methods.html#standalone

Inklusive PGP Signatur.

[erlenmayr]

Sorry, aber bei Debian und Co. gibt es transparente Prozesse. Da kann nicht einfach jeder Maintainer irgendwas unbemerkt hochladen.

Solche externen Depdency Manager wie NPM und Co., die für Entwicklerzwecke zwar sehr praktisch sind, machen es in produktiven Umgebungen praktisch komplett unmöglich, irgendeine Kontrolle über die Supply Chain zu haben.

[MarcusK]

Vanger schrieb:
--------------------------------------------------------------------------------
> MarcusK schrieb:
> ---------------------------------------------------------------------------
> -----
> > Es reicht schon wenn durch einen dummen Fehler die Domain in falsche
> Hände
> > kommt, da hilft auch ein TLS. (Dafür gab es schon beispiele).
>
> Das exakt gleiche Problem hast du bei Paketen aus der Paketverwaltung auch:
> Der Source Code muss ja irgendwie auf das Build System kommen.
>
> > Und Böswillige könnte wieder mal ins Routing eingreifen und schnell auch
> > ein passenden Zertifikat anlegen - alles nicht wirklich ein Problem.
>
> Aha. Das musst du jetzt aber schon erklären wie das funktionieren soll. Das
> wäre nämlich neu. Die mediale Aufmerksamkeit wäre dir auch sicher, dann
> hättest du nämlich bewiesen, dass wir HTTPS abschalten können.

https://winfuture.de/news,83067.html

einfach mal nach BGP-Hijacking suchen, gab da schon mehrere vorfälle.

[felix.schwarz]

Vanger schrieb:
> Das exakt gleiche Problem hast du bei Paketen aus der Paketverwaltung auch:
> Der Source Code muss ja irgendwie auf das Build System kommen.

Idealerweise wird der Weg aber durch GPG-Signaturen abgesichert. Bei Fedora "sollte" es so sein, dass der Paketbau automatisch fehlschlägt, falls die tarball-Signatur nicht zu den für dieses Paket hinterlegten GPG-Schlüsseln passt.

Das setzt natürlich voraus, dass das Upstream-Projekt seine Releases signiert und dass der Fedora Maintainer das auch eingebaut hat. Ansonsten bliebe immer noch die Hoffnung, dass der Maintainer sich zumindest mal grob den diff einer neuen Version anschaut (mache ich bei kleineren Paketen).

PS: Fedora nur hier als Beispiel, weil ich es am besten kenne. Ähnliches gibt es auch bei Debian usw.

[Vanger]

MarcusK schrieb:
--------------------------------------------------------------------------------
> > > Und Böswillige könnte wieder mal ins Routing eingreifen und schnell
> auch
> > > ein passenden Zertifikat anlegen - alles nicht wirklich ein Problem.
> >
> > Aha. Das musst du jetzt aber schon erklären wie das funktionieren soll.
> Das
> > wäre nämlich neu. Die mediale Aufmerksamkeit wäre dir auch sicher, dann
> > hättest du nämlich bewiesen, dass wir HTTPS abschalten können.
>
> winfuture.de
>
> einfach mal nach BGP-Hijacking suchen, gab da schon mehrere vorfälle.

Es ging auch nicht darum wie man das Routing angreift. Es ging darum wie man das Routing angreift und gleichzeitig ein gefälschtes Zertifikat dafür bekommt. Ich bin gespannt...

[MarcusK]

Vanger schrieb:
--------------------------------------------------------------------------------
> MarcusK schrieb:
> ---------------------------------------------------------------------------
> -----
> > > > Und Böswillige könnte wieder mal ins Routing eingreifen und schnell
> > auch
> > > > ein passenden Zertifikat anlegen - alles nicht wirklich ein Problem.
> > >
> > > Aha. Das musst du jetzt aber schon erklären wie das funktionieren
> soll.
> > Das
> > > wäre nämlich neu. Die mediale Aufmerksamkeit wäre dir auch sicher,
> dann
> > > hättest du nämlich bewiesen, dass wir HTTPS abschalten können.
> >
> > winfuture.de
> >
> > einfach mal nach BGP-Hijacking suchen, gab da schon mehrere vorfälle.
>
> Es ging auch nicht darum wie man das Routing angreift. Es ging darum wie
> man das Routing angreift und gleichzeitig ein gefälschtes Zertifikat dafür
> bekommt. Ich bin gespannt...

das ist überhaupt nicht spannend. Man ändert das Routing und beantragt dann über Lets-encrypt ein neues Zertifikat. Das man den notwendigen key auf seinen eigenen Webserver ablegen kann.

[erlenmayr]

Bei Debian liegt auch alles mit PGP-Signatur als Orig-Tarball plus Patch-Tarball auf dem FTP-Server und kann von jedem überprüft werden. Es ist also völlig egal, wer sonst auf dem Server schreibt oder ob man irgendeinen Mirror benutzt.

Beispiel: Das Paket rustc wird gebaut aus rustc_1.62.1+dfsg1-1_amd64.deb
http://deb.debian.org/debian/pool/main/r/rustc/rustc_1.62.1+dfsg1-1.dsc
http://deb.debian.org/debian/pool/main/r/rustc/rustc_1.62.1+dfsg1.orig.tar.xz
http://deb.debian.org/debian/pool/main/r/rustc/rustc_1.62.1+dfsg1-1.debian.tar.xz

Bei Paketen, wo Upstream auch signiert wird, sind auch beide Signaturen dabei. Beispiel:
http://deb.debian.org/debian/pool/main/g/gnupg2/gnupg2_2.2.40-1.dsc
http://deb.debian.org/debian/pool/main/g/gnupg2/gnupg2_2.2.40.orig.tar.bz2
http://deb.debian.org/debian/pool/main/g/gnupg2/gnupg2_2.2.40.orig.tar.bz2.asc
http://deb.debian.org/debian/pool/main/g/gnupg2/gnupg2_2.2.40-1.debian.tar.xz



$ gpg --verify gnupg2_2.2.40.orig.tar.bz2.asc
gpg: assuming signed data in 'gnupg2_2.2.40.orig.tar.bz2'
gpg: Signature made Mon 10 Oct 2022 02:40:37 PM CEST
gpg: using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA
gpg: Good signature from "Werner Koch (dist signing 2020)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA



$ gpg --verify gnupg2_2.2.40-1.dsc
gpg: Signature made Wed 19 Oct 2022 05:37:15 PM CEST
gpg: using EDDSA key 2DB5491C9DF0DC8F432863CF3E9D717371DE565C
gpg: Good signature from "Daniel Kahn Gillmor" [unknown]
gpg: aka "<[e-mail]>" [unknown]
gpg: aka "<[e-mail]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: C29F 8A0C 01F3 5E34 D816 AA5C E092 EB3A 5CA1 0DBA
Subkey fingerprint: 2DB5 491C 9DF0 DC8F 4328 63CF 3E9D 7173 71DE 565C

[Vanger]

MarcusK schrieb:
--------------------------------------------------------------------------------
> Vanger schrieb:
> ---------------------------------------------------------------------------
> -----
> > MarcusK schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > > > Und Böswillige könnte wieder mal ins Routing eingreifen und
> schnell
> > > auch
> > > > > ein passenden Zertifikat anlegen - alles nicht wirklich ein
> Problem.
> > > >
> > > > Aha. Das musst du jetzt aber schon erklären wie das funktionieren
> > soll.
> > > Das
> > > > wäre nämlich neu. Die mediale Aufmerksamkeit wäre dir auch sicher,
> > dann
> > > > hättest du nämlich bewiesen, dass wir HTTPS abschalten können.
> > >
> > > winfuture.de
> > >
> > > einfach mal nach BGP-Hijacking suchen, gab da schon mehrere vorfälle.
> >
> > Es ging auch nicht darum wie man das Routing angreift. Es ging darum wie
> > man das Routing angreift und gleichzeitig ein gefälschtes Zertifikat
> dafür
> > bekommt. Ich bin gespannt...
>
> das ist überhaupt nicht spannend. Man ändert das Routing und beantragt dann
> über Lets-encrypt ein neues Zertifikat. Das man den notwendigen key auf
> seinen eigenen Webserver ablegen kann.

Aha. Das musst du glaube ich mal Let's Encrypt erklären, die finden das sicher äußerst spannend welche neuen Erkenntnisse du da gesammelt hast wie einfach das ist!

Nein, jetzt mal im Ernst, das ist ja irgendwie ganz lustig wie du im Dunkeln herumstolperst und bei der Suche nach dem Lichtschalter gegen jedes Möbelstück stößt, aber so funktioniert das nicht. Du kannst nicht "mal eben" die Routen von sowohl deinem Opfer, als auch Let's Encrypt manipulieren. Eine Instanz, ja, das lässt sich bewerkstelligen - sprich: wie im WinFuture Artikel erläutert benötigst du einen Insider im ISP des Opfers und kannst dann die Routen des Opfers zum rustup.rs Server manipulieren. Ein gültiges Zertifikat hast du dann aber noch nicht - dazu müsstest du auch die Routen von Let's Encrypt zum rustup.rs Server manipulieren. Das wird dir nicht gelingen. Let's Encrypt ist dieses Gefahrenpotenzial durchaus bekannt, weshalb sie Maßnahmen ergriffen haben: So musst du tatsächlich nicht nur die Routen von Let's Encrypt manipulieren, sondern die von zahlreichen über die ganze Welt verteilten Cloud Dienstleistern. Viel Spaß dabei das "mal eben" zu bewerkstelligen... https://letsencrypt.org/2020/02/19/multi-perspective-validation.html

[MarcusK]

Vanger schrieb:
--------------------------------------------------------------------------------
> MarcusK schrieb:
> ---------------------------------------------------------------------------
> -----
> > Vanger schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > MarcusK schrieb:
> > >
> >
> ---------------------------------------------------------------------------
>
> >
> > > -----
> > > > > > Und Böswillige könnte wieder mal ins Routing eingreifen und
> > schnell
> > > > auch
> > > > > > ein passenden Zertifikat anlegen - alles nicht wirklich ein
> > Problem.
> > > > >
> > > > > Aha. Das musst du jetzt aber schon erklären wie das funktionieren
> > > soll.
> > > > Das
> > > > > wäre nämlich neu. Die mediale Aufmerksamkeit wäre dir auch sicher,
> > > dann
> > > > > hättest du nämlich bewiesen, dass wir HTTPS abschalten können.
> > > >
> > > > winfuture.de
> > > >
> > > > einfach mal nach BGP-Hijacking suchen, gab da schon mehrere
> vorfälle.
> > >
> > > Es ging auch nicht darum wie man das Routing angreift. Es ging darum
> wie
> > > man das Routing angreift und gleichzeitig ein gefälschtes Zertifikat
> > dafür
> > > bekommt. Ich bin gespannt...
> >
> > das ist überhaupt nicht spannend. Man ändert das Routing und beantragt
> dann
> > über Lets-encrypt ein neues Zertifikat. Das man den notwendigen key auf
> > seinen eigenen Webserver ablegen kann.
>
> Aha. Das musst du glaube ich mal Let's Encrypt erklären, die finden das
> sicher äußerst spannend welche neuen Erkenntnisse du da gesammelt hast wie
> einfach das ist!
>
> Nein, jetzt mal im Ernst, das ist ja irgendwie ganz lustig wie du im
> Dunkeln herumstolperst und bei der Suche nach dem Lichtschalter gegen jedes
> Möbelstück stößt, aber so funktioniert das nicht. Du kannst nicht "mal
> eben" die Routen von sowohl deinem Opfer, als auch Let's Encrypt
> manipulieren. Eine Instanz, ja, das lässt sich bewerkstelligen - sprich:
> wie im WinFuture Artikel erläutert benötigst du einen Insider im ISP des
> Opfers und kannst dann die Routen des Opfers zum rustup.rs Server
> manipulieren. Ein gültiges Zertifikat hast du dann aber noch nicht - dazu
> müsstest du auch die Routen von Let's Encrypt zum rustup.rs Server
> manipulieren. Das wird dir nicht gelingen. Let's Encrypt ist dieses
> Gefahrenpotenzial durchaus bekannt, weshalb sie Maßnahmen ergriffen haben:
> So musst du tatsächlich nicht nur die Routen von Let's Encrypt
> manipulieren, sondern die von zahlreichen über die ganze Welt verteilten
> Cloud Dienstleistern. Viel Spaß dabei das "mal eben" zu bewerkstelligen...
> letsencrypt.org

Es wurde doch schon so gemacht, ich verstehen nicht was du daran nicht glauben willst?

https://freedom-to-tinker.com/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/

hier stehen noch ein paar mehr Infos

[unfinity]

MarcusK schrieb:
> Es wurde doch schon so gemacht, ich verstehen nicht was du daran nicht glauben willst?
> freedom-to-tinker com/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/

Danke für den Link, MarcusK. War sehr spannend zu lesen, insbesondere folgender Teil am Ende, wo ein Schutz gegen das vorgefallene Problem vorstestellt wurde:
> we have actively been working on developing defenses against it. The defense that has had the biggest impact (that our group developed in our 2018 USENIX Security paper) is known as multiple vantage point domain control verification.

Ist das nicht genau das Verfahren, das Vanger zuvor erwähnte?
> So musst du tatsächlich nicht nur die Routen von Let's Encrypt manipulieren, sondern die von zahlreichen über die ganze Welt verteilten Cloud Dienstleistern. Viel Spaß dabei das "mal eben" zu bewerkstelligen...
> letsencrypt org/2020/02/19/multi-perspective-validation.html

Die in deinem Link angegriffene CA war übrigens ZeroSSL. Der verlinkte Artikel sagt auch
> Currently, Let’s Encrypt is the only certificate authority using multiple vantage point validation

Somit sollte (zumindest letsencrypt) diesen bekannten Angriff deutlich erschweren, oder?

Noch eine Bitte in eigener Sache: Wäre schön wenn nicht unnötig (lange) zitiert wird, damit dieser Thread lesbar bleibt.



6 mal bearbeitet, zuletzt am 12.02.23 21:53 durch unfinity.