Pinephone: DANKE ModemManager!

Liebe Linuxphone Fans, es ist passiert! Ich habe mich geirrt und freue mich darüber 😀

Pinephone: DANKE ModemManager!

Die ModemManagerelease 1.16.x kommt mit einer Option daher, die das Pinephone aus dem Winterschlaf holt bzw. es gar nicht erst schlafen lässt. Die Konsequenz ist, das Pinephone verpennt im Tiefschlaf keine Anrufe oder SMS mehr.

Zusammen mit dem aktuellen Fedora Megi-Kernel läuft das Pinephone jetzt wie ein „normales“ Smartphone stundenlang, weil es nicht mehr läuft, wenn es nicht mehr gebraucht wird.

Dabei kann Euch dieses kleine Projekt helfen:

https://github.com/Cyborgscode/pinephone/tree/main/suspendguardian

Das schickt das PinePhone nämlich nach 30 Sekunden Bildschirm aus in den Suspend. Mit dem neuen ModemManager bleibt das Modem wach und kann das System wecken, wenn ein Anruf kommt. SuspendGuardian macht noch mehr und dann genügend präzise konfiguriert werden.

Damit das problemlos funktioniert, macht Ihr folgendes:

cp ModemManager.service /etc/systemd/system/
vi /etc/systemd/system/Modemmanager.service

Die Zeile ExecStart= wird wie folgt geändert:

ExecStart=/usr/sbin/ModemManager –test-no-suspend-resume

Dann  „systemctl daemon-restart; systemctl restart ModemManager“ oder einen kurzen Reboot, falls das nicht klappt 😉

Da ich den neuen Kernel schon testen konnte, weiß ich, daß das Gerät (mit Modem im Tiefschlaf / also vor der Anpassung oben) in 8h knapp 4% Akkuladung verbraucht hat.

Ich habe dies bei meinem Pinephone natürlich schon gemacht und bin mal gespannt , wie viel Strom das Pine so in der Nacht verbrauchen wird. Das ist ein Game-Changer Feature fürs Pinephone!  Weil ab jetzt ist der Verbrauch quasi nur noch von der echten Nutzungsdauer von Apps abhängig.

 

Pinephone: 200mW – neuer Rekord

Wie sagte Prof. Farnsworth immer „Good News Everyone!“ und dann mußte die Mannschaft auf irgendeine tödliche Mission gehen 😀 Ich schwöre, das ist hier nicht der Fall 😉

Pinephone: 200mW – neuer Rekord

Mit dem aktuellen Megi-Fedora-Kernel 12.0.7 verbraucht das System im Deep-Sleep nur noch 200 mW und kann so 6,5 Tage in Bereitschaft bleiben. Yoda von der Fedora SIG Mobility brachte heute gute Nachricht raus. Wie er sich so lange zurückhalten konnte es zu starten ist mir aber schleierhaft 😉

Im Deep-Sleep reagiert das Modem auf Anrufe und SMS ( der Teil muß noch etwas verbessert werden ) und weckt dann den Rest vom System auf, so daß der Anruf angenommen werden kann. Mit der neuen Modemfirmware soll das noch viel besser klappen, als mit der Herstellerfirmware

Im Normalbetrieb, also erreichbar per SSH, kommt der neue Kernel auf 0.88-0.92W . Das sind 0.5 W weniger als noch vor einer Woche. Das Telefon kann mit der Leistung fast schon in den täglichen Betrieb wechseln, wenn man es zwischenzeitlich nicht zu hart ran nimmt 😉 Tagesbetrieb.. WIR KOMMEN \o/

 

ROOT Exploits in Exim < 4.94.2

Ihr fragt Euch vermutlich, wieso sich so lange gebraucht habe, das zum Thema zu machen, weil die Nachricht ja gestern noch raus kam. Der Grund ist: Sichern, Suchen und Patchen was das Zeug hält.

ROOT Exploits in Exim < 4.94.2

Insgesamt sind es 21 Lücken, welche die Pentester von Qualys gefunden haben:

Summary
Local vulnerabilities
- CVE-2020-28007: Link attack in Exim's log directory
- CVE-2020-28008: Assorted attacks in Exim's spool directory
- CVE-2020-28014: Arbitrary file creation and clobbering
- CVE-2021-27216: Arbitrary file deletion
- CVE-2020-28011: Heap buffer overflow in queue_run()
- CVE-2020-28010: Heap out-of-bounds write in main()
- CVE-2020-28013: Heap buffer overflow in parse_fix_phrase()
- CVE-2020-28016: Heap out-of-bounds write in parse_fix_phrase()
- CVE-2020-28015: New-line injection into spool header file (local)
- CVE-2020-28012: Missing close-on-exec flag for privileged pipe
- CVE-2020-28009: Integer overflow in get_stdinput()
Remote vulnerabilities
- CVE-2020-28017: Integer overflow in receive_add_recipient()
- CVE-2020-28020: Integer overflow in receive_msg()
- CVE-2020-28023: Out-of-bounds read in smtp_setup_msg()
- CVE-2020-28021: New-line injection into spool header file (remote)
- CVE-2020-28022: Heap out-of-bounds read and write in extract_option()
- CVE-2020-28026: Line truncation and injection in spool_read_header()
- CVE-2020-28019: Failure to reset function pointer after BDAT error
- CVE-2020-28024: Heap buffer underflow in smtp_ungetc()
- CVE-2020-28018: Use-after-free in tls-openssl.c
- CVE-2020-28025: Heap out-of-bounds read in pdkim_finish_bodyhash()
Acknowledgments
Timeline

Davon konnten 4 Lücken genutzt werden um die Rechte zu Root auszuweiten und 3 für Remote-Code-Executions genutzt werden, was in der Kombination nichts anderes bedeutet, als daß die Angreifer die Server übernehmen können.

„We have not tried to exploit all of these vulnerabilities, but we successfully exploited 4 LPEs (Local Privilege Escalations) and 3 RCEs (Remote Code Executions):“

Ich vermute ja, daß diese Lücken durch eine automatische Code-Analyse gefunden wurden, da ich mir kaum vorstellen kann, das ein Mensch das alles so überblicken wird. Auch den Exim-Devs wurde nicht gesagt, wie die Lücken gefunden wurden. Aber auch hier die Vermutung, daß es mit automatischen Tools und sehr viel Erfahrung der Analysten geschafft wurde.

Auf der Exim-Mailingliste wurde dies von einigen negativ hervorgehoben, wobei man immer bedenken muß, daß alle Exim Entwickler auch noch ein Berufsleben haben. Wenn dann die Patche nicht mehr kaputt machen sollen, als die Lücken selbst, kann das schon ein bisschen dauern.

Ein bisschen gedauert hat es dann auch, bis z.b. Fedora die neue Exim Version ins Stable übernommen hat. Dies geschah erst durch Benutzerintenvention ( meine 😉 ) einen Tag nach der Veröffentlichung der Lücken. Für das im Endstadium befindliche Fedora 32 gab es den Fix nicht mehr, weswegen ich jedem nur raten kann, auf 33 zu updaten, wenn er Exim betreibt.