Tag Archives: Patch

Follow-Up: Pinephone Gnome Powerbuttonpatch

Posted on by

Moin, Moin,

es tut sich was im Pinephoneland. Meinen Patch habe ich inoffiziell dem Maintainer des entsprechenden Paketes übergeben, nachdem diverse Checks eingebaut wurden, daß das nur passiert, wenn es sich um ein Pinephone oder andere mobile Geräte handelt.

Follow-Up: Pinephone Gnome Powerbuttonpatch

Wer mal sehen möchte:

do_config_power_action (GsdMediaKeysManager *manager,
                        GsdPowerActionType   action_type,
                        gboolean             in_lock_screen)
{

#ifdef __aarch64__
        int status = 0;
#endif
        switch (action_type) {
        case GSD_POWER_ACTION_SUSPEND:
#ifdef __aarch64__
                // only use it on devices that have a mobile-greeter like pinephones
                if( access( "/usr/bin/lightdm-mobile-greeter", F_OK ) == 0 ) {
                        status = system("/usr/bin/dm-tool lock");
                        if ( status == 0 ) {
                               power_action (manager, "Suspend", !in_lock_screen);
                        } else {
                                g_debug ("Execution of LightDM-Lock failed for suspend!");
                          
                                //  TODO: Escalate to OSD, because this is a security problem
                                //        Suspending a device if an intended security feature failes, is out of the question, so we deny it.
                        }
                } else {
                        power_action (manager, "Suspend", !in_lock_screen);
                }
#else 
                power_action (manager, "Suspend", !in_lock_screen);
#endif

Den ganzen Patch gibt es hier, weil Hibernate muß man ja auch abdecken.

https://github.com/Cyborgscode/pinephone/blob/main/gsd-media-keys-manager.c.patch

Jetzt kann nur hoffen, daß der Patch in offizielle Paket kommt. Mein Telefon ist jetzt jedenfalls wieder einen Schritt weiter 🙂

Wer auf seinem Handy Phosh als Desktop nutzt, der hat so einen Patch schon und braucht da nichts machen.

CVE-2019-11500: Heap-Overwrite Lücke in Dovecot

Posted on by

OOB Sicherheitslücke in Dovecot < 2.3.7.2 und < 2.2.36.4 führt schlimmstenfalls zu Remote-Code-Execution. Die Meldung vom Dovecotteam enthält einige Ungereimtheiten, die man mal aussprechen müßte.

UPDATE:  11:56 Uhr : Updates fertig ( Anweisung siehe unten )

Mögliche Remote-Code-Execution in Dovecot

Erstmal schauen wir uns an(siehe Advisory unten), was es für eine Schwachstelle ist: „OOB Write im Pre-AUTH „. Das meint, daß ein Angreifer ohne sich authentifizieren zu müssen, einen „Exploit-String“  an den Service schicken kann, der etwas überschreibt. Genauer betrachtet handelt es sich um einen HEAP Overwrite, d.b. ein Teil des internen Speichers des Prozesses kann durch den Angreifer manipuliert/überschrieben werden.

Das ist insofern kritisch, als daß im HEAP Speicher auch Programmteile und Rücksprungadressen liegen können. Gelingt es dem Angreifer die richtige Speicherstelle mit seinem Code zu überschreiben, führt der Prozess ggf. seinen Code aus, statt dem legitimen Programmcode von Dovecot.

Gelingt dies, hat der Angreifer einen privilegierten Prozess in seiner Gewalt und kann sich von dort weiter nach oben exploiten, weil er einen Fuß in der Tür hat. Da Dovecot in Teilen mit Rootrechten läuft, ist ggf. nicht mehr viel nötig um einen Server zu übernehmen:

root 18590 0.0 0.0 3688 2276 ? Ss 03:06 0:00 /usr/sbin/dovecot
root 18595 0.0 0.0 3640 2196 ? S 03:06 0:00 \_ dovecot/log
root 18617 0.0 0.1 5544 4172 ? S 03:06 0:00 \_ dovecot/config
root 18659 0.0 0.1 16552 8208 ? S 03:06 0:00 \_ dovecot/auth

Gegenmaßnahmen

Es gibt nur die Möglichkeit Dovecot auf die neueste Version zu hieven und da beginnt das Problem für viele Linuxuser, denn z.b. Fedora hat heute erst begonnen neue Versionen zu bauen, obwohl Redhat und das Fedora Team seitdem 14.8. Bescheid wissen.

Wieso das erst heute gemacht wird, liegt in der Einschätzung des Security Teams. Das kam zu der fatalen Fehleinschätzung, daß der OOB auf den Heap ja „extrem schwierig“ wäre, weil der Speicherbereich der überschrieben werden kann, zufällig wäre. Das ein Angreifer dann einfach so lange Exploitversuche wiederholt, bis es zufällig klappt, war dem Security Team offensichtlich nicht ganz klar. In Zeiten von riesigen BOT-Netzen, muß man diese Sicht der Dinge als ziemlich naiv bezeichnen, leider.

Zum Glück gibt es ja findige Blogger, die dem Team klar gemacht haben, wo bei der Einschätzung der Fehler liegt und siehe da …

Package Name dovecot
Version 2.3.7.2
Release 1.fc32
State building
Started Thu, 29 Aug 2019 07:47:34 UTC
Est. Completion Thu, 29 Aug 2019 08:10:40 UTC

Changelog * Thu Aug 29 2019 Michal Hlavinka <mhlavink@redhat.com> – 1:2.3.7.2-1
– dovecot updated to 2.3.7.2, pigeonhole 0.5.7.2
– fixes CVE-2019-11500: IMAP protocol parser does not properly handle NUL byte
when scanning data in quoted strings, leading to out of bounds heap
memory writes

es tut sich was bei Fedora.

Fazit: Manchmal braucht es nur einen, der den Arschtritt vornimmt 😉

Wie gefährlich ist die Lücke wirklich?

Das Problem liegt im Detail. Natürlich gibt es die Speicherverwürfelung von Linux als Schutzmaßnahme, aber das macht es einfach nur schwieriger, nicht unmöglich einen Exploit zu schreiben und auszunutzen. Der Knackpunkt ist genau, daß es nicht unmöglich ist, also muß man es zeitnah beheben. Der Angreifer hat im Worst-Case-Fall unendlich viel Zeit und unbegrenzt Ressourcen zur Verfügung ( eine Beschreibung eines Botnetzes 😉 ) und setz diese auch ein. Er kommt also irgendwann per Zufall durch.

Workround nicht vorhanden

Verschärfend kommt hinzu, daß es keinen Workaround gibt und keine Methode den Angriff verlässlich zu bemerken. Die Logfiles schweigen sich quasi aus:

Aug 29 09:33:26 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:16 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:17 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:18 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:19 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured
Aug 29 09:34:19 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured

Was Ihr oben seht, ist mein Versuch mit einem Beispielcode aus dem Advisory eine Logmeldung zu produzieren. Die Meldung kommt aber am Tag auf größeren System so 100-1000 mal vor, weil natürlich andere Angreifer und falsch konfigurierte Mailprogramme unsinnige Verbindungen zum Server aufmachen, ohne sich zu authentifizieren. Nichts, was ein übermäßiges Security Problem darstellt. Dies muß so ein Server einfach aushalten. Von den jetzt anstehenden Versuchen, die verwundbaren Dovecotserver zu exploiten, kann man das bisherige Rauschen aber nicht unterscheiden und das macht einen effektiven Schutz bis zum Update durch Fedora so problematisch.

Ich seh da nur : Port firewallen und per SSH durchtunneln, oder Firwalllücken für Ips aufgrund einer Auth an einem anderen Service, aber macht das mal mit tausenden von Kunden… also eher keine Lösung.

Das Advisory von Dovecot

Kommen wir zu dem Teil, bei dem ich mich fragte, wieso wir überhaupt ein Problem haben. Das Advisory gibt folgende Daten preis:

Date: Wed, 28 Aug 2019 15:06:23 +0300
Open-Xchange Security Advisory 2019-08-14

Vulnerable version: All versions prior to 2.3.7.2 and 2.2.36.4
Vulnerable component: IMAP and ManageSieve protocol parsers (before and
after login)
Solution status: Fixed by Vendor
Fixed version: 2.3.7.2, 2.2.36.4
Vendor notification: 2019-04-13
Solution date: 2019-06-05
Public disclosure: 2019-08-28
CVE reference: CVE-2019-11500

Gefunden wurde das also im April, im Juni behoben und gestern Abend wurde es öffentlich gemacht. Der 14.8. ist der Tag, an dem Redhat/Fedora davon über die distributionsübergreifende Mailingliste erfahren hat. Soweit so gut.

Wenn man sich jetzt aber die „Fixed Version“ und die Buildhistory von Fedora ansieht:

 NVR                   Built by Finished            State
dovecot-2.3.7.2-1.fc32 mhlavink 2019-08-29 08:36:07 complete
dovecot-2.3.7.1-1.fc30 mhlavink 2019-08-19 20:30:43 complete
dovecot-2.3.7.1-1.fc29 mhlavink 2019-08-19 16:12:18 complete
dovecot-2.3.7.1-1.fc32 mhlavink 2019-08-19 13:52:26 complete

Demnach wurde also am 19.8, 4 Tage nach dem internen Advisory, eine verwundbare Version für Fedora gebaut. Da fragt man sich doch „Wieso“, oder nicht?

Was mich jetzt aber wirklich umtreibt ist, daß es ja schon am 5.6. den Fix gab, der vermutlich intern auch schon eingecheckt war in die Sourcecodes und folglich in dem Build 2.3.7.1 hätte vorhanden sein müssen. Laut Github ist die 2.3.7.1. vom 23. Juli, also 1 Monat nach dem Fix:  „ Jul 23, 2019 2.3.7.1 “ .

Ich werde das leider nicht auflösen können, aber falls jemand anderes da mal Licht auf die Commithistorie werfen möchte, fühlt Euch eingeladen. Persönlich kann ich mir gut vorstellen, daß der Fix nicht ganz so foxy war, wie sich der Hersteller das gewünscht hat und er deswegen nicht gleich in den Code kam. Irgendeine andere Begründung, wäre vermutlich nicht so sexy für die Entwickler 😉

Dovecot Advisory in Natura: https://www.openwall.com/lists/oss-security/2019/08/28/3

PS: der FC32 Build ist durch, ich hoffe die anderen kommen auch gleich noch dran.

UPDATE:  11:56 Uhr

Die gefixte Version ist jetzt verfügbar und funktioniert auch ( für x86_64 ) . Ihr könnt direkt als Root Eure Pakete aktualisieren:

Fedora 29:

dnf update https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc29/x86_64/dovecot-2.3.7.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc29/x86_64/dovecot-mysql-2.3.7.2-1.fc29.x86_64.rpm

Fedora 30:

dnf update https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc30/x86_64/dovecot-2.3.7.2-1.fc30.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/dovecot/2.3.7.2/1.fc30/x86_64/dovecot-mysql-2.3.7.2-1.fc30.x86_64.rpm

Anmerkung: Wer einen anderen Backend als MYSQL benutzt, muß die Anweisung anpassen.

Sicherheitslücke in OpenOffice muß manuell gefixt werden

Posted on by

Für alle unter Euch die OpenOffice einsetzen und die Updates nicht per Distro bekommen: Ihr müßt jetzt aktiv werden!

OpenOffice hat eine „schwere“ Sicherheitslücke : CVE-2016-1513 Ein manipuliertes Officefile zu öffnen reicht schon aus.

Zunächst mal müßt Ihr auf OO 4.1.2 updaten, sofern Ihr das noch nicht gemacht habt. Dazu müssen die Pakete erstmal geladen werden. Hier die Downloadlinks für Fedora/RedHat :

Download

http://netcologne.dl.sourceforge.net/project/openofficeorg.mirror/4.1.2/binaries/de/Apache_OpenOffice_4.1.2_Linux_x86-64_install-rpm_de.tar.gz

Dann braucht Ihr noch den Patch für den HotFix :

https://archive.apache.org/dist/openoffice/4.1.2-patch1/binaries/Linux64/apache-openoffice-4.1.2-patch1-apply-Linux64.zip

Update Openoffice

  1. Das Archiv auspacken und dann in das RPMS Verzeichnis wechseln
  2. mit „su“ Root werden
  3. rpm -U *rpm

Install Patch

  1. Den Patch auspacken. Ihr findet eine Datei namens libtl.so
  2. mv {PFAD zum ausgepackten Archiv}/libtl.so /opt/openoffice4/program/
  3. Die Frage nach de Überschreiben bejahen.

Fazit

Ja, es ist ein HotFix. HotFixe sind dämlich einzuspielen, aber der ganze Updatemechanismus von OpenOffice ist nicht mehr zeitgemäß. Es gibt jetzt zwei Möglichkeiten, ich stelle allen ein Repository zur Verfügung, aber dann gehen Hotfixe unter, oder wir wechseln zu LibreOffice, weil das im Repo von Fedora gepflegt wird.

Pikant an der Lücke ist, das sie seit dem 21.Juli bekannt ist und erst jetzt ein Fix verfügabr ist. Kein Gutes Zeichen für OpenOffice.