Sicherheitslücke in apt

[OrangeJuice]

Sollte man aufgrund des Fehler, wenn man Debian per NetInstall installiert hat, mit dem neuen Image die Installation erneut machen?

[novalix]

Sollte man aufgrund des Fehler, wenn man Debian per NetInstall installiert hat, mit dem neuen Image die Installation erneut machen?

Ne, auf keinen Fall. Ein Upgrade mit den Fixes reicht völlig aus.
Du solltest aber für den Fall, dass Du weitere Rechner mit Debian ausrüsten willst, das gefixte Image benutzen.

[Glur]

Wie installiert man eigentlich Windows, wenn es nicht vorinstalliert ist? Ich glaube ich werde alt.

Medium (CD oder USB-Stick) rein, booten, durchklicken, neustarten.... Auch nicht viel schwieriger als ein handelsübliches Linux.

[irianx]

Hi. Habe ich das richtig erfasst?
Das aktuelle alt (und apt-get) hat eine Lücke. Ein man-in-the-middle konnte damit bei jedem ausgeführen apt -Befehl auf jedem Debian PC ein beliebiges Kommando als root zur Ausführung unterschieben? [Paranoia an] Da nsx u.a. Wissensbegierig einrichtungen über Jahre hinweg die zentralen internetknoten überwacht haben (und potentiell auch den Datenverkehr manipulieren konnten), ist es denkbar, dass nahezu allen apt-nutzern ein root-kit untergeschoben wurde? [Paranoia aus] ... Ich will nicht trollen, möchte nur die potentielle Reichweite einschätzen. Rootkits würde man nur mittels Neuinstallation weg bekommen; außer das rootkit wurde ins uefi geschrieben. [Paranoia wirklich aus]. ???

[albundy]

Wie installiert man eigentlich Windows, wenn es nicht vorinstalliert ist? Ich glaube ich werde alt.

Medium (CD oder USB-Stick) rein, booten, durchklicken, neustarten.... Auch nicht viel schwieriger als ein handelsübliches Linux.

Wann und wo bitte habe ich das denn geschrieben? Zitat falsch gelaufen?

@Glur
Wir auch immer du es geschafft hast, aber du hast mich falsch zitiert. Guck mal:
viewtopic.php?f=1&t=172027&p=1196254&hi ... t#p1196254

Das hatte @uname geschrieben!

[jph]

Das Projekt hat m.E. vorbildlich reagiert und ad hoc Debian 9.7 herausgeschoben. Einzige Änderung gegenüber 9.6: gefixtes apt, damit die Installationsimages sauber sind.

[Glur]

Oh ja, da ist wohl irgendwas schief gegangen... Sorry

[debianuser4782]

Nun ist eine Diskussion über https bei apt entfacht.

Zu Verschlüsselung habe ich eine eigene Meinung. Ich halte es in diesem Fall für gefährlich, anzunehmen, daß man mit HTTPS keine Redirects einbauen könnte. Der Fehler wäre durch HTTPS nicht vermeidbar gewesen, er wäre nur dank Verschlüsselung erst viel später aufgefallen und die "bösen Jungs" hätten mehr Zeit gehabt, echten Schaden anzurichten.

Bzw für die Zukunft: Ist hier eine Verwendung von onion-services eine Alternative zu https?

In wiefern schützt TOR vor Redirects? Wie soll HTTPS vor Redirects schützen?
OK, das Redirect-Problem wurde jetzt sowieso geflickt, aber der nächste Fehler lauert bestimmt schon. Meiner Meinung sind HTTPS und TOR nur Security by Obscurity, schützen letzten Endes also nicht. Unverschlüsselte Verbindungen könnte jeder (ganz nach dem Open Source Gedanken) mit einfachsten Mitteln wie tcpdump oder den Logs, die squid produziert, selbst kontrollieren, Verschlüsselung macht das so gut wie unmöglich.

Bitte nicht mißverstehen. Bei meinen Onlinebestellungen möchte ich meine Kreditkartendaten auch nicht unverschlüsselt übertragen wissen.

Onlinebanking betreibe ich sowieso nicht, weil mir bewußt ist, daß man vor allem im Bankensektor mit HTTPS nur Sicherheit vortäuschen will. Die Banken haben eine lange Tradition darin, technische Unzulänglichkeiten juristisch als "sicher" deklarieren zu lassen. Ja, wenn ein Jurist sagt, das ist sicher, dann wird das wohl stimmen. Beispiel?
https://de.wikipedia.org/wiki/Chaos_Com ... b#Btx-Hack

Ja, die Erwägungen leuchten ein.

Wie ich inzwischen herausfinden konnte, ist Diskussionsgegenstand lediglich "https in source.list in Debian per default", da es über das Paket "apt-transport-https" ja schon eine Möglichkeit gibt "https" in der sources.list zu verwenden:

With the apt-transport-https package installed, you can instead use https://... in all of the above lines to use the repositories over encrypted HTTPS connections. https://wiki.debian.org/SourcesList

Anders scheint bei einer über onion-strings torifizierte sources.list kein https vorgesehen zu sein, wie in folgenden Listen [1] und im Thread [2] sowie im wiki [3] zu sehen:
[1]
https://onion.debian.org/
https://onion.torproject.org/
[2]
https://tor.stackexchange.com/questions ... ists-https
[3]
https://wiki.debian.org/SourcesList:

Here is an example sources.list using the onion services for Debian 9/Stretch:

Code: Alles auswählen

deb tor+http://vwakviie2ienjx6t.onion/debian stretch main
deb-src tor+http://vwakviie2ienjx6t.onion/debian stretch main

deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security stretch/updates main
deb-src tor+http://sgvtcaew4bxjd7ln.onion/debian-security stretch/updates main

deb tor+http://vwakviie2ienjx6t.onion/debian stretch-updates main
deb-src tor+http://vwakviie2ienjx6t.onion/debian stretch-updates main

[tobo]

Anders scheint bei einer über onion-strings torifizierte sources.list kein https vorgesehen zu sein, wie in folgenden Listen [1] und im Thread [2] sowie im wiki [3] zu sehen:
...
[2]
https://tor.stackexchange.com/questions ... ists-https

Dann hast du den von dir auf Seite 1 verlinkten Thread aber nur oberflächlich gelesen, genau wie [2], was mit der Thematik überhaupt nicht zu tun hat!? Verbindungen zu Onion Services sind Ende-zu-Ende verschlüsselt.

[debianuser4782]

Anders scheint bei einer über onion-strings torifizierte sources.list kein https vorgesehen zu sein, wie in folgenden Listen [1] und im Thread [2] sowie im wiki [3] zu sehen:
...
[2]
https://tor.stackexchange.com/questions ... ists-https

Dann hast du den von dir auf Seite 1 verlinkten Thread aber nur oberflächlich gelesen, genau wie [2], was mit der Thematik überhaupt nicht zu tun hat!? Verbindungen zu Onion Services sind Ende-zu-Ende verschlüsselt.

Ich ging davon aus, man könne onion-services zusätzlich zu https verwenden und dies würde dann entsprechend in der sources.list so abgebildet. Also in etwa: https verschachtelt durch Tor.

[tobo]

Ich ging davon aus, man könne onion-services zusätzlich zu https verwenden und dies würde dann entsprechend in der sources.list so abgebildet. Also in etwa: https verschachtelt durch Tor.

Https zu einem Onion Service geht grundsätzlich schon. Aber a) weiß ich nicht, ob apt das formal (deb tor+https://...) kann und b) weiß ich nicht, ob überhaupt irgendwelche Mirrors existieren, die sich ein Zertifikat haben ausstellen lassen!? Zum Hintergrund (Onion über https) kannste ja mal hier lesen:
https://blog.torproject.org/facebook-hi ... ttps-certs

Anders aber als hier im Thread behauptet, wäre der apt-Fehler mit https oder tor so nicht ausnutzbar gewesen. Dazu müsste dann schon der entsprechende Spiegel-Server kompromittiert sein, aber dann wäre ja eh Essig...

[KBDCALLS]

Mal so nebenbei ,bevor ihr euch die Köpfe heißredet.

• apt-transport-tor

und die Dateiliste des Pakets

• Code: Alles auswählen

  /usr/lib/apt/methods/tor
  /usr/lib/apt/methods/tor+copy
  /usr/lib/apt/methods/tor+file
  /usr/lib/apt/methods/tor+http
  /usr/lib/apt/methods/tor+https
  /usr/lib/apt/methods/tor+mirror+copy
  /usr/lib/apt/methods/tor+mirror+file
  /usr/lib/apt/methods/tor+mirror+http
  /usr/lib/apt/methods/tor+mirror+https
  /usr/share/doc/apt-transport-tor/README.md.gz
  /usr/share/doc/apt-transport-tor/changelog.gz
  /usr/share/doc/apt-transport-tor/copyright

[uname]

Man kann ja auch nur apt-transport-https und dann URLs der Form https:// verwenden, wobei das Problem ja sowieso eher innerhalb von "apt" lag.

[wanne]

wäre der apt-Fehler mit https oder tor so nicht ausnutzbar gewesen.

So? Meines Wissens ist niemand bekannt der die Lücke ausgenutzt hat. Der Entdecker hat lediglich ein Szenario aufgezeigt, wie die Lücke hätte ausgenutzt werden könnte, die mit https nicht funktioniert hätte. Auf andere Art und weise wäre es problemlos möglichgewesen. – Nämlich indem man einen Mirror auf macht. Das dürfte sowieso die um Größenordnungen einfachere Variante sein als sich irgend wo zwischen mich und den sowieso meist wenige km entfernten Mirror ins Glasfaserkabel einzuklinken. Normalerweise liegt man da ja sogar beim gleichen Anbieter.

Dazu müsste dann schon der entsprechende Spiegel-Server kompromittiert sein, aber dann wäre ja eh Essig...

Nein. Debian Mirrors darf jeder Betreiben, der will. Da gibt es absichtlich keine Kontrollen, weil man da um jeden freiwilligen froh ist. Apt kontrolliert die Echtheit der Pakete. Deswegen ist das kein Problem. Sind die nicht vom Maintainer unterschrieben, werden sie nicht installiert.
Hilft natürlich nichts gegen Sicherheitslücken in apt selbst, wenn diese vor oder in der Signaturprüfung liegen.
Die Diskussion gibt es seit Jahren: Wenn apt einen Fehler in der Signaturprüfung hätte (Das davor in den 10 Zeilen Download Lücken sein könnten hatte vorher niemand angenommen.) könnte https und kontrollierte Mirrors helfen. Man hätte eine doppelte Absicherung. Auf der anderen Seite holt man sich die Gefahr ins Haus, dass die TLS-Implementierung alleine anfällig ist. Apt mit https-Support ist etwa doppelt so groß wie ohne. Und der aller meiste Teil, der in apt gemacht wird ist eh nach der Signaturprüfung und damit nicht angreifbar. Man würde sich die Angriffsfläche vervielfachen. Auch die Statistik spricht für http: GnuTLS hatte deutlich mehr Sicherheitslücken als apt. Man hätte sich den Teufel mit dem Blezebub ausgetrieben.
Und das zu einem hohen Preis: Man müsst jetzt plötzlich alle Mirror-Betreiber kontrollieren und würde sich vor allem die ganze Caching-Struktur kaputt machen. Während Webcaches sonst eher tot sind lebt das im Debianuniversum noch: Debian hat nur wenige private nutzer sondern eher tausenden ähnlichen Geräten. Und während mirrors und apt-cache voraussetzen dass überall die sources.lst korrekt angepasst ist, und für jede Quelle einzeln eingerichtet und gewartet werden muss ist ein squid ein 0 effort Teil den man sogar Transparent für den Clienten machen kann. Vor unseren Server-VMs steht ein squid. Der hat immer >90% Cache-Hits. Weil das halt alle irgend wie eine übliche Linux-Distro die regelmäßig Updates macht da stehen hat. Würden die auf https umsteigen würde sich der Traffic zum Mirror mehr als verzehnfachen. – Und der ist dann noch mehr Aufwand weil sichergestellt werden muss, das er nicht kompromittiert wird.

Kurz: Nutzen von https ist eher zweifelhaft bis kontroproduktiv. Der Aufwand wäre aber riesig.
Deswegen macht keiner https. Insbesondere security.debian.org hat explizit https abgeschaltet, weil sie meinen lieber schnelle Sicherheitsupdates mit Proxy als irgend welche schlecht gewarteten zusätzlichen Mirrors, die wegen fehlendem Caching her müssen.

[uname]

Deswegen macht keiner https. Insbesondere security.debian.org hat explizit https abgeschaltet, weil sie meinen lieber schnelle Sicherheitsupdates mit Proxy als irgend welche schlecht gewarteten zusätzlichen Mirrors, die wegen fehlendem Caching her müssen.

Liegt vielleicht auch daran, dass das neue, aktualisierte .deb-Paket kein Geheimnis darstellt. Entscheidend ist nur, dass die Integrität gewahrt wird. Soll heißen, dass das .deb-Paket bitgenau beim Client so verarbeitet wird, wie es vom Server bereitgestellt wurde. Durch geeignete Prüfsummen, Keyrings und deren korrekte Überprüfung sollte das kein Problem sein. Und das war hier nicht sichergestellt. Somit ein Fehler von apt. Im übrigen sollte sich apt oder egal welche Anwendung NIE auf TLS-Transportverschlüsselung verlassen.

[tobo]

wäre der apt-Fehler mit https oder tor so nicht ausnutzbar gewesen.

So? Meines Wissens ist niemand bekannt der die Lücke ausgenutzt hat. Der Entdecker hat lediglich ein Szenario aufgezeigt, wie die Lücke hätte ausgenutzt werden könnte, die mit https nicht funktioniert hätte.

Ich sehe da jetzt erstmal keinen Widerspruch.

Auf andere Art und weise wäre es problemlos möglichgewesen. – Nämlich indem man einen Mirror auf macht. Das dürfte sowieso die um Größenordnungen einfachere Variante sein als sich irgend wo zwischen mich und den sowieso meist wenige km entfernten Mirror ins Glasfaserkabel einzuklinken.

Was dann aber unabhängig zum verwendeten Protokoll wäre.

Die Diskussion gibt es seit Jahren: Wenn apt einen Fehler in der Signaturprüfung hätte (Das davor in den 10 Zeilen Download Lücken sein könnten hatte vorher niemand angenommen.) könnte https und kontrollierte Mirrors helfen. Man hätte eine doppelte Absicherung.

Kontrollierte Mirrors - sowas wie Debian Enterprise Edition?

Auf der anderen Seite holt man sich die Gefahr ins Haus, dass die TLS-Implementierung alleine anfällig ist.

Davon redet keiner. Die Sicherheitsmechanismen von APT ändern sich ja nicht, nur weil das transportverschlüsselt wird!? Das ist nicht Oder- sondern Und-Verknüpft.

Apt mit https-Support ist etwa doppelt so groß wie ohne. Und der aller meiste Teil, der in apt gemacht wird ist eh nach der Signaturprüfung und damit nicht angreifbar. Man würde sich die Angriffsfläche vervielfachen. Auch die Statistik spricht für http: GnuTLS hatte deutlich mehr Sicherheitslücken als apt. Man hätte sich den Teufel mit dem Blezebub ausgetrieben.

Ich bin ja auch für weniger und kleinere Software, man darf aber auch nicht das große Ganze aus den Augen verlieren. Bei den staatlichen/wirtschaftlichen Begehrlichkeiten heutzutage muss das Anliegen doch sein, dass die Kommunikationstränge verschlüsselt sind und selbstverständlich ist das aufwendiger, als unverschlüsselt Daten zu übertragen. Und selbst wenn GNU TLS eine Bugmaschine wäre, was wäre denn dann das Worstcase-Szenario? Dass du auf das Sicherheitsniveau von APT zurückfällst und keinen Deut darunter.

Und das zu einem hohen Preis: Man müsst jetzt plötzlich alle Mirror-Betreiber kontrollieren

Warum, um was zu erreichen?

und würde sich vor allem die ganze Caching-Struktur kaputt machen.

Ja, es muss ja auch einen guten Grund geben, wieso das nicht längst der Default ist!?

[jph]

Onlinebanking betreibe ich sowieso nicht, weil mir bewußt ist, daß man vor allem im Bankensektor mit HTTPS nur Sicherheit vortäuschen will. Die Banken haben eine lange Tradition darin, technische Unzulänglichkeiten juristisch als "sicher" deklarieren zu lassen. Ja, wenn ein Jurist sagt, das ist sicher, dann wird das wohl stimmen. Beispiel?
https://de.wikipedia.org/wiki/Chaos_Com ... b#Btx-Hack

Meiner Meinung nach ist es unredlich, den Btx-Hack von vor 35 Jahren (den jüngeren Forenteilnehmern wirst du erst mal erklären müssen, was Btx überhaupt war) anzuführen und daraus zu schlussfolgern, dass die Banken seitdem nichts dazugelernt hätten.

Full disclosure: ich arbeite in einer Rechenzentrale, habe aber mit IT-Security nichts zu tun.

[KBDCALLS]

Meiner Meinung nach ist es unredlich, den Btx-Hack von vor 35 Jahren (den jüngeren Forenteilnehmern wirst du erst mal erklären müssen, was Btx überhaupt war) anzuführen und daraus zu schlussfolgern, dass die Banken seitdem nichts dazugelernt hätten.

Full disclosure: ich arbeite in einer Rechenzentrale, habe aber mit IT-Security nichts zu tun.

Das die Banken was gelernt haben da kann man schon berechtigte Zweifel dran haben. Zum Beispiel wie mit Leuten umgegangen wird denen die Ec-Karte gestohlen und dann das Konto geplündert wird , und denen dann unterstellt das man den Ganoven die Pin auf dem Silbertablett serviert hat, (Anscheinsbeweis) . Obwohl es Beweise gibt wie die Ganoven an die Pin kommen, nur das wird einfach ignoriert.

[wanne]

Davon redet keiner. Die Sicherheitsmechanismen von APT ändern sich ja nicht, nur weil das transportverschlüsselt wird!? Das ist nicht Oder- sondern Und-Verknüpft.

Eine Lücke im der http Implementierung wie sie jetzt gefunden wurde ist dann ja auch völlig harmlos, weil danach die Signaturen überprüft werden. Oder?

Und selbst wenn GNU TLS eine Bugmaschine wäre, was wäre denn dann das Worstcase-Szenario? Dass du auf das Sicherheitsniveau von APT zurückfällst und keinen Deut darunter.

Wenn also ein Bug im http ist fällt man lediglich auf das Sicherheitsniveau von PGP? Dann haben wir ja im Moment kein Problem.

Ne sorry, wenn dein TLS eine remote-Code Execution oder Speicher auslesen im TLS hat, dann interessierst du dich nicht mehr dafür , ob apt sicher ist. Du hast neie root shell.

Und das zu einem hohen Preis: Man müsst jetzt plötzlich alle Mirror-Betreiber kontrollieren

Mehr Sicherheit als aktuell. Um den aktuellen Bug auszunutzen, musst du mindestens ein MITM sein. Wenn du lediglich https machst kann das weiterhin jeder, der die 5min investiert sich ein TLS-Zertifikat zu klicken. Normalerweise sichert sich TLS dagegen ab, indem es die Domain der URL im Browser mit der im Zertifikat abgleicht. Apt ist aber keine interaktive Browseranwendung, wo du gegen die Addresszeile abgleichen kannst. Du forderst Pakete an, die je nach Laune von völlig unterschiedlichen URLs kommen können. – Je nach dem was Debian gerade als schnell erachtet. Liefert dir irgend jemand ein passendes Paket nimmt apt im Moment jede Domain. Ein Angreifer würde sich also einfach ein kostenloses Zertifikat holen können, dass zu einer Domain gehört die ihm legitim gehört.
TLS meckert nicht apt meckert nicht. Bingo! Und erzähl mir nichts von kompliziert:
Du hast vorher gemeint, dass da irgend jemand NSA style mäßig irgend wo heimlich Kabel manipuliert. Das war mal einfach, aber häute kannst du da dicke Bücher drüber schreiben, wie man das mit Glasfaser oder DSL noch hinbekommt.
Wie gesagt der mit Abstand einfachste weg den aktuellen Bug auszunutzen ist einfach einen eigenen Mirror zu betreiben. Und da hilft absolut kein TLS.

Ja, es muss ja auch einen guten Grund geben, wieso das nicht längst der Default ist!?

Nein. Weil es mit https deutlich sicherer wird.

[tobo]

Da du mich ja gezielt falsch verstehen willst, verstehst du mich nicht richtig.

Du hast vorher gemeint, dass da irgend jemand NSA style mäßig irgend wo heimlich Kabel manipuliert.

Wo habe ich das gesagt: anderer Thread, anderes Forum?

[wanne]

Da du mich ja gezielt falsch verstehen willst, verstehst du mich nicht richtig.

Nein. Deine aussagen waren schlicht falsch. Ich habe sie nur konsequent weiter gedacht. Da ist halt eben keine Und-Verknüpfung. (Und auch keine Oder) Für Lücken wie die aktuelle ist halt die erste Schicht, die die zählt. Deswegen hat PGP den Bug im http-Code nicht ausmerzen können und deswegen könnte es das auch nicht im Fall von https. – Nur das https ungleich komplizierter ist und deswegen anfälliger für Fehler.

Wo habe ich das gesagt: anderer Thread, anderes Forum?

Das war halt der Angriff den https verhindert hätte. Alle einfacheren hätte es nicht verhindert.