|
detructor15
Anmeldungsdatum: 16. Januar 2007
Beiträge: 5733
|
Hi, ich hatte gerad eine Diskussion mit einem Windowsler über Sinn und Unsinn von Paketquellen. Im Laufe dieser Diskussion kamen wir darauf, wie das eigentlich bei den beiden Systemen ist, aber wie ist das eigentlich bei Linuxoiden Repos? Nehmen wir der einfachheit halber mal die Debian/Ubuntu Quellen. Mir ist folgendes Prinzip bekannt: Auf dem Paketserver liegt die .deb Datei und "daneben" eine md5sum Datei, wenn das .deb Paket runtergeladen wurde, wird die md5sum von meinem PC berechnet und anschließend mit der Server datei verglichen. Ist das korrekt? Falls ja, was hindert eine Person daran, auf den Server zu gehen und die .deb Datei und die md5 Datei auszustauschen? Falls nicht, wie funktioniert das ganze dann? Gruß detru
|
|
BuBu2009
Anmeldungsdatum: 28. März 2009
Beiträge: 134
|
GPG-Signaturen Deb-Pakete in Paketquellen werden mit GnuPG-Schlüsseln digital signiert. Passt die Signatur zu keinem der Paketverwaltung bekannten Schlüssel, so wird der Benutzer bei der Installation eines Paketes aus solch einer Quelle gewarnt. Drittanbieter stellen daher oft ihren GPG-Key zur Verfügung, den man dann in seinen Keyring importieren kann. Wichtig ist aber, was weiter oben schon zu den zwei Stufen des Vertrauens geschrieben wurde. Ein GPG-Key kann keine von beiden ersetzen. Er kann nur beweisen, dass die Pakete wirklich vom Besitzer der Paketquelle stammen und nicht nachträglich verändert wurden. Desweiteren kann ein GPG-Key, der auf demselben Server liegt wie die Dateien, die mit ihm signiert sind, von einem Einbrecher mit Leichtigkeit mitsamt den Dateien ausgetauscht werden. Einfach den GPG-Key zu importieren und dann die Software zu installieren, sagt deswegen gar nichts über die Authentizität der Software aus. Allerdings schützt der Schlüssel einen in Zukunft, wenn man Updates lädt und der Server in der Zwischenzeit kompromittiert wurde. Außerdem ist es für einen Site-Admin weitaus einfacher, regelmäßig seinen auf dem Server hinterlegten GPG-Key auf Veränderungen zu überprüfen als die Prüfsummen aller Pakete zu vergleichen. Ob der Besitzer eines Repositories das auch macht, kann aber natürlich keiner sagen, außer er selber. In gewisser Weise ist das Nichthinzufügen des GPG-Schlüssels für manche Benutzer ein Sicherheitsaspekt. Denn werden in solchen Fremdquellen Pakete aktualisiert, meldet dies auch der Updatenotifier von Ubuntu. Man kann aber nicht immer genau erkennen, aus welcher Quelle das Paket kommt. Fügt man den Schlüssel nicht hinzu, erhält man bei solchen Fremdpaketen immer eine Warnung und man kann es sich gegebenenfalls noch einmal anders überlegen, ob man das Update wirklich installieren will.
Quelle: http://wiki.ubuntuusers.de/Fremdquellen Moderiert von V for Vortex: Bitte fasse Zitate in Zitatzeichen, um sie von Deinen eigenen Aussagen deutlich abzugrenzen. Ich habe es hier mal nachgeholt.
|
|
uname
Anmeldungsdatum: 28. März 2007
Beiträge: 6030
Wohnort: 127.0.0.1
|
Zur Vertiefung der Informationen. Die Schlüssel werden im Keyring
/etc/apt/trusted.gpg
gespeichert, die man wie folgt ermitteln kann
sudo apt-key list Ein Risiko ist somit vor allem die Installation von Debian/Ubuntu von CDs. Aber jedermann wird natürlich den MD5-Fingerprint der CD-ROM mit dem Original der ISO-Datei vergleichen.
|
|
elusive
Anmeldungsdatum: 25. Oktober 2006
Beiträge: 260
|
ich denke sein Gedanke/Problem ist ein anderes: Ich erstelle mir ein PPA und behaupte ich habe dort Software XY drin. Zum Beispiel einen aktuellen daily build von ... gtkpod. Das finden viele Leute ganz nett und installieren sich das PPA und installieren auch die Software aus dem PPA. Nun habe ich aber gar nicht gtkpod kompiliert, sondern zum Beispiel eine Malware oder ein Script welches beim nächsten Booten die Festplatte löscht oder so etwas. Da ich das aber alles selber so reingestellt habe und auch selber signiert etc. wäre das für die Anwender durchaus ein Problem. Klar, wahrscheinlich würde es ziemlich schnell auffalen, aber bis dahin hätte mindestens einer ein großes Problem.
|
|
detructor15
(Themenstarter)
Anmeldungsdatum: 16. Januar 2007
Beiträge: 5733
|
elusive schrieb: ich denke sein Gedanke/Problem ist ein anderes: Ich erstelle mir ein PPA und behaupte ich habe dort Software XY drin. Zum Beispiel einen aktuellen daily build von ... gtkpod. Das finden viele Leute ganz nett und installieren sich das PPA und installieren auch die Software aus dem PPA. Nun habe ich aber gar nicht gtkpod kompiliert, sondern zum Beispiel eine Malware oder ein Script welches beim nächsten Booten die Festplatte löscht oder so etwas. Da ich das aber alles selber so reingestellt habe und auch selber signiert etc. wäre das für die Anwender durchaus ein Problem. Klar, wahrscheinlich würde es ziemlich schnell auffalen, aber bis dahin hätte mindestens einer ein großes Problem.
nö, das war schon meine Frage. Aber dein Szenario ist auch interessant...allerdings wird da auch überall vor gewarnt: keine fremdquellen benutzen. Meine Frage war einfach: Wenn sich jemand auf einen Server einhackt und dort ein paar Quellcode Zeilen in irgendeinem Programm ändert und die Signatur (oder was auch immer) neu erzeugt, alles hochlädt und das alte überschreibt...wird das vom eigenen System irgendwie bemerkt? Die Antwort ist (soweit verstanden): Nein.
|
|
Chrissss
Anmeldungsdatum: 31. August 2005
Beiträge: 37971
|
elusive schrieb: Ich erstelle mir ein PPA und behaupte ich habe dort Software XY drin...
Und genau deswegen steht an allen Ecken und Enden ein Link auf Fremdquellen
|
|
elusive
Anmeldungsdatum: 25. Oktober 2006
Beiträge: 260
|
Chrissss schrieb: elusive schrieb: Ich erstelle mir ein PPA und behaupte ich habe dort Software XY drin...
Und genau deswegen steht an allen Ecken und Enden ein Link auf Fremdquellen
ja na sicher, gewarnt wird, aber mal ehrlich: wie ernst nimmst du diesen Hinweis? Ich denke das Problem, welches ich beschrieben habe, könnte durchaus ohne größere Probleme Wirklichkeit werden, da es innerhalb der Linux Gemeinde sehr viel "Vertrauen" gibt. (hoffe ihr versteht was ich meine) Und das könnte natürlich relativ leicht ausgenutzt werden...
|
|
Chrissss
Anmeldungsdatum: 31. August 2005
Beiträge: 37971
|
elusive schrieb: ja na sicher, gewarnt wird, aber mal ehrlich: wie ernst nimmst du diesen Hinweis?
Sehr Ernst, ich habe sie geschrieben... http://forum.ubuntuusers.de/topic/ikhaya-eine-kleine-geschichte-ueber-fremde-pa/
|
|
detructor15
(Themenstarter)
Anmeldungsdatum: 16. Januar 2007
Beiträge: 5733
|
verdammt, dass wollte ich gerad posten, Chrisss du bist zu schnell...mal wieder...naja, wie eigentlich immer... 😉
|
|
MxO
Anmeldungsdatum: 19. Oktober 2007
Beiträge: 123
|
detructor15 schrieb: Meine Frage war einfach: Wenn sich jemand auf einen Server einhackt und dort ein paar Quellcode Zeilen in irgendeinem Programm ändert und die Signatur (oder was auch immer) neu erzeugt, alles hochlädt und das alte überschreibt...wird das vom eigenen System irgendwie bemerkt? Die Antwort ist (soweit verstanden): Nein.
Falls der Besitzer des PPAs so unvorsichtig ist, dass der Angreifer seinen persönlichen GPG-Schlüssel samt Passwort in die Hände bekommt, dann wirst du es nicht bemerken. Andernfalls kann er das Paket allerdings gar nicht signieren, weil ihm dazu der Schlüssel fehlt. Am Schritt "die Signatur (oder was auch immer) neu erzeugen" sollte es also im Normalfall scheitern. Da ich andererseits nicht weiß, wie das mit dem Signieren genau gehandhabt wird, möchte ich mich jetzt nicht zu weit aus dem Fenster lehnen und behaupten, dass der Schlüssel nicht auf dem Server liegt. Das signieren ist so weit ich das verstanden habe hauptsächlich gegen Man-in-the-middle angriffe gedacht. Man muss allerdings sagen, dass gegen ein gehacktes Software-Repository + geklauten privaten Schlüssel kein Update-System immun sein kann. Wenn du den Windows/Firefox/egal - Update-Server hackst, dein Paket unterbringen kannst + es signieren kannst, werden die meisten Leute es installieren, warum sollten sie es auch nicht tun (bzw. der Firefox unter Windows fragt gar nicht erst und installiert es normalerweise sofort, weiß nicht wie die Standardeinstellungen von Windowsupdate und z.B. Synaptic bezüglich sicherheitsrelevanter Updates ist). Deshalb sollten die Repositorys auch gut geschützt werden, etwas anderes kann man meiner Meinung nach nicht dagegen unternehmen. Gruß Stephan (Edit: wenn man den privaten Schlüssel vom Conficker-Autor kennen würde, könnte man z.B. fast das ganze Conficker-Netzwerk vernichten, indem man sich möglichst viele von den Update-Urls holt und dort ein Update bereitstellt, das den Wurm wieder entfernt. Scheitert daran, dass man den Schlüssel nicht hat und damit das Update nicht signieren kann.)
|
|
akrde
Anmeldungsdatum: 22. März 2009
Beiträge: 400
|
Chrissss schrieb: elusive schrieb: Ich erstelle mir ein PPA und behaupte ich habe dort Software XY drin...
Und genau deswegen steht an allen Ecken und Enden ein Link auf Fremdquellen
Fallen Downloads von http://www.getdeb.net/ auch unter diesen Sicherheitshinweis? Wie komme ich dann aber z.b. für Ubuntu 8.10 an ein SICHERES Installationspaket von z.b. der aktuellen Version 2.2.9 von gnucash, welche von den gnucash-Entwicklern bei Problemen mit QIF-Imports empfohlen wird? Sollte man überhaupt irgendwas installieren (egal ob Neuinstallationen oder Updates), was nicht über Synaptic der jeweiligen Ubuntu-Version angeboten wird? Lässt sich das überhaupt generell vermeiden? Und wenn man kein Ubuntu-fremdes Paket herunterladen/installieren sollte: ist selbst kompilieren sicher und damit eine bessere Idee?
|
|
MxO
Anmeldungsdatum: 19. Oktober 2007
Beiträge: 123
|
elusive schrieb: Ich erstelle mir ein PPA und behaupte ich habe dort Software XY drin. Zum Beispiel einen aktuellen daily build von ... gtkpod. Das finden viele Leute ganz nett und installieren sich das PPA und installieren auch die Software aus dem PPA. Nun habe ich aber gar nicht gtkpod kompiliert, sondern zum Beispiel eine Malware oder ein Script welches beim nächsten Booten die Festplatte löscht oder so etwas. Da ich das aber alles selber so reingestellt habe und auch selber signiert etc. wäre das für die Anwender durchaus ein Problem. Klar, wahrscheinlich würde es ziemlich schnell auffalen, aber bis dahin hätte mindestens einer ein großes Problem.
Auch hier ist das Problem ähnlich: Ohne den Sourcecode zu lesen + komplett zu verstehen + dann selbst zu kompilieren und zu installieren kannst du keinem Programm vertrauen. Das Problem tritt bei eigentlich jeder Installation auf: der Installer braucht viele Rechte, um das Programm in das System einzufügen und kannst nicht wissen, was er damit machen wird. Vielleicht könnte man ein System entwerfen, bei dem jedes Programm von allen anderen Programmen komplett abgeschottet ist und damit keine Möglichkeit hat, Schaden im System anzurichten. Allerdings wäre ein solches System wahrscheinlich sehr unkomfortabel und umständlich für Programmierer. Auch bei diesem System müsste man aber wahrscheinlich dem Programmierer des Systems vertrauen. Ich glaube es führt insgesamt momentan kein Weg daran vorbei, viel Vertrauen in die Besitzter der Repositorys und die Programmierer der Programme zu haben (Edit: und in die Sicherheit der Repository-Server). Wenn man das nicht hat, kann man ja immer noch einen Computer einfach nicht ans Internet anschließen, dann kann auch nicht viel kaputt gehen. Online-Banking geht dann allerdings auch nicht mehr 😉 Gruß Stephan
|
|
uname
Anmeldungsdatum: 28. März 2007
Beiträge: 6030
Wohnort: 127.0.0.1
|
ja na sicher, gewarnt wird, aber mal ehrlich: wie ernst nimmst du diesen Hinweis?
Die Warnung vor den Fremdquellen sollte man sehr ernst nehmen. Denn genau das ist unter Windows auch der Weg wie man sich Trojaner, Viren usw. besorgt. Und durch die Installation hat man es als "root" installiert. Das System ist im Zweifelsfall verloren. Hier mal ein Beispiel, wurde vor einiger Zeit diskutiert: http://www.linux-firewall.org/ Hört sich toll an, mag toll sein und mag auch kein Virus versteckt sein. Wer dieses jedoch sich besorgt und installiert braucht gar keine Firewall mehr. Er braucht eine Neuinstallation.
wenn man den privaten Schlüssel vom Conficker-Autor kennen würde
Oh ja. Da haben echt Leute Ahnung gehabt. Aber wer jetzt über die ganzen Conficker-Opfer lacht sollte daran denken, dass das mit Fremdquellen auch leicht passieren kann. PS.: hatte ich schon vor der Gefahr von Fremdquellen gewarnt?
|
|
Chrissss
Anmeldungsdatum: 31. August 2005
Beiträge: 37971
|
akrde schrieb: Fallen Downloads von http://www.getdeb.net/ auch unter diesen Sicherheitshinweis?
Im Endeffekt: Ja.
Wie komme ich dann aber z.b. für Ubuntu 8.10 an ein SICHERES Installationspaket von z.b. der aktuellen Version 2.2.9 von gnucash, welche von den gnucash-Entwicklern bei Problemen mit QIF-Imports empfohlen wird?
Warte auf die nächste Ubuntu Version.
Sollte man überhaupt irgendwas installieren (egal ob Neuinstallationen oder Updates), was nicht über Synaptic der jeweiligen Ubuntu-Version angeboten wird? Lässt sich das überhaupt generell vermeiden?
Eigentlich nein.
Und wenn man kein Ubuntu-fremdes Paket herunterladen/installieren sollte: ist selbst kompilieren sicher und damit eine bessere Idee?
Es geht um Vertrauen. Wo du die Grenze ziehst, ist dir überlassen. Dem Distributor deiner Linux-Distribution musst du wohl oder übel vertrauen. Somit steht dir automatisch auch ein Pool an zehntausenden Programmen zur Verfügung. Möchtest du nun eine andere Software benutzen, so musst DU entscheiden in wie weit du dem Autor traust.
|
|
akrde
Anmeldungsdatum: 22. März 2009
Beiträge: 400
|
Chrissss schrieb: Wie komme ich dann aber z.b. für Ubuntu 8.10 an ein SICHERES Installationspaket von z.b. der aktuellen Version 2.2.9 von gnucash, welche von den gnucash-Entwicklern bei Problemen mit QIF-Imports empfohlen wird?
Warte auf die nächste Ubuntu Version.
Um bei meinem Beispiel mit gnucash zu bleiben: Warten auf die nächste Ubuntu Version geht ja nicht, wenn ich aktuelle und akute Probleme mit gnucash Version 2.2.6 habe, die für Ubuntu 8.10 über Synaptic zur Verfügung steht und auch das nächste Ubuntu-Update noch auf sich warten liesse. Ubuntu bietet keine Aktualisierungen für gnucash innerhalb der laufenden Ubuntu-Version an, was bleibt einem da eigentlich anderes übrig, als die aktuellen deb-Pakete irgendwo anders herzubekommen oder 2.2.9 selbst zu kompilieren? Das gnucash-Problem muss ja irgendwie gelöst werden, auch in einer 8.10, oder? Was macht ihr in so einem Fall?
|