Sicherheitslücke im ModulManager

Andynium · 11. Januar 2016 21:01

Der Blick über den Tellerrand hat noch nie geschadet, insbesondere, wenn es um Sicherheitslücken geht. Mir fehlt zwar die Zeit, alle bekannteren Systeme im Detail zu verfolgen, doch was mir hier in die Finger gekommen ist, war zu augenscheinlich

http://www.heise.de/newsticker/meldung/ … 68105.html
http://blog.ioactive.com/2016/01/drupal … ocess.html

Konkret waren es die folgenden Passagen, die bei mir alle Alarmglocken schrillen ließen

Die System-Updates des freien Content-Management-Systems (CMS) Drupal werden im Klartext übertragen – ein Problem, das seit 2012 bekannt ist.

Die unverschlüsselten Updates sind mit Abstand das schwerwiegendste der drei Probleme. Ein Angreifer im selben Netz wie ein Drupal-Admin kann diesem manipulierte Update-Dateien unterschieben und auf diesem Wege die Kontrolle über das CMS übernehmen.

Flugs im Code des ModulManagers (V 1.5.8) geschaut - ModuleManager.module.php, Zeile 44

Hier klicken, um den Code zum Kopieren zu markieren

  const _dflt_request_url = 'http://www.cmsmadesimple.org/ModuleRepository/request/v2/';

In der Zeile wird die URL des externen Repositorys definiert, über die die gesamte Update-Prozedur läuft. Gleiches findet sich im ModulManager der CMSMS V2

Wie ihr unschwer erkennen könnt, wird da eine Verbindung via http-Protokoll (und nicht dem sicheren https) aufgebaut. Ergo erfolgt sämtliche Kommunikation mit dem Repository unverschlüsselt, weshalb das für Drupal geschilderte Problem für CMSMS genau so relevant ist.

Die Tatsache, dass es bei CMSMS "nur" die Aktualisierung von Modulen betrifft (und nicht die System-Aktualisierung wie bei Drupal), glättet (bei mir) die Sorgenfalten keineswegs. Ob nun das System 'ne Backdoor hat oder nur ein Modul, ist praktisch ohne Bedeutung - Backdoor ist Backdoor.

Eine wirkliche Lösung ist nicht in Sicht, in Sachen SSL bzw TLS ist auf der .org keinerlei Aktivität zu erkennen, trotz dass die "Let's encrypt"-Initiative eine kostenfreie Lösung anbietet.

Soweit ihr (wie bislang empfohlen) weiterhin CMSMS in der 1er Version einsetzt, kann das Modul bedenkenlos entfernt werden und gut ist.

Für CMSMS V2 ist das ganze etwas dramatischer, da dort die gesamte Modulverwaltung in den ModulManager verlagert wurde - einfach den ModulManager löschen ist also nicht. Bereits beim ersten Aufruf des Moduls - siehe action.defaultadmin.php, Zeile 75

Hier klicken, um den Code zum Kopieren zu markieren

  $newversions = modulerep_client::get_newmoduleversions();

wird eine unverschlüsselte Verbindung zum Server aufgebaut, ungefragt natürlich. Abschalten? Nicht vorgesehen!

Und das erfolgt zu einem Zeitpunkt, an dem noch gar nicht klar ist, was derjenige, der das Modul aufruft, eigentlich möchte. Für eine Übersicht aller installierten Module braucht es keine Abfrage des Repositorys.

Vereinfacht gesagt wird da sinnlos Traffic erzeugt - möglicherweise relevant, wenn der Traffic eures Hosts ein Limit hat.

Da besteht nur die Möglichkeit, dem Server eures Hosts die Kontaktaufnahme zu externen Servern generell zu verbieten. Voraussetzung ist natürlich, dass euer Hoster diese Einflußnahme auf den Server erlaubt.

Dies geht entweder über einen Eintrag in die .htaccess

Hier klicken, um den Code zum Kopieren zu markieren

php_value allow_url_fopen Off
php_value allow_url_include Off

(probieren, ob euer Host auf "Off" oder "0" (=Null) konfiguriert ist)

oder über einen Eintrag in die config.php

Hier klicken, um den Code zum Kopieren zu markieren

ini_set('allow_url_fopen', '0');
ini_set('allow_url_include', '0');

Wenn es funktioniert, gibt's 'ne modulseitige Fehlermeldung, dass keine Verbindung zum Forge hergestellt werden konnte.

NaN · 12. Januar 2016 09:29

Abschalten? Nicht vorgesehen!

Stimmt nicht.
Ist nur versteckt.
Bei CMSms 2 in der config.php die Option $config['developer_mode'] = true; setzen und im ModulManager im Tab "Settings" die URL zum Repository entfernen.
Dann verschwinden auch die beiden Tabs zum Suchen nach Modulen.

Außerdem werden die Ergebnisse der Requests ans Repository für mindesten eine Minute gecached.
(kommt drauf an, was in den globalen Einstellungen im Tab "Weitere Einstellungen" bei "Browserzwischenspeicher-Einstellungen" eingestellt ist)

Bei den Settings kann man dann auch einstellen, ob der ModulManager deinstalliert werden darf.
Allerdings gibt es keine Möglichkeit, das Modul bei Bedarf wieder zu installieren.
monkey
Die Modulverwaltung komplett aus dem Core auszulagern war meiner Meinung nach eine blöde Idee. Wozu etwas modularisieren, was zum Modularisieren gedacht ist? Modularisierung ist nunmal eine Core-Funktion des CMS.

Ein Modul zum Installieren von Modulen ... klingt nach dem berühmten Schlüssel in der Truhe.

Andynium · 12. Januar 2016 09:56

NaN schrieb:

Abschalten? Nicht vorgesehen!
Stimmt nicht.
Ist nur versteckt.

Hand Hoch - wer kennt den Parameter $config['developer_mode'] = true;? Und wer hat ihn schon mal genutzt?

So versteckt, wie das ist, ist es für Otto Normalnutzer quasi nicht vorhanden, und damit ein Problem hmm .

Oder ist das irgendwo sachgerecht publiziert? Sehe ja auch nicht alles ...

NaN schrieb:

im ModulManager im Tab "Settings" die URL zum Repository entfernen.

Gleich die ganze URL entfernen ist aber auch bißl daneben. Denn wo nehme ich die aktuelle URL her, falls diese Funktion doch wieder mal genutzt werden soll? Ein Normalnutzer schaut ja nicht in die Sourcen. Ein einfacher Schalter "Ein/Aus" hätte es auch getan.

Das primäre Problem ist ja aber die Nichtnutzung von SSL/TLS - kann doch nicht so schwer sein, das zu aktivieren. Und die Verantwortung dafür liegt klar beim Dev-Team!

Allerdings gibt es keine Möglichkeit, das Modul bei Bedarf wieder zu installieren.

Die Installation ist nur ein Einzeiler und wurde daher offensichtlich in der ModuleManager.module.php platziert. Es wird da nur die Reposity-URL als Voreinstellung gesetzt.

Interessanter- und irgendwo auch logischerweise (Stichwort Schlüssel in der Truhe) wurde eine Deinstallation gar nicht vorgesehen.

Beitrag geändert von Andynium (12. Januar 2016 10:22)

NaN · 12. Januar 2016 10:47

Hand Hoch - wer kennt den Parameter $config['developer_mode'] = true;?

Bin auch nur im Code drüber gestolpert. ops
Keine Ahnung ob das irgendwo dokumentiert ist.

Gleich die ganze URL entfernen ist aber auch bißl daneben. Denn wo nehme ich die aktuelle URL her, falls diese Funktion doch wieder mal genutzt werden soll?

Dazu gibt es gleich daneben den Button "Reset" wink

Die Installation ist nur ein Einzeiler und wurde daher offensichtlich in der ModuleManager.module.php platziert. Es wird da nur die Reposity-URL als Voreinstellung gesetzt.

Und wer führt die Zeile aus, wenn das Modul zum Installieren von Modulen - was eben jene Zeile ausführen soll - nicht installiert ist? wink

Du musst dann an die Datenbank ran und das Ding sozusagen "per Hand" installieren.

Interessanter- und irgendwo auch logischerweise (Stichwort Schlüssel in der Truhe) wurde eine Deinstallation gar nicht vorgesehen.

Und das leitest Du woraus ab?
Weil keine eigene Funktion zum Deinstallieren existiert?
Ist doch egal.
Die Moduleinstellungen werden beim Deinstallieren automatisch alle entfernt, solange keine eigene Funktion namens AllowUninstallCleanup() definiert wurde, die false zurückgibt wink

Andynium · 12. Januar 2016 10:53

Pfff, kommt mir vor wie ein Wespennest, in das ich hier hineingestochen hab cool ... ziemlicher Murks.

NaN · 12. Januar 2016 11:02

Also halten wir einfach mal fest:

In CMSms 1 kann man den ModulManager deinstallieren. Thema erledigt.
Damit entfällt die Funktion, Module (ohne HTTPS) aus dem Modulrepository von CMSms zu beziehen und das System ist sicherer.

In CMSms 2 muss man den Developer Mode einschalten und beim ModulManager die Funktion zum Beziehen von Modulen aus dem CMSms Repository "deaktivieren", indem man in den Einstellungen die URL zum Repository löscht. Dann hat man am Ende das gleiche Resultat wie bei CMSms 1.
(Danach kann man den Developer Mode wieder deaktivieren)

Andynium · 12. Januar 2016 11:17

Danke für die Zusammenfassung smile .

Andynium · 09. August 2016 08:58

NaN schrieb:

Die Modulverwaltung komplett aus dem Core auszulagern war meiner Meinung nach eine blöde Idee.

Das hat man offensichtlich mittlerweile (fast 1 Jahr später) auch an anderer Stelle erkannt roll .

Nur - anstatt den Fehler einzugestehen und die Modulinstallation wieder in den Core zu integrieren, folgt nun dieses

http://viewsvn.cmsmadesimple.org/revision.php?repname=cmsmadesimple&rev=10731 schrieb:

Rev 10731 -- No longer allow ModuleManager to be disabled/uninstalled.

(ist aus dem Repository der kommenden 2.2)

Ja natürlich, es tut seinen Zweck.

Aber wenn ihr mich fragt ... Dünnbrettbohrer, denn für die Installation von Modulen braucht es die Modul-API nicht. So, wie der CMSMailer in den Core integriert wurde, gehörte auch der ModulManager dahin - IMHO (mein Lehrmeister hätte mir für so eine Bastellösung kräftig was gehustet, wenn ich so etwas abgeliefert hätte).

Andynium · 26. Oktober 2016 14:00

NaN schrieb:

Die Modulverwaltung komplett aus dem Core auszulagern war meiner Meinung nach eine blöde Idee. Wozu etwas modularisieren, was zum Modularisieren gedacht ist? Modularisierung ist nunmal eine Core-Funktion des CMS.
Ein Modul zum Installieren von Modulen ... klingt nach dem berühmten Schlüssel in der Truhe.

Etwas OT, aber indirekt wurde bei der letzten GeekMoot der Grund für die allgemeine Modularisierung genannt

https://twitter.com/cmsms/status/789446611273392128 schrieb:

Up now: #cmsms as an application framework by @calguy1000 #app #video #gm2016

Warum muss man ein (bislang) einfach zu bedienendes CMS zu einem Framework umbauen? Zumal es selbige bereits wie Sand am Meer gibt ops ...

owr_web · 29. Oktober 2016 09:23

Ach du sch....

was mich noch viel mehr stört, ist der Text nach framework und vor #app

Also endlich ganz offiziell, dass er sagt, es ist jetzt sein Eigentum - also nix mehr Team, sondern jetzt sind somit offiziell alle nur mehr Handlanger und Wasserträger.

Andynium · 29. Oktober 2016 16:42

owr_web schrieb:

Also endlich ganz offiziell, dass er sagt, es ist jetzt sein Eigentum

yikes yikes yikes

Hatte mich bislang nur auf den technischen Teil ("Framework") konzentriert.

Aus dieser Perspektive hatte ich es noch gar nicht betrachtet - Cafe Größenwahn. Und dann hält er noch Vorträge über lizenzrechtliche Themen... schräger geht es nicht. Jetzt fehlt nur noch, dass er dafür Geld verlangt.

Andynium · 03. November 2016 19:40

Wie gerade zu lesen ist, bringt der ModulManager noch ein anderes Problem mit.

Ist das Repository down, friert das Modul bis zum Timeout ein

https://forum.cmsmadesimple.org/viewtopic.php?t=75650

nockenfell · 04. November 2016 06:38

Kann ich bestätigen. Hatte ich diese Woche mit einer 2.1.5er.

Das Problem ist, dass danach die komplette Seite nicht mehr läuft, bis der Browser neugestartet wird.

Janl · 05. November 2016 15:01

Oh, ich bin so froh, 2.1.5 nur in einem Test und ablaufend genutzt zu haben.

Wenn sich nichts ändert, schafft jemandem die Zerstörung des Projektes, weil nicht mehr zugehört wird, wie es Nutzer erfahren, was von Entwickler als "Verbesserungen" präsentiert wird.

Da schwimmt man doch weg, oder . . .

Andynium · 07. November 2016 06:59

Janl schrieb:

Oh, ich bin so froh, 2.1.5 nur in einem Test und ablaufend genutzt zu haben.

Meinen Weg kennst du ja wink . Mal sehen, vllt bekomm ich es noch rechtzeitig als Weihnachtsgeschenk fertig...

Andynium · 28. Dezember 2016 08:17

cyberman schrieb:

Wie ihr unschwer erkennen könnt, wird da eine Verbindung via http-Protokoll (und nicht dem sicheren https) aufgebaut. Ergo erfolgt sämtliche Kommunikation mit dem Repository unverschlüsselt, weshalb das für Drupal geschilderte Problem für CMSMS genau so relevant ist.
Die Tatsache, dass es bei CMSMS "nur" die Aktualisierung von Modulen betrifft (und nicht die System-Aktualisierung wie bei Drupal), glättet (bei mir) die Sorgenfalten keineswegs. Ob nun das System 'ne Backdoor hat oder nur ein Modul, ist praktisch ohne Bedeutung - Backdoor ist Backdoor.

Fast 1 Jahr hat man benötigt, um diese (eigentlich simple) Sicherheitslücke zu schließen roll hmm sad

http://viewsvn.cmsmadesimple.org/revision.php?repname=cmsmadesimple&rev=10938 schrieb:

now use https.

Forum für CMS/made simple

#1 11. Januar 2016 21:01

Sicherheitslücke im ModulManager

#2 12. Januar 2016 09:29

Re: Sicherheitslücke im ModulManager

#3 12. Januar 2016 09:56

Re: Sicherheitslücke im ModulManager

#4 12. Januar 2016 10:47

Re: Sicherheitslücke im ModulManager

#5 12. Januar 2016 10:53

Re: Sicherheitslücke im ModulManager

#6 12. Januar 2016 11:02

Re: Sicherheitslücke im ModulManager

#7 12. Januar 2016 11:17

Re: Sicherheitslücke im ModulManager

#8 09. August 2016 08:58

Re: Sicherheitslücke im ModulManager

#9 26. Oktober 2016 14:00

Re: Sicherheitslücke im ModulManager

#10 29. Oktober 2016 09:23

Re: Sicherheitslücke im ModulManager

#11 29. Oktober 2016 16:42

Re: Sicherheitslücke im ModulManager

#12 03. November 2016 19:40

Re: Sicherheitslücke im ModulManager

#13 04. November 2016 06:38

Re: Sicherheitslücke im ModulManager

#14 05. November 2016 15:01

Re: Sicherheitslücke im ModulManager

#15 07. November 2016 06:59

Re: Sicherheitslücke im ModulManager

#16 28. Dezember 2016 08:17

Re: Sicherheitslücke im ModulManager

Fußzeile des Forums