Klar. Gehst in dein Kundenaccount bei Hoster, und änderst das Passwort für die DB.
Dann das in der configuration.php eintragen.
Hundertfach gemacht.
Hatte ich noch nie gebraucht, ok danke.
Klar. Gehst in dein Kundenaccount bei Hoster, und änderst das Passwort für die DB.
Dann das in der configuration.php eintragen.
Hundertfach gemacht.
Hatte ich noch nie gebraucht, ok danke.
Der Hintergrund des Erneuerns ist, dass durch die Lücke ggf. Daten über die API ausgelesen werden konnten. Zur Sicherheit sollte man also genannte Passwörter wie Datenbank neu anlegen. Nicht nur in der configuration.php.
Die Lücke war nicht so undurchschaubar, dass nicht schon andere sie ggf. zuvor rausbekommen haben.
Die Lücke war nicht so undurchschaubar, dass nicht schon andere sie ggf. zuvor rausbekommen haben.
Ja diese Unsicherheit bleibt immer, auch wenn gesagt wird das "in freier Wildbahn" noch kein darauf basierender Hack gesichtet wurde.
Nicht so wichtig, da ja meist eh abgesperrt:
Die 4.3 Development-Versionen sind auch betroffen. Die Lücke wurde heute mit Joomla! 4.3.0 Beta 2 geschlossen.
Die Nightly-Builds werden dann wohl heute Nacht nachziehen, wenn noch nicht geschehen, denke ich.
Updaten über "Hochladen und Aktualisieren".
Mir ist grad aufgefallen, dass die coniguration.php neuerdings mit CHMOD 444 statt 600 gespeichert wird, wenn man im Backend in der Konfiguration was ändert.
Mir ist grad aufgefallen, dass die coniguration.php neuerdings mit CHMOD 444 statt 600 gespeichert wird, wenn man im Backend in der Konfiguration was ändert.
Kann ich nicht bestätigen. Bei verschiedenen Seiten gerade ausprobiert.
Bleibt bei 444.
Kann ich nicht bestätigen. Bei verschiedenen Seiten gerade ausprobiert.
Bleibt bei 444.
ja, 444 ist aber neu...? ich hatte vorher immer 600. ist 600 nicht sicherer?
Hatte noch nie 600.
Du willst doch keine Schreibrechte einräumen.
Hier sind jetzt komische Leute mit seltsamen Kappen und kleiner Glocke vorne dran .
Denke ich bin für heute mal weg ...
mh... Also ich habe selten an den Berichtigungen über FTP geschraubt. Mir schien es, dass Joomla vorher die configuration.php immer automatisch mit 600 gespeichert hat. Zumindest habe ich das jetzt mal in einer 3er Version getestet. War bis heute auch mit allen 4er so.
Und jetzt speichert Joomla plötzlich mit 444 ab. Leserechte für alle???
Und jetzt speichert Joomla plötzlich mit 444 ab.
Ich hab hier lokal 3 Installationen - 1x J3 und 2x J4 - und bei allen stehen die Rechte auf 444.
So, die vom Security-Team gelieferten Infos sind in die Firewall eingetragen. Damit sollte hier schon mal alles sicher sein.
Top danke!
Verstehe das eher so, dass man in der configuration.php die Daten dort nochmals "abspeichern" soll.
christine2 , ändere vorsichtshalber doch auch die Datenbank Passwörter, so ist es sicherer.
dass Joomla vorher die configuration.php immer automatisch mit 600 gespeichert hat
Joomla hat seit je her ein chmod '0444' für unschreibbar machen und ein '0644' für temporär schreibbar machen in der Methode writeConfigFile(). Gelingt eines der beiden nicht, wird einem eine Meldung angezeigt.
Zumindest in "Normalumgebungen".
christine2 , ändere vorsichtshalber doch auch die Datenbank Passwörter, so ist es sicherer.
Ist halt schon ein bisschen ein Aufwand, wenn man eine größere Anzahl an Seiten betreut.
Ist halt schon ein bisschen ein Aufwand, wenn man eine größere Anzahl an Seiten betreut.
...aber kleiner als wenn etwas passiert.
Nicht so wichtig, da ja meist eh abgesperrt:
Die 4.3 Development-Versionen sind auch betroffen. Die Lücke wurde heute mit Joomla! 4.3.0 Beta 2 geschlossen.
Die Nightly-Builds werden dann wohl heute Nacht nachziehen, wenn noch nicht geschehen, denke ich.
Updaten über "Hochladen und Aktualisieren".
Bei einer 4.2.8-dev wird 4.2.9-dev angeboten, funktioniert aber nicht. Werde ich wahrscheinlich stanzen (Testseite).
christine2 , ändere vorsichtshalber doch auch die Datenbank Passwörter, so ist es sicherer.
Ja, Danke, habe ich (soweit) arrangiert. Bei 1er Seite will es partout nicht, da kriege ich 500er. (= anderer, ein Testserver, mehrere Seiten). Muss anderer Grund sein. .... Updates selbst funktionierten eh.
Joomla hat seit je her ein chmod '0444' für unschreibbar machen und ein '0644' für temporär schreibbar machen in der Methode writeConfigFile(). Gelingt eines der beiden nicht, wird einem eine Meldung angezeigt.
Zumindest in "Normalumgebungen".
Ja, habe auch chmod '0444' bzw. '0644'
Für heute, Gute Nacht.
Liebe Grüße
Christine
Bei einer 4.2.8-dev wird 4.2.9-dev angeboten, funktioniert aber nicht. Werde ich wahrscheinlich stanzen (Testseite).
Ja, da gibt es schon länger Probleme, dass vielleicht sogar falsche Pakete installiert werden könnten. Ob das mittlerweile gänzlich gefixt ist, habe ich den Überblick verloren.
Deshalb mein Hinweis:
Updaten über "Hochladen und Aktualisieren".
Also von https://developer.joomla.org/nightly-builds.html herunterladen.
Generell ist dieser Sicherheitsfix aber auch ein versteckter Appell an Administratoren, unnötige Erweiterungen zu deaktivieren, also z.B, alle zur Joomla-API gehörenden Plugins ("Web Services"), wenn man sie gar nicht nutzt oder nur die, für die Bereiche, die man per API nutzt.
Es gibt zahlreiche, anderweiige Erweiterungen in Joomla 4, die man oft deaktivieren kann.
Unter'm Strich tut man auch "Joomla gut", wenn nicht zu viel Unnötiges aktiv ist und es fördert die Übersichtlichkei (weswegen ich das eigentlich bei jeder Seite mach(t)e). Aber nicht zu blind vorgehen, wenigstens nicht ohne Sicherung der Tabelle #__extensions zuvor
Generell ist dieser Sicherheitsfix aber auch ein versteckter Appell an Administratoren, unnötige Erweiterungen zu deaktivieren, also z.B, alle zur Joomla-API gehörenden Plugins ("Web Services"), wenn man sie gar nicht nutzt oder nur die, für die Bereiche, die man per API nutzt.
Es gibt zahlreiche, anderweiige Erweiterungen in Joomla 4, die man oft deaktivieren kann.
Unter'm Strich tut man auch "Joomla gut", wenn nicht zu viel Unnötiges aktiv ist und es fördert die Übersichtlichkei (weswegen ich das eigentlich bei jeder Seite mach(t)e). Aber nicht zu blind vorgehen, wenigstens nicht ohne Sicherung der Tabelle #__extensions zuvor
Ich stimme Dir voll und ganz zu, aber wir haben es häufig mit Anfängern zu tun, die das nicht richtig einschätzen können.
Ich meine, man sollte bei der Installation auswählen können, was man an Core Erweiterungen braucht und das dann darüber steuern lassen.
Besser wäre es sogar, auch Core Erweiterungen nur zu installieren, wenn sie benötigt werden.
Das würde die Basis schmälern und das System sicherer machen.
Welche Plugins könnte man deaktivieren ?
Zum Beispiel:
- API Authentifizierung – Web Services Basisauthentifizierung
- API Authentifizierung – Web Services Joomla Token
Welche noch ?