News Debian 8 Jessie: Kritische Fehler gefährden Veröffentlichung im April

[Daaron]

So hab ich den aktuellsten Kernel (alle 2 Monate 5 Minuten Aufwand) und FF/TB sind auch aktuell. Der Rest ist mir egal, da er funktional sein muss. Noch nie so en wartungsarmes (und trotzdem aktuelles) System gehabt.

Du weißt schon, dass für den Kernel regelmäßig Sicherheitsupdates kommen, und du mit deiner 2-Monate-Methode im Zweifel fast 2 Monate mit Lücken im Kernel rum gurkst?

Was ich viel weniger verstehe, ist, was alle an SysVinit so toll finden, dass es da bei Debian so ein Gezanke drum gibt.

Es geht nicht darum, dass SysVinit toll ist, es geht darum, dass Systemd SCHEISSE ist.
SysVinit musste weg, das ist klar. Aber die Alternative Upstart wäre weit weniger pervers tief im System verankert gewesen als Systemd. Systemd hat etwas von einem Virus, der sich in jede Komponente des Systems einklinken will, vom Logging bis zum Log-In.

Dass, was Systemd bietet, ist einfach ein Widerspruch gegen die Philosophie hinter Unix/Linux: Mach, wie es DIR gefällt. Sobald eine Distribution auf Systemd gewechselt hat gilt: "Mach, wie es Poettering gefällt"... und ganz ehrlich: Diese Flachpfeife könnte genauso gut bei Microsoft arbeiten.
Systemd behebt allerhand Probleme, die Systemd eigentlich nicths angehen. Das Thema war "Schaffe ein neues, besseres Init-System"... und das hat Upstart auch toll gelöst. Systemd macht daraus "Schaffe einen Allgeist, ohne den gar nichts mehr geht"

 

[boarder-winterman]

Im Zweifel klappen die Updates genauso gut oder schlecht wie bei Ubuntu, ist ja dasselbe in Grün.
Von daher: Warum kein Upgrade der 12.04-Installation auf 14.04? Dann haste für Kern-Pakete Support bis 2019. Da ein verlässliches Debian LTS ja weiter in den Sternen steht, wäre das doch sicher ne Alternative.

Von Ubuntuupgrades bin ich endgültig weg.
Bisher bei allen Versuchen ein zerstörtes System mit einem Haufen Arbeit gehabt.
Nein Danke, jetzt bekommt Debian eine Chance.

 

[Daaron]

Dann hast du bei Ubuntu aber jedes Mal viel falsch gemacht. Ich habe dieselbe Installation über viele Jahre mit geschleppt, ohne nennenswerte Probleme. Da kann man also getrost davon ausgehen, dass du bei Debian genau dieselben Fehler machen wirst. Der Upgrade-Prozess ist intern derselbe:
- ändere die Sources-Liste auf die neue Paketquelle
- aktualisiere alle Pakete inkl. Abhängigkeiten
- nutze Autoremove, um unbenutzte Altlasten zu entsorgen

 

[boarder-winterman]

Genau so habe ich das auch gemacht.
Fazit: System zerlegt.

Ich habe keine Fremdquellen, auf dem Server nichtmals unfreie Pakete.
Es hat alles nichts geholfen.

Werde jetzt mal Debian antesten. Die aktuelle Installation kann ich aber nicht mehr mitschleppen, da ist vieles vermurxt.
Mauszeigerverschwinden ist da noch das geringste Problem.

 

[exuser0815]

Du weißt schon, dass für den Kernel regelmäßig Sicherheitsupdates kommen, und du mit deiner 2-Monate-Methode im Zweifel fast 2 Monate mit Lücken im Kernel rum gurkst?

Hallo Schlaubi Schlumpf.

Ja weiss ich. Und? Was wird mir hier passieren, hintern NAT Router?
Und was wuerde es bringen den Standardkernel zu verwenden, wenn ich den Server ohnehin nur alle 2 Monate boote?

 

[Daaron]

Also du spielst für alles immer fleißig Patches ein, aber für den Kernel denkst du dir plötzlich "Ach, egal... is ja NAT"? Wenn der Kernel nicht sicher ist, dann ist NICHTS sicher.
Und dein Reboot-Problem... Tja. Da musst du ihn halt beim Kernel-Update doch mal neu starten. Oder du musst auf eine Distribution setzen, die Kspice (und ähnliches) bereits beherrscht.

 

[exuser0815]

Rotfl.

Erklaer mir bitte, wie du ein System angreifst, welches:
1. hinter einem NAT Router steht
2. kein einziges Port/Service im Internet anbietet
3. keine anderen User drauf sind, nur ich
4. IRC/Jabber/Web/Email Client laufen (und ein paar Buero Dinge ohne Internetverbindung)

d.h. selbst wenn der Kernel remote exploitbare Luecken haette, wuerdest du sie nicht ausnutzen koennen. Zumal es den letzten Remote Exploit fuer 2.6.24? gab?
Mein Setup is sicherer als das jedes Hosters!

Viel Glueck!

 

[Kenneth Coldy]

Angriffe die über IRC/Jabber/Web/Email Client initiiert werden und den Kernel attackieren sind nun aber wirklich nicht sooo exotisch.

 

[Daaron]

Erklaer mir bitte, wie du ein System angreifst, welches:
1. hinter einem NAT Router steht
2. kein einziges Port/Service im Internet anbietet
3. keine anderen User drauf sind, nur ich
4. IRC/Jabber/Web/Email Client laufen (und ein paar Buero Dinge ohne Internetverbindung)

http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-1690.html
Das hat mich jetzt eine Google-Suche nach "irc remote kernel exploit" und nem Klick auf das 2. Resultat gekostet...

Der Ball ist jetzt definitiv in deinem Feld.

 

[exuser0815]

1. von 2014
2. fuer 3.12.8
3. muss man dafuer iptables des kernels verwenden (mache ich nicht)
4. funktioniert bei mir DCC ohnehin nicht, dank NAT Router (und wie ich schon gesagt hatte, keine Ports zum Linux Server weitergeleitet)

Koennte also jetzt noch 3.12 nutzen, ohne Probleme.

Ball zurueck.

 

[Daaron]

Du wolltest ein Angriffsszenario, ich habe dir in wenigen Sekunden eins geliefert, das noch nicht so alt ist. Wer sagt dir, dass dir RCs von 4.0 nicht eine ähnlich Schwachstelle haben?

Kernel müssen gepatcht werden. Wenn dem nicht so wäre, wieso dann die Mühe, Live-Patching endlich massentauglich zu machen?

 

[obz245]

Durch einen alten Laptop habe ich immer Kontakt mit Linux. Eigentlich bin ich bei Arch hängen geblieben. Aber bei dem alten Ding habe ich Debian 6 mit LXDE installiert und das Ding rennt noch besser als mit Arch.

Auf meinen großen rennt Debian 8 Jessie Testing und kann mit QEMU nebenher noch ein Windows 8.1 starten mit durch gereichter zweiter Grafikkarte. Auch hier Top Leistung.

 

[exuser0815]

Du wolltest ein Angriffsszenario, ich habe dir in wenigen Sekunden eins geliefert, das noch nicht so alt ist. Wer sagt dir, dass dir RCs von 4.0 nicht eine ähnlich Schwachstelle haben?

Kernel müssen gepatcht werden. Wenn dem nicht so wäre, wieso dann die Mühe, Live-Patching endlich massentauglich zu machen?

Ich wollte ein Angriffsszenario fuer meinen Einsatzzweck, weil DU DICH ueber mein Setup lustig gemacht hast.
Und du hast keines geliefert, weil es keines gibt.
Zumindest gab es seit Jahren nicht einen Kernel Bug, der mein Setup verwundbar gemacht haette.

Auch im "echten Leben" wird nicht planlos alles immer gepatcht, nur weil irgendwo etwas anfaellig ist.
Der erste Schritt ist immer, den Exploit zu reproduzieren um zu sehen, ob man ueberhaupt verwundbar ist. Wenn ja, wird meistens zuerst ein Workaround versucht, damit man nicht patchen muss. Anstaendige Datacenter haben Zeitfenster in denen sie patchen duerfen, und idr. sind das insgesamt ein paar Stunden im Jahr. So isses zumindest bei unserer Firma.