# Hacker entern Github-Dienst von Gentoo Linux

## Tyrus

Kam grade auf heise.de rein: https://www.heise.de/security/meldung/Hacker-entern-Github-Dienst-von-Gentoo-Linux-4094422.html

 *Quote:*   

> 
> 
>  Hacker entern Github-Dienst von Gentoo Linux
> 
> 29.06.2018 10:28 Uhr Dennis Schirrmacher
> ...

 

Urghs.

----------

## hampelratte

Was mir noch nicht ganz klar ist, ob die offiziellen mirrors davon betroffen sind, oder nicht (ich benutze 2 deutsche Hochschulen). Ich gehe jetzt erst mal davon aus, dass die von gentoo.org spiegeln, aber solange mir das nicht klar ist, mach ich kein emerge update.

----------

## firefly

 *hampelratte wrote:*   

> Was mir noch nicht ganz klar ist, ob die offiziellen mirrors davon betroffen sind, oder nicht (ich benutze 2 deutsche Hochschulen). Ich gehe jetzt erst mal davon aus, dass die von gentoo.org spiegeln, aber solange mir das nicht klar ist, mach ich kein emerge update.

 

Soweit ich die news gelesen habe (auch die meldung von gentoo selbst über ihre gentoo-announcement  e-mail verteiler) scheint nur die github git reprositories betroffen zu sein.

Der portage tree auf gentoo.org und deren rsync/websync mirrors ist wohl nicht betroffen

----------

## Yamakuzure

 *hampelratte wrote:*   

> Was mir noch nicht ganz klar ist, ob die offiziellen mirrors davon betroffen sind, oder nicht (ich benutze 2 deutsche Hochschulen). Ich gehe jetzt erst mal davon aus, dass die von gentoo.org spiegeln, aber solange mir das nicht klar ist, mach ich kein emerge update.

 Die Mirrors, die tarballs u.s.w. hosten, haben mit den Ebuild-Repositories nichts zu tun. Ausschließlich https://github.com/gentoo ist betroffen.

----------

## franzf

 *Yamakuzure wrote:*   

>  *hampelratte wrote:*   Was mir noch nicht ganz klar ist, ob die offiziellen mirrors davon betroffen sind, oder nicht (ich benutze 2 deutsche Hochschulen). Ich gehe jetzt erst mal davon aus, dass die von gentoo.org spiegeln, aber solange mir das nicht klar ist, mach ich kein emerge update. Die Mirrors, die tarballs u.s.w. hosten, haben mit den Ebuild-Repositories nichts zu tun. Ausschließlich https://github.com/gentoo ist betroffen.

 

Oho, die gesamte Gentoo-org Seite auf github ist jetzt weg, der Link gibt ne 404. Ebenso wenn ich es aus meiner Browserchronik öffne.

https://github.com/gentoo-mirror/gentoo ist auch nicht betroffen, das verwende ich zum Syncen.

Ich hoffe die bekommen das auf die Reihe. Proxy und vieles andere (Qt-bumps im gentoo/qt-repo) ging ja mittlerweile über github pull requests.

----------

## ChrisJumper

https://forums.gentoo.org/viewtopic-t-1083234.html

Ja so schnell kann es gehen. Bin aber auch nicht betroffen, rsync nutzt hier rsync://rsync.gentoo.org/gentoo-portage und die wenigen Overlays ziehen von anderen github Verzeichnissen.

Mir kommt es eh ein wenig vor wie ein Warnschuss dafür das MS github übernommen hat. Aber es kursieren in den Kommentaren auch schon wilde VT dazu das Geheimdienste Microsoft natürlich den Zugang gewähren.. ;D

Ich glaube es ist eher ein Weckruf als ein gezielter Angriff.

----------

## Yamakuzure

Ohje... Ich frage mich, woe die Verschwörungstheorien her kommen. Warum zur Hölle sollte eine Firma von den Ausmaßen Microsofts eine Meta-Distri wie Gentoo als Bedrohung ansehen? Ergibt kein Sinn.

Und jetzt auch noch Geheimdienste....

Mannmannmann... Die tolle eingeschleuste "Malware" war ein schnödes "rm /*", mit dem manche Ebuilds versetzt wurden. Davonabgesehen, dass "emerge" dann aussteigt, würde es eh nicht funktionieren: --recursive fehlt.

Also wer wirklich glaubt, dass da ein ernsthafter Angriff hinterstand, der von irgendwelchen Geheimdiensten oder von Microsoft angezettelt wurde, der sollte seinen Aluhut schleunigst auf Löcher untersuchen!

----------

## asturm

 *Yamakuzure wrote:*   

> Also wer wirklich glaubt, dass da ein ernsthafter Angriff hinterstand, der von irgendwelchen Geheimdiensten oder von Microsoft angezettelt wurde, der sollte seinen Aluhut schleunigst auf Löcher untersuchen!

 

Wer nichts weiß muss alles glauben. Immerhin kann man gut beobachten wer da leichtfertig seine (Online-)Reputation aufs Spiel setzt.

----------

## Tyrus

Auf Heise.de gibt es dazu nen neuen Artikel: https://www.heise.de/security/meldung/Gentoo-Linux-kurzzeitig-mit-Wiper-Malware-verseucht-4095751.html

 *Quote:*   

> 
> 
> Gentoo Linux kurzzeitig mit Wiper-Befehl versehen
> 
> Update
> ...

 

Betroffende Commits kann man hier nachprüfen: https://wiki.gentoo.org/wiki/Github/2018-06-28

----------

## ChrisJumper

 *asturm wrote:*   

>  *Yamakuzure wrote:*   Also wer wirklich glaubt, dass da ein ernsthafter Angriff hinterstand, der von irgendwelchen Geheimdiensten oder von Microsoft angezettelt wurde, der sollte seinen Aluhut schleunigst auf Löcher untersuchen! 
> 
> Wer nichts weiß muss alles glauben. Immerhin kann man gut beobachten wer da leichtfertig seine (Online-)Reputation aufs Spiel setzt.

 

Ach was, war doch bestimmt nur Sarkasmus und als Humor zu verbuchen. Es passte halt zu dem drum herum. Es ist wirklich schade das News immer so aufgebauscht werden, denn das erhöht die Zeitverschwendung.

Gleichzeitig fand ich es aber auch gut das Gentoo als Name noch mal bei Heise erscheint, auch wenn die Schlagzeile das ganze in ein falsches Licht gerückt hat. Das Thema Open Source oder Linux, ist ja leider sowohl bei Heise, Google als auch der Öffentlichkeit in den Hintergrund gerückt.

So gab es ja auf der letzten CBit auch keine Open-Source Bereich mehr wenn ich das richtig vernommen habe. Da bleibt dann fast nur noch der Linux Tag und die Foscon oder?

Na wie auch dem ich hoffe das noch einige junge Menschen in ihrem Alltag öfter über Linux oder Gentoo stolpern und sich das mal anschauen. Diese Heise-Meldung war aber auch wieder eine Medienkompetenz-Übung. Sie hätten besser statt über Gentoo, einfach nur über die zwei Git-Rispositorys schreiben sollen.

Schade fand ich sowohl in der Meldung als auch in den News, das nicht auf den Umstand eingegangen wurde das Portage Signaturen verwendet und auch nicht der Stable Zweig betroffen war, sondern nur jene die dies Git-Respository nutzen und die Software bauen.

Das es dann nur ein rf Befehl war, ist aber schon ein schlechter Witz.

Aber gut zu wissen das im Fall eines Falles, das ganze Bemerkt wird.

----------

## asturm

 *ChrisJumper wrote:*   

> und auch nicht der Stable Zweig betroffen war, sondern nur jene die dies Git-Respository nutzen und die Software bauen.

 

Jeder in Gentoo baut die Software. Die ebuilds hier wie dort unterscheiden sich auch nicht. Der Punkt ist, wie schon viele Male erklärt, dass normalerweise *niemand* von den betroffenen GitHub Repos synct. Sondern nur pusht. Es ist nicht auszuschließen dass jemand davon in /usr/portage gesynct hat, aber eher aufgrund gefährlichen Halbwissens.

----------

## Josef.95

 *Tyrus wrote:*   

> Auf Heise.de gibt es dazu nen neuen Artikel:[...]

  Jo, der hätte auch gut aus der Bildzeitung stammen können - unnötig dramatisieren hilft hier niemanden weiter.

Den Artikel von https://www.techrepublic.com/article/gentoo-stops-github-repo-hack-in-an-hour-setting-standard-for-security-response fand ich da deutlich besser gelungen :)

----------

## schmidicom

 *Yamakuzure wrote:*   

> ...
> 
> Mannmannmann... Die tolle eingeschleuste "Malware" war ein schnödes "rm /*", mit dem manche Ebuilds versetzt wurden. Davonabgesehen, dass "emerge" dann aussteigt, würde es eh nicht funktionieren: --recursive fehlt.
> 
> ...

 

War vermutlich ein Scriptkiddie das nicht wusste wie man ein "FORMAT C:" in Linuxisch korrekt formuliert.  :Wink: 

----------

## Erdie

Ich verfolge heise schon viele Jahre. Man kann nicht behaupten, dass die Qualität der Artikel in den Jahren zugenommen hat. Es geht nur noch um Clicks, clicks ... clicks

----------

## mv

 *asturm wrote:*   

> Der Punkt ist, wie schon viele Male erklärt, dass normalerweise *niemand* von den betroffenen GitHub Repos synct.

 

Ganz im Gegenteil: Das war die Sync-Methode der Wahl, und sollte es in hoffentlich nicht allzu ferner Zukunft wieder werden: Es ist die einzige Möglichkeit, ChangeLogs zu erhalten, ohne sich seine Festplatte mit überflüssiger Metadatan-Geschichte vollzumüllen.

Der einzige Grund, weshalb es seit ein paar Tagen nicht mehr optimal ist, ist, dass für rsync und git-mirror eine automatische Unterschriften-Verifikation implementiert wurde (für rsync zufälligerweise schon ein paar Tage vor dem Angriff, für git-mirror erst danach), während dies für das obige Repository leider noch nicht geschehen ist.

Das ist natürlich ein massier Grund (der mich dazu gezwungen hat, ab jetzt auf die ChangeLogs zu verzichten), aber hoffentlich nur zeitweise.

----------

## asturm

 *mv wrote:*   

>  *asturm wrote:*   Der Punkt ist, wie schon viele Male erklärt, dass normalerweise *niemand* von den betroffenen GitHub Repos synct. 
> 
> Ganz im Gegenteil: Das war die Sync-Methode der Wahl, und sollte es in hoffentlich nicht allzu ferner Zukunft wieder werden: Es ist die einzige Möglichkeit, ChangeLogs zu erhalten, ohne sich seine Festplatte mit überflüssiger Metadatan-Geschichte vollzumüllen.

 

Ohne metadata generation? Ohne CI integrity check? Sicher nicht (zumindest nicht als Standardempfehlung für User). Darüber hinaus gibt es immer noch gentoo.git, dafür braucht es kein GitHub. Letzteres ist auf meinen Systemen weder als pull noch als push remote eingetragen, weil es automatisch von gentoo.git gesynct wird. Nicht einmal PRs werden auf GitHub gemerged, sondern zu gentoo.git gepushed und von dort an GitHub weitergereicht.

(mein Kommentar hat sich ausschließlich auf die Nutzung als /usr/portage bezogen, mir ist schon klar dass viele die das repo wollen aus Gewohnheit von GitHub klonen werden).

----------

## mv

 *asturm wrote:*   

> Ohne metadata generation? Ohne CI integrity check?

 

Metadata generation ist kein Problem. Vor vielen Jahren hat das Portage ohnehin immer selbst (nach /var/cache/edb) gemacht; inzwischen gibt es egencache für den "richtigen" Ort.

Signatur-Verifikation ist halt im Moment das Problem. Ich hoffe, dass es in näherer Zukunft eine offizielle Möglichkeit gibt, die aktuellen Entwickler-Schlüssel zu bekommen und auf dem laufenden zu halten. Das zugehörige Projekt gkeys gibt es ja eigentlich...

Edit: Fehlende Wort "Jahren" eingefügt.Last edited by mv on Mon Jul 23, 2018 6:26 am; edited 1 time in total

----------

## ChrisJumper

Ich hatte gerade eben (kurz) das Problem das die Sync-Server nicht erreichbar waren und ich den Tree nicht synchronisieren konnte. Obwohl ich das eh von meinem lokalen Portage-Mirror mache.

Bisschen schade ist das schon das ich meinen eigenen Portage-Mirror nicht auch als Keys-Server vertrauen kann. Portage zu Verifizieren dauert aber wirklich lange. Würde es nicht reichen nur die Änderungen zu verifizieren?

Also im Grunde begrüße ich alles, was mehr Sicherheit verspricht.

Aber im Grunde ist Gentoo ja schon dafür berühmt viel Strom zu verschwenden für Stabilität. Das jetzt die Signatur-Prüfung nur von einer CPU gemacht wird und ewig dauert setzt dem ganzen die Krone auf. Na mal schauen ob ich meinen Stromverbrauch ein wenig reduzieren kann. Zumindest in der Chain of Thurst.

----------

## mv

 *ChrisJumper wrote:*   

> Würde es nicht reichen nur die Änderungen zu verifizieren?

 

Mit rsync ist es nicht so einfach, eine Liste der geänderten files zu erhalten. Vielleicht könnte man den rsync-output abfangen; erscheint mir aber ziemlich schräg.

Nachdem jetzt git syncing mit Tiefe 1 in portage wieder implementiert ist (und höhere Tiefen aus Platzgründen für das Nicht-source-Repository nicht zweckmäßig sind), ist m.E. git mit Tiefe 1 ein sinnvoller Ersatz für rsync. Das geht auch schnell.

 *Quote:*   

> Das jetzt die Signatur-Prüfung nur von einer CPU gemacht wird und ewig dauert setzt dem ganzen die Krone auf.

 

gemato ist in m.W. in python implementiert. Multitasking ist da schwer möglich (GIL).

----------

