Veni, Vidi, VISA

Meine Dotfiles sind mittlerweile bei GitHub zu finden. Verwaltet werden die unter $HOME relativ simpel. Die relevanten Dateien werden mit ln(1) in ein Verzeichnis (${HOME}./dotfiles/) verlinkt, das als Repo dient. Sicherheitsrelevante Abschnitte (Passwörter, Emailadressen, IPs, ..) werden in andere Dateien ausgelagert (i. e. mutt.secret. Bei der Konfigurationsdatein von Irssi geht das nicht, da man keine externen Konfigurationsdateien "sourcen" kann. In meinem Fall ist das aber auch nicht weiter tragisch, weil sich die Konfiguration von Irssi seit ~10 Jahren kaum geändert hat. Ergo hab ich sich einfach von ~/.irssi/config nach ~/.dotfiles/irssi.config kopiert und dann in das Repo hinzugefügt, nachdem ich alle Passwörter (für Nichserv, Bouncer, VServer, ..) durch den String password ersetzt habe. Und jetzt ratet mal.. There has been 31 failed logins attempts since your last successful login.; das hab ich als Notice von FreeNode bekommen und bei meinem Bouncer waren es 18 fehlgeschlagene Logins. Also manchmal.. *sigh*

Gentoo hat sich mittlerweile zu dem Einbruch auf ihr Repo bei GitHub geäußert. Und zwar ohne langes Blabla, Ausreden oder ähnliches; sondern so: https://wiki.gentoo.org/wiki/Github/2018-06-28.

Nachdem ich das schon einige Male gefragt wurde: Nein> Meine Dotfiles gibt es nicht bei GitHub. Jetzt nicht aus egoistischen Gründen, sondern weil es mir zuviel Aufwand ist. Meine Konfigurationsdateien enthalten private/persönliche Daten wie z. B. Emailadressen, Hostnamen, IPs, Links zu privaten Seiten, ... Jetzt könnte ich persönliche Daten/Zeilen z. B. mit EDIT markieren, anschließend ein Script schreiben das alle Zeilen mit EDIT löscht bevor ich die Datei ins Repo lade, aber das ist mir - momentan - zuviel Aufwand. Wenn jemand eine brauchbare Lösung dafür parat hat, dann immer her damit.

Das Gentoo-Projekt wurde durch Unbekannte von seinen eigenen Seiten auf Github ausgesperrt. Der dort liegende Code wurde anscheinend manipuliert. Die Gentoo-eigene Infrastruktur ist dagegen nicht betroffen und die dort erstellten Pakete sind unversehrt.

Die Linux-Distribution Gentoo besitzt eine Github-Seite, über die ein Spiegel des Paket-Repositoriums bereitgestellt wird. Laut einer Mitteilung wurde diese Seite am 28. Juni gegen 20:20 UTC gehackt. Unbekannte konnten die Kontrolle über die Github Gentoo-Organisation übernehmen und die Mitglieder des Gentoo-Projekts aussperren. Einige Seiten sowie Inhalte der Repositorien wurden offenbar manipuliert. Gentoo versucht zur Zeit, wieder die Kontrolle über die Seiten zu erlangen.
Jeder Gentoo-Code auf Github muss daher als kompromittiert angesehen werden und sollte auf keinen Fall genutzt werden. Wie das Team erklärt, ist der Code auf Github nur eine Kopie des Codes, der auf der Gentoo-eigenen Infrastruktur gespeichert ist. Die Gentoo-eigene Infrastruktur ist nicht von dem Einbruch betroffen und nach wie vor sicher. Ebenfalls unversehrt sind die Gentoo-Mirror-Repositorien, die ebenfalls auf Github liegen, aber unter einer separaten Organisation. Gentoo spricht hier allerdings mit aller Vorsicht nur von »wahrscheinlich nicht betroffen«.

Alle Commits in die Gentoo-Repositorien sind signiert und es empfiehlt sich grundsätzlich immer, die Integrität der Signaturen zu verifizieren, wenn man Git nutzt, und jetzt erst recht. Weitere Informationen will das Team bereitstellen, sobald sie verfügbar sind.

Quelle: https://www.pro-linux.de/news/1/26044/gentoo-github-seiten-gekapert.html

Zeitnah dazu die Mitteilung auf Gentoo

Update: 04:26 UTC. Gentoo has regained control of the the Gentoo Github Organization. We are currently working with Github on a procedure for resolution. Please continue to refrain from using code from the Gentoo Github Organization. Development of Gentoo primarily takes place on Gentoo operated hardware (not on github) and remains unaffected. We continue to work with Github on establishing a timeline of what happened and we commit to sharing this with the community as soon as we can.

Today 28 June at approximately 20:20 UTC unknown individuals have gained control of the Github Gentoo organization, and modified the content of repositories as well as pages there. We are still working to determine the exact extent and to regain control of the organization and its repositories. All Gentoo code hosted on github should for the moment be considered compromised.

This does NOT affect any code hosted on the Gentoo infrastructure. Since the master Gentoo ebuild repository is hosted on our own infrastructure and since Github is only a mirror for it, you are fine as long as you are using rsync or webrsync from gentoo.org.

Also, the gentoo-mirror repositories including metadata are hosted under a separate Github organization and likely not affected as well.

All Gentoo commits are signed, and you should verify the integrity of the signatures when using git.

More updates will follow.

Ich mag zwar Gentoo nicht (u. a. wegen "POSIX?! pfff.. GNU Nano! Because fuck you!"), aber das ist mal ein vorbildliches Verhalten!

Durch einen Einbruch bei LinuxForums.org konnten Unbekannte die Zugangsdaten von 276.000 Benutzern erbeuten. Auf LinuxForums.org fehlt bis heute jeder Hinweis auf den Vorfall.

LinuxForums.org, ein Online-Forum für alle Linux-Themen, war offenbar bereits am 1. Mai oder früher Opfer eines Server-Einbruchs. Danach war die Seite zeitweise nicht erreichbar. Aktuell ist sie wieder online.


Das englischsprachige internationale Forum hatte nach Informationen von Linux Uprising rund 276.000 Benutzer, deren Zugangsdaten jetzt als kompromittiert gelten müssen. Benutzer sollten ein neues sicheres Passwort generieren, nicht nur bei LinuxForums.org, sondern auch bei allen anderen Zugängen, die dasselbe Passwort verwenden.

Besonders ärgerlich an dem Vorfall ist das Verhalten des Inhabers des Forums. MAS Media Inc, die Firma, die die seit 2001 bestehende Seite im Jahr 2008 übernommen hat, hat keinerlei Hinweise auf den Einbruch gegeben. Laut haveibeenpwned.com MAS Media Inc. außerdem auf keinen Kontaktversuch reagiert. Darüber hinaus hat es die Firma unterlassen, die Foren-Software aktuell und sicher zu halten. Zum Einsatz kommt auf LinuxForums.org eine proprietäre Software, vBulletin, in der obsoleten Version 4.2.2, die fast fünf Jahre alt ist.

Die von den Einbrechern vermutlich ausgelesenen Passwörter lagen zwar nicht im Klartext vor, sondern nur als gesalzener MD5-Hash. Dennoch müssen sie als kompromittiert gelten, da es mit heutiger Rechenleistung praktikabel ist, aus dem MD5-Hash das Passwort zu regenerieren. Für die Benutzer stellt sich die Frage, ob die Seite überhaupt noch betreut wird oder ob es nicht besser wäre, sie gleich ganz zu verlassen.

Quelle: https://www.pro-linux.de/news/1/25977/server-einbruch-bei-linuxforumsorg.html

Manchmal kann man nur noch mit dem Kopf nicken, den Schultern zucken und "Ja.. mei.." Denken.

Ergänzung der Regelungen zur Quellen-TKÜ und zur Online-Durchsuchung um ein Betretungsrecht
[..]
Sie sind der Auffassung, dass die derzeit zulässigen Möglichkeiten zur Aufbringung der Software auf dem informationstechnischen System des Betroffenen mit erheblichen rechtlichen und tatsächlichen Problemen behaftet sind.
[...]

Quelle: http://www.jm.nrw.de/JM/jumiko/beschluesse/2018/Fruehjahrskonferenz_2018/II-8-RP---Ergaenzung-der-Regelungen-zur-Quellen-TKUe-und-zur-Online-Durchsuchung-um-ein-Betretungsrecht.pdf

Kurz: Es geht um den Bundestrojaner. Die Polizei will in Wohnungen eindringen dürfen, um dort Spähsoftware auf dem Rechner installieren zu dürfen.

Der Ubuntu Snap Store hat Snaps angeboten, die Malware enthielten, um per Crypto-Mining Hardware-Ressourcen der Anwender zur Erstellung von ByteCoin abzuzweigen.

Im Ubuntu Snap Store kursierten seit Ende April verschiedene Snaps, die eine Malware enthielten, um die Crypto-Währung ByteCoin zu erstellen. Mindestens zwei der Pakete eines Users, der mehrere Snaps unter dem Namen Nicolas Tomb hochgeladen hatte, enthielten die Crypto-Mining-Malware, die als Systemd-Daemon getarnt war. Canonical hat die Snaps dieses Users mittlerweile entfernt und eine Untersuchung eingeleitet.
Es ist nicht bekannt, wie oft die Snaps heruntergeladen wurden, da der Snap Store keinen öffentlichen Zähler aufweist. Zudem waren die Snaps auch über die Applikation Gnome-Software zu beziehen, die neben Ubuntu auch von anderen Distributionen verwendet wird. Bei den beiden identifizierten Snaps handelt es sich um die Spiele »2048buntu« und »Hextris«. Tomb hatte teilweise proprietäre Lizenzen verwendet, um sich so vor Entdeckung zu schützen. So war das Snap zu 2048buntu, einem Clone des Spiels »2048«, mit einer solchen Lizenz versehen. Das Originalspiel unterliegt einer MIT-Lizenz, die es erlaubt, die Software frei oder proprietär zu verteilen. Vor drei Tagen fragte der Entdecker der Malware auf der GitHub-Instanz von Snapcraft an, wo er die Malware melden solle.

Jedermann kann in den Snap Store Pakete hochladen, sofern sie technisch funktionieren. Das stellt ein automatischer Test sicher, der derzeit die einzige Zugangsbarriere des Ubuntu Snap Store darstellt. Selbst eine weitere Überprüfung der Apps wäre wegen der proprietären Lizenz nicht in der Lage gewesen, die Malware zu erkennen.

Im Flatpak-Store FlatHub wird jedes Paket einer manuellen Durchsicht unterzogen, ob die App Requirements erfüllt werden. Auch FlatHub erlaubt proprietäre Lizenzen, um Anwendungen wie etwa Steam oder Spotify als Flatpak zu ermöglichen. Auch hier kann laut aussage eines Entwicklers in solchen Fällen keine absolute Sicherheit gewährleistet werden. Jedoch ist Flatpak eher auf Upstream-Pakete ausgelegt, deren Quellen man vertraut, als auf Pakete Dritter. Alle FlatHub-Pakete werden zudem auf vertrauenswürdigen Build-Servern gebaut.

Quelle: https://www.pro-linux.de/news/1/25887/ubuntu-snap-store-enthielt-malware.html

Von früh bis spät nur Qualität. Und - für bei Linux und Co. mittlerweile schon fast selbstverständlich - kein einziger Hinweis auf snapcraft, because "Not only are snaps kept separate, their data is kept separate too. Snaps communicate with each other only in ways that you approve.".

Kann jetzt endlich mal jemand einen anständigen Fork von Linux rausbringen und so Abfallhalden wie Ubuntu, open Suse und wie die ganzen anderen "Du bist zu faul um Dokumentationen zu lesen und sowieso zu dumm um sie zu verstehen? Kein Problem! Wir haben da genau das richtige für Dich!" - Distributionen heißen entsorgen?

Zwei Sicherheitslücken und einige Regressionen wurden jetzt im Debian-Kernel gepatched. Beide waren der Kategorie »high« zugeordnet.

Das Debian Security Advisory 4196-1 bezieht sich auf zwei Sicherheitslücken mit den CVE-Nummern CVE-2018-1087 und CVE-2018-8897, die jetzt im Debian-Kernel gepatched wurden. CVE-2018-1087 war von Kernel-Entwickler Andy Lutomirski entdeckt worden. Die Lücke in der Kernel-based Virtual Machine (KVM)ermöglichte es einfachen KVM-Anwendern, ihre Privilegien auszuweiten oder das Gastsystem zum Absturz zu bringen.

Die zweite Lücke, CVE-2018-8897, entdeckte Nick Peterson von der Firma Everdox Tech LLC. Sie ermöglichte unprivilegierten Anwendern, Kernel-Abstürze durch eine Lücke herbeizuführen, die darin lag, wie der Kernel mit nach Mov-to-SS- oder Pop-to-SS-Instruktionen erlaubten Debug-Exceptions umgeht. Beide Lücken, wurden in ihrer Gefährlichkeit als »high« eingestuft.

Zudem wurden drei Regressionen beseitigt, die ein Kernel-Update letzte Woche in Debian GNU/Linux 8 »Jessie« eingeschleppt hatte. Dieses Update hatte weitere Patches gegen Spectre v1 gebracht und insgesamt 27 Sicherheitslücken geschlossen, einschließlich einer bereits seit acht Jahren vorhandenen Lücke in MMap.

Anwender von Debian GNU/Linux 9 »Stretch« und Debian GNU/Linux 8 »Jessie« sollten die Updates zeitnah einspielen, indem sie auf Kernel 4.9.88-1+deb9u1 respektive 3.16.56-1+deb8u1 aktualisieren. Updates, die auf einem Debian Security Advisory (DSA) beruhen, werden in Debian möglichst zeitnah gepatched und ausgeliefert. Diese Updates werden dann später zusammen mit bereinigten Fehlern kumulativ in einem Update der jeweils stabilen Veröffentlichung herausgegeben. Das letzte Update dieser Art war die Aktualisierung auf Debian 9.4. Ein Termin für Debian 9.5, das dann auch die gestern veröffentlichten Kernel-Updates umfasst, ist noch nicht bekannt.

Quelle: https://www.pro-linux.de/news/1/25878/sicherheitsl%C3%83%C2%BCcken-im-debian-kernel-geschlossen.html

Acht Jahre.. was nennt man da als Grund? Because fuck you, thats why! oder was? Tja.. was soll man dazu noch sagen? Vielleicht Leise Scheisse.., aber sonst fällt einem da nix mehr ein.

Nachdem mir der httpd(8) von OpenBSD auf die Eier gegangen ist, habe ich ihn gegen Lighttpd ausgetauscht, was auch problemlos funktioniert hat. Anschließend habe ich just for fun DokuWiki installiert und beim Aufruf von install.php It seems your data directory is not properly secured. zu sehen bekommen. chmod/chown waren korrekt gesetzt, also konnte es daran nicht liegen. Lag es auch nicht. Nach kurzer Recherche habe ich dann folgendes gefunden: https://www.dokuwiki.org/security#deny_directory_access_in_lighttpd und siehe da.. nach dem Eintrag von

$HTTP["url"] =~ "^/dokuwiki/(data|conf|bin|inc)/+.*" {

    url.access-deny = ("")

}

in der lighttpd.conf und einem anschließendem Neustart war das mit de Warnhinweis auch Geschichte.

Sodala.. Nextcloud 13.0.1, S9Y 2.1.2, DokuWiki 2017.02.19e und PostgreSQL 10.3 sind installiert und laufen; versorgt werden sie von httpd(8) und PHP 5.6. Alles nicht optimal konfiguriert und auch nicht auf dem neusten Stand, aber mir ging es erstmal nur darum, alles zum laufen zu bekommen. Android synchronisiert sich mit der passenden App bzw. DAVdroid. Momentan hat die Kiste 8G RAM, eine AMD Phenom(tm) II X4 945 Processor, 3000.63 MHzm, 300W Netzteil und 100MBit/s RJ-45, welches direkt an der Fritz!Box hängt. Gespeichert werden die ganzen Daten auf einem Raid 5 mit ins. 8TB Speicherplatz. Momentan ist das alles nur eine Spielerei, weil ich erstmal ein Energiemessgerät dazwischenhängen muss, damit ich mir einen Überblick über den Stromverbrauch machen kann. Sollte sich der in Grenzen halten, wird die Kiste gegen einen richtigen Rechner getauscht, welcher besser geeignetere Komponenten enthält.
Sollte ich mal viel Zeit und noch mehr Lust haben, werde ich die einzelnen Installationsroutinen zusammenschreiben und veröffentlichen. Jetzt is erstmal Feierabend angesagt und ich fahr zum Fischen.