Firefox – Bugs auf die lange Bank geschoben

Wer weiß noch, was er vor 11 Jahren gemacht hat? Bugtracker z.B. wissen es, sollten sich aber nicht 11 Jahre zurück erinnern müssen. Im Fall des Firefox-Bugs #435013 weiß ich dies auch und der Bugreport befindet sich in guter Gesellschaft 😉

Uralte Bugreports auf die lange Bank geschoben

Ein bisschen stolz darf man bei den Firefox Devs ruhig sein, ihr Produkt gibt es schon min. 11 Jahre, denn genau solange  ist der Bug #425013 bereits offen. Dabei handelt sich um eine echt knifflige Sache, nämlich die Frage: „Wann darf ein Computerprogramm es besser wissen, als der Mensch der es bedient?

In dem obigen Bugreport geht um einen technisch gesehen einfache Sache: Wenn jemand ein SSL-Zertifikat ausstellt, dann bekommt dies eine Seriennummer. Keine zwei SSL-Zertifikate des gleichen Ausstellers sollten die gleiche Seriennummer haben. Sagt die Theorie.

Die Praxis

In der Praxis kann man sich immer noch selbst Zertifikate ausstellen, und wenn man das macht, fängt das Programm, das dies für einen durchführt, bei  Eins an zu zählen. Das sind die Selbst-Signierten-SSL-Zertifikate. Die kann man ganz leicht mit OpenSSL selbst erstellen. Dauert keine zehn Sekunden.

Jetzt stellen wir uns mal vor, daß zehn Leute  Ihrem OpenSSL-Befehl sagen, mach mir ein Zertifikat für „localhost“ oder 127.0.0.1. Dann geht das jeweilige OpenSSL-Tool „openssl“ hin und macht das. Bei jedem der Zertifikate, die sich ja auf zehn verschiedenen Computern befinden, schreibt OpenSSL als Seriennummer eine Eins rein, denn auf dem jeweiligen Computer ist es das erste Zertifikat, das dort erstellt wurde.So weit, so gut.

Diesen Vorgang kann man auch automatisch durchführen. Wenn man ein Softwareprodukt verteilt, welches ein SSL-Zertifikat braucht, kann dies beim Start eines automatisch erstellen. Prima. Wir haben Verschlüsselung, den privaten Schlüssel des Zertifikates gibt es nur auf dem einem Produkt, nennen wir das mal spaßeshalber „IPMI-Modul“ und damit ist die Verbindung für die dies Zertifikat benutzt wird sicher.Genial, oder?

Die Sache mit dem Erfolg

Mal sehen. So ein „IPMI“ Modul verkauft sich, weil es für Server benutzt wird, recht gut. Es wird zig tausendmal verkauft. Bei zigtausend Servern wird beim ersten Start so ein SSL-Zertifikat mit der Seriennummer Eins (in Zahlen „1“) erzeugt und wenn man sich dahin als Käufer verbindet ist alles gut. Jetzt soll es vorkommen, daß Käufer, die dies Produkt gut fanden, gleich noch eins kaufen, ..oder zwei, …drei, .. hundertneunzehn oder tausende (Hostingunternehmen z.B.).

Auf jedem der Server wird ein Zertifikat mit der Seriennummer Eins erzeugt, aber keins der Zertifikate hat den gleichen Schlüssel drin, ergo nicht die gleichen Checksummen wie die anderen Zertifikate der anderen Server. Jetzt kommt wieder Firefox-Bug #435013 ins Spiel. Wenn man aus so einem Haufen von Servern auf das erste IPMI-Modul per HTTPS zugreift, das liegt daran, daß es Remote-Adminpanels sind, die als Webseiten recht praktisch zu benutzen sind, dann ist die Welt noch in Ordnung.

Will man jetzt aber nach dem ersten Server auch den zweiten Server so besuchen, meckert FireFox, daß es da vom selben Aussteller ( vermutlich die Default-CA von OpenSSL ) bereits ein Zertifikat mit der Seriennummer und dem Hostnamen ( der ist auch immer gleich ) gibt und man ja jetzt einer Fälschung aufgesessen wäre. Bei „normalen“ SSL-Zertifikatsproblemen, wie abgelaufenen Gültigkeitsdaten, kommt  jetzt eine Nachfragemöglichkeit, ob man das ausgelaufene Zertifikat trotzdem benutzen will. Per Definition geht es bei den meisten SSL-Zertifikaten um Verschlüsselung der Datenübertragung. Bei WebShops geht auch schon einmal um Authentifizierung, also den Beweis, daß man der ist, der man vorgibt zu sein.

Jetzt ist ein zeitlich ausgelaufenes Zertifikat im Bezug auf Verschlüsselung nicht so schlimm (kann auch schlimm sein, aber bei Otto-Normal-Webseiten eher nicht), weil der Schlüssel wird ja nicht dadurch schlechter oder „ungeheim“, nur weil in dem Zertifikat das Datum von Vorgestern drinsteht.

Bei Seriennummern ist das anders…

Bei Seriennummern ist das anders, weil eine Seriennummerkollision wie oben beschrieben der Versuch sein kann, ein anderes Zertifikat so geschickt nachzuahmen, daß ein Man-in-the-Middle-Angriff auf den Webseitenbesucher nicht bemerkt würde. Beim MITM-Angriff setzt sich der Angreifer zwischen Besucher und Webseite und simuliert beiden Seiten, daß er jeweils der Andere wäre, um so an die verschlüsselten Daten zu kommen, da er den Endpunkt der jeweiligen Kommunikation darstellt.

Das kann nur funktionieren, wenn das Zertifikat, daß der Angreifer präsentiert, vom Browser als das alte, bereits bekannte, Zertifikat eingestuft wird und daher muß es min. die gleiche Seriennummer haben. Ergo, findet man zwei gleiche Seriennummern in Zertifikaten, die den gleichen Namen und Aussteller haben, aber einen anderen Inhalt (Public-Key), so kann es sich nur um eine Fälschung handeln. Das ist Browserlogik und an sich stimmt das auch so. Es ist also Zeit Alarm zuschlagen und dem Benutzer mitzuteilen, daß da was ganz böse im Argen ist und das macht Firefox auch.

Nicht alles was rot blinkt, ist ein Atomsprengkopf im Anflug

Das Problem im Falle der zwei+X IMPIs ist nun, daß es kein Angriff ist, sondern eine Folge der oben beschriebenen Umstände, daß die Zertifikate automatisch erstellt wurden und mangels Vorgänger, die Seriennummer Eins haben. Das kann der Browser nicht wissen, aber der Admin vor dem Monitor schon, und der erwartet von FireFox, daß er das als Mensch besser wissen darf und einen „Mach trotzdem“-Button zur Verfügung bekommt. Bekommt er aber nicht.

„Früher“(tm), als alles noch besser war ;), gab es den Button, der flog dann aber raus, weil die Masse der Menschen nun einmal kein Admin ist und Dumm&Unerfahren noch dazu. Die Mozilla-Entwickler haben entschieden, die „Mach Trotzdem“-Button zu entfernen, weil 99,5% oder mehr Prozent der Nutzer in dem Fall nicht wüßten, wann Sie den Button nicht benutzen dürfen. Kann man verstehen die Überlegung. Wieso es dann aber keine Konfigurationseinstellung gibt, die es Experten erlaubt, trotzdem einen „Mach Trotzdem“-Button zu bekommen, ist Inhalt des Firefox-Bugs #435013 .

Wenn das schon…

… solange eine getroffene Entscheidung der Devs ist, wieso gibt es dann den Bugreport noch? Jetzt könnten böse Zungen schreiben, daß dies ja die übliche Masche ist bei Mozilla, unangenehme Dinge aus zu sitzen. Dafür ist die Beweislage dann doch etwas dünn 🙂 Ja dünn, weil Indizien sind ja da sehr wohl vorhanden, wie man hier sieht:

https://bugzilla.mozilla.org/show_bug.cgi?id=479520

Das ist der berüchtigte Bugreport zu IDNA2008, den Internationalen Domainnamen und dem Kampf der deutschen Benutzer von Firefox um das ß im Domainnamen. Da ich bei der Argumentation nicht ganz unbeteiligt war, an dieser Stelle schöne Grüße an die Kollegen von DENIC, weiß ich auch noch, wie lange und vor allem zäh dieser Bugreport behandelt wurde. Die Teergruben in Los Angeles sind ein Witz dagegen 🙂 Dabei war die Sachlage eigentlich ganz einfach, ß wurde beim Original IDNA  ausgespart, weil es ein Sonderfall war, denn es gab damals kein großes ß im Deutschen Zeichenvorrat. Im ersten IDNA Regelwerk war dann auch der Sonderweg ß -> ss   vorgesehen, was im Nachhinein wirklich keine gute Idee war. Straße.de und Strasse.de waren damit gleich, was aber nicht geht, weil Domainnamen keine Aliase haben können.

Naja, langer Rede kurze Pointe, mit genug Druck haben wir es geschafft und vor drei Jahren hat Firefox endlich die Regel ß -> ss durch die korrekte IDNA2008 Punycodeumwandlung des Strings ersetzt. Seit dem Tag kann man endlich die Straße.de aufrufen 😀

Über die Gründe, warum der Bugreport zu dem Seriennummernproblem so lange offen bleibt, wo doch eine Entscheidung getroffen wurde, kann man nur spekulieren. Ich denke, dies liegt daran, daß Chrome das nicht macht. Bei Chrome kann man auf dem „Machs doch“ Button klicken, weil einer da ist. Damit hat man argumentativ schlechte Karten, wenn das große Google das anders als das viel kleinere Mozilla macht. Also schieben wir es als „Wir denken dran“ auf die Bank und irgendwann wird sich das von selbst erledigen. Persönlich glaube ich ja, daß es das nicht wird.

Wie kam ich jetzt eigentlich darauf?

Weil ich ja auch im CC stehe, bekomme ich alle Kommentare zugemailt, die es zu dem Fall gibt, und heute kam der hier rein:

Comment # 208 on Bug 435013 from at 2019-06-10 12:46:51 PDT

Problem still exists. Is there a bug associated with „devs are using the browser to try to improve the world of security, exception would hinder that. User attempts to justify unique situation, devs in denial that such a situation warrants a change.“ ???

#egotistical, #broken, #savetheworld, #thanksmom, #papersplease

I don’t have a war on hackers or viruses anymore. The new battleground features users and devs, with the devs costing us all way more lost time than viruses or hacking ever has, and I’ve been using computers since my commodore 64. If the devs don’t care, then I do know ways to make them care. Or at least see that they can’t win at this.

Wer es nicht verstanden oder gesehen hat, ich übersetze mal den Satz:

Wenn die Entwickler sich nicht kümmern, dann habe ich Wege, daß sie es doch tun, oder wenigsten merken, daß sie den Kampf nicht gewinnen können.

Das drückt den Benutzerstandpunkt eigentlich ganz gut aus, weil auch ich sehe es so, daß der Button wieder her muß, weil FF sonst unbenutzbar ist in diesem speziellen Fall. Für Admins kommt sowas nämlich überproportional oft vor und ist damit echt nervig. Ich würde ja genau wie #209 den Mittelweg wählen und einfach eine about:config Option einbauen, aber  auf mich hört ja keiner 🙁 (beim ersten mal 😀 )

Wir dürfen gespannt sein, wie lange der Bugreport noch offenbleibt. Möglicherweise ja bis Mozilla den AskFedora pullt und alle alten Bugs beim Wechsel zu einem neuen System, auf dem alten System läßt 🙂

Exim < 4.92 mit CVE-2019-10149

Jetzt muß ich es Euch doch erzählen, wo ich doch dachte, es dauert noch länger bis die Katze aus dem Sack ist. Ok, Exim < 4.92 hat eine schwerwiegende Sicherheitslücke, die man auch noch trivial ausnutzen kann: CVE-2019-10149

Um die Schwachstelle wurde viel Wirbel gemacht, dummerweise bekam bislang niemand die Zähne auseinander, ob man das auch ohne Update abwehren kann. Schauen wir uns mal an worum es überhaupt geht.

Was ist der triviale Exploit?

Es reicht, wenn man als lokaler Angreifer eine Email mit dem Sendmailersatz von Exim an „<${run{bash}}@zieldomain.de>“ sendet. Im Augenblick wo die zugestellt wird, wird der eingebettete Befehle (hier bash) als Root ausgeführt.

Das ganze kann man ggf. auch per Remote ausführen, so daß es eine richtig fiese Schwachstelle ist. Betroffen sind aber nur Versionen  > 4.87 < 4.92 . Dazu müssen aber diverse Dinge in der Config erlaubt sein, was in der Defaultkonfig nur teilweise der Fall ist. z.b. kann man keine „/“ in dem Befehl unterbringen, weil das unerlaubte Zeichen sind. Das schränkt den Angreifer natürlich stark sein.

Da selbst auf der Eximliste bis heute viel Geheimniskrämerrei im Spiel war, hier die ebenso triviale Gegenmaßnahmen:

Gegenmaßnamen

Einfach kein „$“ in Emailadressen erlauben 😀 Das war es. Da fiel mir nur ARGS zu ein 😀

Das hier kommt in Eure Exim Konfiguration rein, dann Exim neu starten:

acl_check_rcpt:

deny message = Restricted characters in address
domains = +local_domains
local_parts = ^[.] : ^.*[\$@%!/|]

deny message = Restricted characters in address
domains = !+local_domains
local_parts = ^[./|] : ^.*[\$@%!] : ^.*/\\.\\./

….

acl_check_mail:

drop message = Restricted characters in address
condition = ${if match{$sender_address}{\N.*\$.*run.*\N}{1}{0}}

# WICHTIG: Vor dieser Anweisung reinschreiben, sonst Essig!

accept hosts = +relay_from_hosts

Das würgt den Angreifer ab, bevor die Email zugestellt wird.

Die bessere Gegenmaßnahme wäre natürlich auf einen aktuelleren Exim umzusteigen. Aber wie das so ist, es gibt halt immer „Gründe“ warum und wieso was nicht aktualisiert werden kann.

Keiner bekommt die Zähne auseinander…

Was mich am allermeisten an der Lücke nervt ist, daß diese billige Gegenmaßnahme im Advisory von Qualys und in den Hinweisen vom Exim Team nicht vorkommen. Bei den Exim Leuten kann ich es noch verstehen, weil die den Bug selbstständig schon Anfang des Jahres gefixt hatten und halt mit Recht sagen können: Mach halt Updates.

Bei Qualyssieht anders aus, die schreiben :

As per the distros list policy:

Below is an abridged version of our advisory (with all the vulnerability
details, but without exploitation details); we will publish the complete
version in 24 hours, or as soon as third-party exploits are published,
whichever happens first.

We believe that it makes no sense to delay this any longer than that:
this vulnerability is trivially exploitable in the local and non-default
cases (attackers will have working exploits before that, public or not);
and in the default case, a remote attack takes a long time to succeed
(to the best of our knowledge).

Schön das Ihr den Exploit weggelassen habt, wie wär es mal mit dem Workaround, so das die guten Jungs einen kleinen Vorsprung haben?  Und dieser kryptische Hinweis „a remote attack takes a long time to succeed“ meint übrigens, das man seinen Exim mal alle 24h neu starten sollte, weil es da wohl irgend einen Scheiß mit „Teergruben“ gibt.

Das sind i.d.R. Spamfallen, die so langsam antworten, daß der Angriff des Angreifers einfach zäh wie in einer Teergrube abläuft, bis hin zu „gar nicht voran kommt“. So was in der Art nutzen die Angreifer hier aus. Daher einmal im Cron „killall -9 exim; systemctl restart exim“ per Cron: Fertig.

The Revenge of Mariadb IV

Es ist mal wieder Zeit für eine MariaDB Geschichte. Keine Panik, die wird nicht wieder biblisch werden 🙂

Es war mal wieder Zeit für ein OS-Upgrade

Mittlerweile waren drei OS-Releases ins Land gegangen und eine sich anbahnende Sicherheitslücke im Exim .. PSSST! Ich habe sie Euch nicht verraten. Tut so, also wenn Ihr nächste Woche das erste mal davon gelesen habt, ja? 😉 .. zwang zu einem schnellen Update auf eine nicht betroffene Version. Fedora 29 sollte es sein 😉

Nun, glücklicherweise war auch ein anderer Testserver noch auf der gleichen alten OS Release, so daß er als Testlauf herhalten durfte. Dieser Test lief ausgesprochen positiv ab, um genau zu sein, makellos. Daher wurde kürzestfristig entschieden, auch den eigentlichen Kandidaten auf die gleiche Art zu updaten. Ein Snapshot der VM und 30 Minuten später  war das Update komplett und der Server startete wieder.

Mailserver, Webserver, IMAP-Server, diverse Dienste liefen. Was natürlich nicht lief war die MariaDB .. Ätzzz. N I C H T  S C  H O N  W I E D E R!   Auch gutes Zureden, energisches Nachtreten mit systemctl änderte nichts an diesem Status, der Datenbankserver startete nicht.

Same procedure als last year, Miss Sophie?

Leider nein. Letztes mal hatte sich bekanntlich ein Konfigfile des Systemd geändert, so daß die zum Start nötigen Limits nicht gesetzt wurden. Natürlich wurde der DIFF Test vom letzten mal auch wieder angewendet, zeigte aber keinen Unterschied an. Also mußte die gute alte Methode „Start den Dienst von Hand, dann bekommst Du Infos“ herhalten.

Wie macht man das?

Wir schauen uns mal an, was der Systemd so starten wollen würde:

cat /usr/lib/systemd/system/mariadb.service

Da findet dann das hier:

ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n
# MYSQLD_OPTS here is for users to set in /etc/systemd/system/mariadb@.service.d/MY_SPECIAL.conf
# Note: we set –basedir to prevent probes that might trigger SELinux alarms,
# per bug #547485
ExecStart=/usr/libexec/mysqld –basedir=/usr $MYSQLD_OPTS $_WSREP_NEW_CLUSTER
ExecStartPost=/usr/libexec/mysql-check-upgrade

Das POST können wir ignorieren, soweit kommen wir nicht, bleiben nur Pre und der eigentliche Dienststart.

Das in den einschlägigen Envfiles  unter /etc/sysconfig/ nichts steht, reicht also ein :

/usr/libexec/mysqld –basedir=/usr

für den Test aus. Ja super.. eine Fehlermeldung:   Can’t set requested open_files (1024) to 2000 …

Das lag an dem ulimit hier:

# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 32088
max locked memory (kbytes, -l) 16384
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 32088
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Damit kann nicht mal die minimale Version der Datenbank starten 😉 Ergo geben wir ein: „ulimit -n 99999“ und starten es nochmal und siehe da, es hat sich doch wieder was geändert:

2019-06-04 23:13:41 0 [ERROR] /usr/libexec/mysqld: unknown variable ‚innodb_additional_mem_pool_size=50M‘
2019-06-04 23:13:41 0 [ERROR] Aborting

Wenn man denn endlich mal in Logfile schaut, sieht man dort auch die Warnung, daß sich das ja mal ändern könnte. Wer rechnet schon mit damit, daß da jemand mal Ernst macht 😉

2019-05-26 09:18:16 b753fd80 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB’s internal memory allocator.
2019-05-26 9:18:16 3075734912 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

Merke, erst ins Datenbank Log schauen, dann Server updaten!

Drei OS-Versionen sind dann vielleicht doch etwas happig bei einem Update. Diese Option findet man, so man sie gesetzt hat, in der Datei /etc/my.cnf . Anweisung auskommentieren, diesmal Datenbank über systemctl starten und läuft wieder 🙂

Und hier dachte ich eigentlich, ist die Story zu ende… war sie aber nicht!

Der an diesem Master angeschlossene Replications Elf ( Sklave sagt man im PCSG nicht mehr 😉 ) mochte die Replikationsblöcke vom Master nicht mehr lesen, weil Checksumme unbekannt! Das lag daran, daß der Replikations Elfe eine ältere Datenbankversion laufen hatte, da LTS. Einer langen Suche kurzes Ende:

Elfen anhalten: mysql -p -e „stop slave
auf den Master connecten: mysql -p -e „set global binlog_checksum=’NONE‘; SHOW MASTER STATUS;“ ausführen.

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000138 | 521505   |              |                  |
+------------------+----------+--------------+------------------+

Datenbank auf dem Master dumpen, auf den Elfen kopieren. Auf dem Elfen die Datenbank wipen, den SQL Dump einspielen.

Auf dem Elfen : mysql -p -e „change master to MASTER_LOG_FILE=’mysql-bin.000138′, MASTER_LOG_POS=521505;start slave

Sollte wieder gehen. Ging nicht.. Neuer Fehler! Statt:

Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave can not handle replication events with the checksum that master is configured to log; the first event 'mysql-bin.000136' a'

gabs jetzt :

Last_IO_Errno: 1045
Last_IO_Error: error connecting to master 'test@masterserver:3306' - retry-time: 60  retries: 86400

Er zum Geier ist „TEST“ !?

Tja, keine Ahnung wie das passieren konnte, aber der „change master to …“ Befehl hatte den Replikationsusernamen durch „test“ ersetzt! Einfach so! Passwort war ok, Servername war ok, Username weg! Wie geil ist das denn ?!?!?

Also nochmal mit dem change master an den Elfen ran:

/usr/bin/mysql -p -e „stop slave;;CHANGE MASTER TO MASTER_USER=’myreplicationusername‘,MASTER_PASSWORD=’MeinPasswort‘;start slave

Da machste was mit als Admin … Ich wollte doch nur den Exim abdichten, nicht das Rad neu erfinden! Naja, jetzt gehts ja erstmal wieder 🙂 Und bevor noch einer fragt, nein, der Server hatte extern nur Port 25 zu bieten, deswegen ja auch das Update 😉