Monthly Archives: November 2020

Zur Zeitumstellung alles Gute

Posted on by

Liebe Leser,

auch wenn es ein bisschen spät sein mag, aber wir hatten doch vor einigen Wochen die Umstellung von Sommer auf Winterzeit. Einigen ist das nicht gut bekommen 🙂

Zur Zeitumstellung alles Gute

Erinnert sich noch jemand an die Y2K Panik, weil zweistellige Jahreszahlen von jeher eine doofe Idee waren? Die ganze Zeitsteuerung geht deutlich einfacher in die Hose, wenn das ganze System exakt so funktioniert, wie es seit 30 Jahren läuft, aber eine andere Software die Fakten falsch interpretiert 😉

Wir hatten da einen kuriosen Fall im Support, den ich Euch nicht vorenthalten möchte, da man sich da einiges an Lehren rausziehen kann:

Es war einmal ein Linux-Server, der seiner Zeitzone gemäß brav am 25. Oktober die Uhrzeit von 3 Uhr auf 2 Uhr umstellte. Eine andere Serversoftware namens fcron tat wie ihr geheißen ward und startete um 2 Uhr ein Backupsystem. Das Backupsystem bemerkte, daß es a) ein Backup machen sollte und b) daß da bereits ein Job lief, ergo könnte es diesen Job jetzt ja gar nicht machen, weil zu viele Ressourcen belegt würden, oder anders ausgedrückt: Es ist nicht zielführend zwei Backups gleichzeitig laufen zulassen.

Hier könnte die Geschichte schon zu Ende sein, aber das Backupsystem war anderer Meinung, denn es fügte der Liste der zu erledigen Backupjobs, einfach noch einen Backupjob an, obwohl genau dieser Job gerade ausgeführt wurde, weil dieser beim „ersten 2:00 Uhr“ bereits gestartet war. Nun kam eins zum Anderen, es war ein sehr sehr großes Backup… wiedermal 😉 Die Admins wurden aufmerksam, als die Backupstorage 100% voll meldete und das Backup mit Fehler abbrach. Ihr wollt wissen, wie es an einem Mittwoch gegen 11 zu der Meldung kommen konnte, wenn das alles in der Nacht von Samstag auf Sonntagpassierte? Ich sagte doch, es ist ein sehr sehr großes Backup, auf einer eher schwachen Hardware 😉

Merke: Immer 1:59Uhr als Backupzeitpunkt benutzen, aber NIEMALS 2:00-2:59 nehmen 😀

Merke auch, wenn Du einen laufenden Backupjob findest, prüf doch mal, ob das evtl. der ist, den Du jetzt eigentlich starten solltest 😉

CVE-2020-15999: Der Kelch, der an Euch vorbei ging

Posted on by

Nein, heute geht es nicht um Dichtung, eher um Undichtigkeiten in Betriebssystemen 😉

CVE-2020-15999: Der Kelch, der an Euch vorbei ging

Google’s Projekt Zero hat im Oktober eine Serie von kritischen Bugs offengelegt, mit deren Hilfe iOS, Android, Windows, Macs und Linuxsysteme übernommen werden konnten. Die Lücken sind so groß, daß Apple sogar noch Iphone 5s aktualisiert und die sind seit Jahren im End-of-Live.

Ein Blick auf eine dieser Lücken zeigte, daß diese auch für Linux vorhanden war, aber unter dem Radar bliebt: FreeType < 2.10.4

„Bug #1890210 – CVE-2020-15999 freetype: heap-based buffer overflow via malformed ttf files“

Red Hat hat dazu im Bugreport geschrieben:

„A flaw was found in freetype in the way it processes PNG images embedded into fonts. A crafted TTF file can lead to heap-based buffer overflow due to integer truncation in Load_SBit_Png function.“

Wer in den letzten Tagen die Updates verfolgt hat, weiß, daß es für Chrome, FireFox, Thunderbird eine schere Sicherheitslücke beim Webseitenaufruf gab. Über den Bug im FreeType, einer Font-Rendering-Engine, die auch und gerade in Webbrowsern genutzt wird, konnte mit Hilfe eines manipulierten Fontfiles, und da zählen auch WebFonts zu, das komplette System übernommen werden.

Diese Lücke betraf uns alle, und mit alle meine ich wirklich ALLE auf dem Planeten.

Wie kann eine so simple Sache wie einen Fontrendern, zu einer Systemübernahme führen? Das liegt daran, daß es sich hierbei wohl um den ersten Schritt in einer ganzen Exploitchain handelt. Hat man erstmal den Fuß im Chrome oder Firefox, muß man nur noch dort ausbrechen können und das war bei Chrome über einen Sandbox-Escape möglich. Danach findet sich im Kernel schon eine Schwachstelle, gerade bei Handies.

Von der Tragweite der Lücke mal abgesehen, rankt sich um die Google Veröffentlichung noch einiges andere. In der Szene munkelt man von „Spionagekram“, wozu auch paßt, daß keiner der Beteiligten dazu irgendwas sagen möchte. Nachdem der Exploit verbrannt ist, dürften die früheren Nutzer ziemlich sauer auf Google sein. Das Google uns aber nicht sagen kann, woher die Exploits stammen und wie Sie darauf aufmerksam wurden, spricht dafür, daß es ein „us-heimischer“ Dienst war, sonst wären die Antworten vermutlich anders. Aber, genaueres weiß man nicht, da keiner reden will.

Also feiert, daß ein Angriff weniger auf Euch möglich ist und wer von Euch Software schreibt, denkt bitte daran, wirklich sauber zu arbeiten, weil auch die unbedeutendste Lib einen immensen Schaden anrichten kann!