DSM 6.x und darunter Sicherheit der Diskstation

[süno42]

Hallo zusammen,

ich habe eine DS213+ und bin etwas verwundert, daß sich Synology anscheinend keine Gedanken über die Sicherheit macht bzw. kein Sicherheitskonzept verfolgt. Fast alle Dienste laufen mit Rootrechten, obwohl dies nicht in allen Fällen zwingend notwendig ist Besonders kritisch ist dies bei Prozessen zu sehen, die direkt mit dem Internet kommunizieren bzw. Datenströme aus Verbindungen interpretieren, z.B.

• "mplayer" bei Wiedergabe von Internetradio
• "wget" für Download-Station
• …und bestimmt noch unzählige weitere

Einer dieser Prozesse muß nur einen kritischen Fehler enthalten wie beispielsweise einen Pufferüberlauf (mplayer läßt grüßen) und schon kann ein Angreifer mit Rootrechten auf der Diskstation sein Unwesen treiben. Zumindest läßt sich die Sicherheit an dieser Stelle mit einfachen Mitteln leicht verbessern, und Verminderung von Prozeßprivilegien konnte ich auch nicht feststellen.


Viele Grüße,
Süno42

 

[Puppetmaster]

Und, hast du Synology schon darauf aufmerksam gemacht?

 

[süno42]

Und, hast du Synology schon darauf aufmerksam gemacht?

Aber Natürlich, vom Himmel werden die Korrekturen wohl nicht fallen, wenn man es nicht meldet. Aber ich kann nur den Kopf schütteln, da einfachste Sicherheitsmechanismen des Betriebssystems nur aus Faulheit ausgehebelt werden.

 

[süno42]

Ich habe eine Rückmeldung von Synology erhalten. Leider nur, daß die Entwickler dies für zukünftige Releases berücksichtigen möchten. Aber ich warte mal ab, ob ich noch eine aussagekräftigere Rückmeldung erhalte.


Viele Grüße,
Süno42

 

[jahlives]

Einer dieser Prozesse muß nur einen kritischen Fehler enthalten wie beispielsweise einen Pufferüberlauf (mplayer läßt grüßen) und schon kann ein Angreifer mit Rootrechten auf der Diskstation sein Unwesen treiben. Zumindest läßt sich die Sicherheit an dieser Stelle mit einfachen Mitteln leicht verbessern, und Verminderung von Prozeßprivilegien konnte ich auch nicht feststellen.

so einfach wie du das hier beschreibst ist es aber nicht. Denn die von dir gelisteten Apps können nicht von aussen erreicht werden, sondern nur wenn du von innen nach aussen eine Verbindung aufbaust. Wesentlich kritischer sehe ich z.B. den DSM welcher immer unter root läuft und auch von extern initialisierte Verbindungen abnimmt. Technisch bedingt muss aber der DSM als root laufen, da kann man nichts einschränken

 

[süno42]

so einfach wie du das hier beschreibst ist es aber nicht. Denn die von dir gelisteten Apps können nicht von aussen erreicht werden, sondern nur wenn du von innen nach aussen eine Verbindung aufbaust. Wesentlich kritischer sehe ich z.B. den DSM welcher immer unter root läuft und auch von extern initialisierte Verbindungen abnimmt. Technisch bedingt muss aber der DSM als root laufen, da kann man nichts einschränken

Hallo jahlives,

dem kann ich nicht so ganz zustimmen. Du hast recht, die o.g. Prozesse nehmen keine eingehenden Verbindungen an, hierdurch ist die Angriffsfläche nicht ganz so hoch. Hat ein Prozeß aber erst einmal eine Verbindung nach außen aufgebaut, macht dies bezüglich Angriffe keinen Unterschied mehr. Gerade der "mplayer" baut Verbindungen zu diversen Streamingservern im Internet auf. Mit weiterer Verbreitung der Diskstations von Synology steigt auch gleichzeitig das Interesse möglicher Angreifer.

Ich sehe gegenwärtig die Angriffsfläche auf "wget" in der Downloadstation nicht als so hoch an, weil die Interpretation von HTTP-Daten im Vergleich zu anderen Anwendungen relativ gering ist und ansonsten die enthaltenen Nutzdaten evtl. mit vorheriger Dekodierung nur in eine Datei geleitet werden. Möglich sind Angriffe aber prinzipiell auch hier. Beim "mplayer" sehe ich im Vergleich schon eine viel höhere Angriffsfläche. Ausschließliche Interpretation der Nutzdaten durch den "mplayer" selbst und durch die Vielzahl seiner unterschiedlichen Codecs. In Verbindung mit der veralteten Version kann hier schon sehr viel Angriffspotential verborgen sein. Durch seriöse Streaminganbieter ist die Wahrscheinlichkeit eines Angriffs wohl geringer. Aber gerade hier lassen sich in Unkenntnis des Serverbetreibers Angriffe relativ gut plazieren, da korrekt arbeitende Streamingsoftware von den Angriffsvektoren nichts mitbekommt oder den Abspielvorgang eventuell verweigert.

Was meinst Du genau mit "dsm" als Root? Ich sehe im DSM keinen gleichnamigen Prozeß mit Root-Rechten.

Fakt ist aber, daß viele Prozesse mit Root-Rechten laufen, obwohl dies nicht nötig ist. Falls einige Prozesse wirklich mit Root-Rechten starten müssen, so können sie nach der Initialisierung beispielsweise unwiderruflich ihre Privilegien reduzieren. Ich sehe generell das Problem, wenn bei der zitierten Software schon geschlampt wird, daß es mit anderen Softwarebestandteilen höchstwahrscheinlich ähnlich aussieht. Wenn es dann noch den Kernel betrifft (beispielsweise wegen einer veralteten Version), dann braucht man über Root-Rechte nicht mehr nachzudenken. Auch wenn der Kernel stets aktuell ist, können beispielsweise die Kernelmodule von Synology ebenfalls große Löcher reißen, wenn diese mit ähnlich niedriger Qualität wie die Anwendungen ausgeliefert werden.

Alles im allen sehe ich die Politik von Synology weiterhin als sehr bedenklich an.

Grüße,
Süno42

 

[jahlives]

der gesamte DSM läuft in einem Apache unter root. Das kannst du nicht wirklich ändern, auch Rechte droppen bringt nichts, weil der DSM für 99.9% seiner Möglichkeiten (einstellungen) root Rechte braucht. du kannst als non-root ein Linux nicht wirklich verwalten.
Klar ist veraltete Software nicht unbedingt gut auch könnte Synology sicher einige Prozesse mehr als non-root laufen lassen. Beim mplayer bestimmst ja DU wann eine Verbindung und wohin sie gemacht werden darf

 

[süno42]

der gesamte DSM läuft in einem Apache unter root. Das kannst du nicht wirklich ändern, auch Rechte droppen bringt nichts, weil der DSM für 99.9% seiner Möglichkeiten (einstellungen) root Rechte braucht. du kannst als non-root ein Linux nicht wirklich verwalten.

Mit ein bißchen Energie ist das technisch kein Problem. Man könnte in das DSM beispielsweise eine sehr schlanken und gut getesteten Managementprozeß zwischen Apache und dem System schalten, welcher die Konfigurationen übernimmt, die unbedingt Root-Rechte benötigen. So kann der Apache problemlos mit eingeschränkten Rechten laufen.

Weiterhin mache ich mir um den Apache für die DSM-Konfiguration über die Weboberfläche im lokalen Netzwerk nicht so große Sorgen. Mein lokales Netzwerk ist vertrauenswürdig. Aber dennoch sollte man sich hierüber generell Gedanken machen und weiterhin über jede weitere Webanwendung, die dieser Apache-Prozeß bedient. Ein Sicherheitsgewinn wäre ein Apache ohne Root-Rechte dennoch, auch wenn der Code zigfach im Einsatz ist und Synology die Konfigurationsdateien hoffentlich nicht zerfrickelt hat.

Noch abenteuerlicher ist dagegen, daß auch der Apache-Prozeß, welcher über Port 80 Webdienste anbieten soll, mit Root-Rechten läuft.

Klar ist veraltete Software nicht unbedingt gut auch könnte Synology sicher einige Prozesse mehr als non-root laufen lassen. Beim mplayer bestimmst ja DU wann eine Verbindung und wohin sie gemacht werden darf

Siehe hierzu mein obiges Zitat. Und noch einmal: die Auslieferung dieses übermäßig veralteten mplayers ist m. E. nicht entschuldbar.


Viele GRüße
Süno42

 

[jahlives]

Mit ein bißchen Energie ist das technisch kein Problem. Man könnte in das DSM beispielsweise eine sehr schlanken und gut getesteten Managementprozeß zwischen Apache und dem System schalten, welcher die Konfigurationen übernimmt, die unbedingt Root-Rechte benötigen. So kann der Apache problemlos mit eingeschränkten Rechten laufen.
Nein kann er eben nicht, denn bei deinem Bsp wäre es so, dass ein unprivilegierter Prozess einen Prozess unter root dazu bringen kann etwas zu tun. Hälst du das für sicherer? Wie verhinderst du eine direkte Kommunikation von anderen Prozessen mit diesem root Prozess? Da muss man sehr sehr aufwändig Absicherungen programmieren

Weiterhin mache ich mir um den Apache für die DSM-Konfiguration über die Weboberfläche im lokalen Netzwerk nicht so große Sorgen. Mein lokales Netzwerk ist vertrauenswürdig. Aber dennoch sollte man sich hierüber generell Gedanken machen und weiterhin über jede weitere Webanwendung, die dieser Apache-Prozeß bedient. Ein Sicherheitsgewinn wäre ein Apache ohne Root-Rechte dennoch, auch wenn der Code zigfach im Einsatz ist und Synology die Konfigurationsdateien hoffentlich nicht zerfrickelt hat.

Noch abenteuerlicher ist dagegen, daß auch der Apache-Prozeß, welcher über Port 80 Webdienste anbieten soll, mit Root-Rechten läuft.
Und das ist gar nicht korrekt! Der läuft unter dem User nobody. Gewisse Arbeiten müssen jedoch mit root Rechten erfolgen: z.B. Keyfiles einlesen oder Sockets öffnen.
Apache macht das gleich wie jeder andere Serverdienst welcher mit master/slaves läuft. Der master läuft als root und startet die slaves mit eingeschränkten Usern. Die Kommunikation gegen aussen findet dann IMMER via diese unprivilegierten Prozesse statt. Der Prozess unter root wird nicht direkt angesprochen. Wenn aber einer der slaves etwas von einem anderen Slave will, dann geht diese Anfrage via den master Prozess. Dieser fragt dann den anderen Slave nach der Info und reicht die Antwort dem anfragenden Slave durch. Ein klassisches Beispiel dafür wäre auch postfix. Es darf niemals sein, dass zwei Slaves direkt miteinander kommunizieren können

glaub mir: root loszuwerden ist nicht so einfach wie du dir das vorstellst. Gerade wenn es um die Systemverwaltung geht. Schau dir doch einfach mal eine andere Verwaltungssoftware z.B. Webmin an. Was glaubst du unter welchem User diese Prozesse laufen?
Das mit einem unprivilegierten Prozess, der einen Prozess unter root anweist etwas zu tun geht eigentlich nur dann, wenn der Master und der Slave Prozess zu der gleichen Software gehören. Sprich wenn der Slave auch von diesem Master gestartet wurde. Nur dann hat der Masterprozess eine Möglichkeit zu kontollieren dass der anfragende Slave auch wirklich zu ihm gehört und auch von ihm gestartet wurde. Um in deinem Vorschlag zu bleiben: man hätte einen Apache unter einem eingeschränkten User und irgendeinen Master Daemon welcher unter root die Anfragen entgegen nimmt und mit seinen Rechten ausführt. Wie willst du im Master prüfen ob der Request wirklich vom legitimen Slave Prozess her kommt? Der Master wäre dann ja ein Syno-Eigengewächs und der Slave der Apache.
Ganz ehrlich, beide Arten sind nicht optimal in Bezug auf Sicherheit, aber das kleinere Übel ist imho definitiv wenn ein spezieller Webserver unter root läuft.

 

[süno42]

Mit ein bißchen Energie ist das technisch kein Problem. Man könnte in das DSM beispielsweise eine sehr schlanken und gut getesteten Managementprozeß zwischen Apache und dem System schalten, welcher die Konfigurationen übernimmt, die unbedingt Root-Rechte benötigen. So kann der Apache problemlos mit eingeschränkten Rechten laufen.

Nein kann er eben nicht, denn bei deinem Bsp wäre es so, dass ein unprivilegierter Prozess einen Prozess unter root dazu bringen kann etwas zu tun. Hälst du das für sicherer? Wie verhinderst du eine direkte Kommunikation von anderen Prozessen mit diesem root Prozess? Da muss man sehr sehr aufwändig Absicherungen programmieren

Was glaubst Du denn, wie die Sache derzeit läuft. Ein unprivilegierter Prozeß (Dein Internetbrowser) instruiert einen privilegierten Prozeß (Apache), Parameter Deiner Diskstation zu konfigurieren, wobei für die Konfigurationsvorgänge Root-Rechte notwendig sind. Der einzige Unterschied ist, daß diese Konfigurationsbeziehung verteilt über eine Netzwerkverbindung abläuft. Man muß überhaupt nicht aufwendig absichern! Im anderen Modell muß sich der nun unprivilegierte Prozeß (Apache) gegenüber dem mit Root-Rechten laufenden Managementprozeß lediglich authentifizieren. Der einfachste Weg ist hier, die an den Webserverprozeß übergebenen Anmeldedaten transparent an den Managementprozeß weiterzureichen (Proxy).

Dies macht das System auf jeden Fall sicherer. Diese Methode kann eine eventuelle Systemkompromittierung natürlich auch nicht 100%tig verhindern, zumal dies unmöglich ist. Das ist aber auch nicht der Anspruch dieser Diskussion.


[...]

Noch abenteuerlicher ist dagegen, daß auch der Apache-Prozeß, welcher über Port 80 Webdienste anbieten soll, mit Root-Rechten läuft.

Und das ist gar nicht korrekt! Der läuft unter dem User nobody. Gewisse Arbeiten müssen jedoch mit root Rechten erfolgen: z.B. Keyfiles einlesen oder Sockets öffnen.
Apache macht das gleich wie jeder andere Serverdienst welcher mit master/slaves läuft. Der master läuft als root und startet die slaves mit eingeschränkten Usern. Die Kommunikation gegen aussen findet dann IMMER via diese unprivilegierten Prozesse statt. Der Prozess unter root wird nicht direkt angesprochen. Wenn aber einer der slaves etwas von einem anderen Slave will, dann geht diese Anfrage via den master Prozess. Dieser fragt dann den anderen Slave nach der Info und reicht die Antwort dem anfragenden Slave durch. Ein klassisches Beispiel dafür wäre auch postfix. Es darf niemals sein, dass zwei Slaves direkt miteinander kommunizieren können

Ich habe es mal geprüft, ich habe mich wohl geirrt, kann auch mal passieren. Stimmt, der Apache delegiert dies an ein Kindprozeß unter der ID "nobody". Das hätte ich Synology jetzt nicht gerade zugetraut. Wobei dies womöglich eher der Standardkonfiguration von Apache zuzuordnen ist.

glaub mir: root loszuwerden ist nicht so einfach wie du dir das vorstellst. Gerade wenn es um die Systemverwaltung geht. Schau dir doch einfach mal eine andere Verwaltungssoftware z.B. Webmin an. Was glaubst du unter welchem User diese Prozesse laufen?
Das mit einem unprivilegierten Prozess, der einen Prozess unter root anweist etwas zu tun geht eigentlich nur dann, wenn der Master und der Slave Prozess zu der gleichen Software gehören. Sprich wenn der Slave auch von diesem Master gestartet wurde. Nur dann hat der Masterprozess eine Möglichkeit zu kontollieren dass der anfragende Slave auch wirklich zu ihm gehört und auch von ihm gestartet wurde. Um in deinem Vorschlag zu bleiben: man hätte einen Apache unter einem eingeschränkten User und irgendeinen Master Daemon welcher unter root die Anfragen entgegen nimmt und mit seinen Rechten ausführt. Wie willst du im Master prüfen ob der Request wirklich vom legitimen Slave Prozess her kommt? Der Master wäre dann ja ein Syno-Eigengewächs und der Slave der Apache.
Ganz ehrlich, beide Arten sind nicht optimal in Bezug auf Sicherheit, aber das kleinere Übel ist imho definitiv wenn ein spezieller Webserver unter root läuft.

Deinen ersten Satz glaube ich gerne. Aber überlege doch noch mal, es geht hier mitnichten darum, Root loszuwerden. Ziel ist es, die Angriffsfläche auf die Diskstation zu minimieren, wobei der aktuelle Fokus mit der Konfigurationsoberfläche des DSM nur ein Aspekt von vielen ist.


Viele Grüße,
Süno42