Sicherheitsloch bei 2.6er Versionen

[lxo@…]

Ein angemeldeter Benutzer mit Zugriff auf Menüpunkt System kann Administrationsrechte erlangen und seine Rechte erweitern.
Somit ist es möglich fast jede Datei auf dem System zu lesen und zumindest im Webserver-Verzeichnis zu schreiben.
Dazu ist kein besonderes Hacker-Fachwissen nötig. Es reicht unter Verwendung geeigneter Befehle einen Drucker einzurichten und zu benutzen.
Man kann an die Zugangsdaten der Datenbank und anderer Daten kommen.

Betroffen sind alle Versionen von Lx-Office ab 2.6.0.
Bei der 2.4.3 sollte es eventuell auch gehen, konnte ich jetzt nicht testen.
Es ist auch die offizielle Lx-Office Demo betroffen!

Lösungsmöglichkeiten:

1.) Dem Web-User Schreibrechte entziehen (dürfte zu Problemen führen)

2.) Nur die Auslieferung bestimmter Datei-Typen durch den Webserver zulassen.

(auch nicht sooo sicher)

3.) Den String für den Druckbefehl checken und nur Strings zulassen,

die Sinn machen und sicher sind.

4.) Zusätzliche "ACCESS=config_printer" und "ACCESS=batch_printing" Rechte

einführen, die es erlauben bestimmten Usern das Konfigurieren (Erfassen)
von Druckern bzw. das Benutzen des Menüpunktes "Druck" zu erlauben.

Mir erscheinen die Punkte 3 und 4 am besten geeignet.
Den 4. kann ich implementieren. Um den 3. muss sich jemand kümmern, der auf die Schnelle weiß, wie man das am besten realisiert.

Als Workaround für Produktionssysteme schlage ich vor in menu.ini die
Drucker-Menüpunkte auszukommentieren:

#[System--Printer]
#module=menu.pl
#action=acc_menu
#target=acc_menu
#submenu=1

#[System--Printer--Add Printer]
#module=am.pl
#action=add_printer

#[System--Printer--List Printer]
#module=am.pl
#action=list_printer

Alle Lx-Office-Versionen sind hiervon betroffen. In der Demo habe ich jetzt schlicht den Code im Backend sowie die Menüpunkte auskommentiert.

1.) Dem Web-User Schreibrechte entziehen (dürfte zu Problemen führen)

Ist keine Lösung. Man kann trotzdem z.B. "cat /etc/passwd" als Drucker einrichten und erhält sensitive Informationen über das System.

2.) Nur die Auslieferung bestimmter Datei-Typen durch den Webserver zulassen.
(auch nicht sooo sicher)

Auch keine Lösung, siehe 1.

3.) Den String für den Druckbefehl checken und nur Strings zulassen,
die Sinn machen und sicher sind.

Solch eine Lösung hat immer das Problem, dass sie sehr schwer fehlerfrei zu implementieren ist. Außerdem geht dabei dann die Flexibilität (siehe unten) verloren.

4.) Zusätzliche "ACCESS=config_printer" und "ACCESS=batch_printing" Rechte
einführen, die es erlauben bestimmten Usern das Konfigurieren (Erfassen)
von Druckern bzw. das Benutzen des Menüpunktes "Druck" zu erlauben.

Würde das Problem nur verkleinern, aber die Ursache nicht beheben.

Als Workaround für Produktionssysteme schlage ich vor in menu.ini die
Drucker-Menüpunkte auszukommentieren:

Hilft nicht, man kann solche Aktionen weiterhin aufrufen, wenn man schlicht die URL verwendet, die vom entsprechenden Menüpunkt generiert würde.

Die Sache ist ja, dass Lx-Office durch die Wahl beliebiger Befehle als Drucker sehr flexibel ist. Man kann eben nicht nur Drucker einbinden, sondern z.B. auch eigene Archivierungssysteme, Faxversand, was weiß ich was. Will man das beibehalten, so kommt man nicht darum herum, weiterhin beliebige Befehle zuzulassen.

Alternativ könnte man implementieren, dass Lx-Office ausschließlich drucken kann. Dann kann man die freie Befehlswahl durch eine brauchbare Schnittstelle zu CUPS ersetzen (Lx-Office fragt bei CUPS die vorhandenen Drucker an und gibt dem Benutzer nur die Möglichkeit, einen davon auszuwählen, eventuell mit Zusatzoptionen/einem Konfigurationsdialog wie bei Desktopanwendungen). Sehr viel Arbeit, und die oben genannte Flexibilität geht flöten.

Auch aufgrund bestehender Installationen, bei denen die Flexibilität bereits genutzt wird, würde ich eher zu 4. tendieren und zusätzlich geeignete Warnhinweise (in den Masken selber, in der Administration in der Rechteverwaltung, in der Dokumentation) einbauen.

Weitere Meinungen?

Normalerweise würde ich sagen, dass das Anlegen von Druckern dem Administrator vorbehalten sein sollte.

Ich gehe grundsätzlich davon aus, dass ein Administrator einer Webanwendung eh Zugriff auf die Kiste hat, und deshalb eh mindestens alles darf, was der web-user auch darf. Dass ein User das nicht dürfen sollte ist verständlich und sinnvoll.

Ich würde vorschlagen:

• Drucker anlegen in die Adminmaske, und sauber auf Adminzugriff prüfen
• Ne dicke rote Warnung dadrüber, ein "rm -rf /" nicht sinnvoll als Printercommand ist.
• Sauberes Escapen von allen Daten die an den Drucker übergeben werden (wobei das glaube ich eh nur Dateien sind).

(In reply to comment #2)

Normalerweise würde ich sagen, dass das Anlegen von Druckern dem Administrator
vorbehalten sein sollte.

Würde ich auch. Oder zumindest entsprechend vertrauenswürdigen Mitarbeitern.

Ich würde vorschlagen:

• Drucker anlegen in die Adminmaske, und sauber auf Adminzugriff prüfen

Das finde ich als "long term solution" gut.

1.) Als Sofortlösung, und um bestehende Installationen zu schützen, vote ich für zusätzliche ACCESS-Rechte, die per default _nicht_ gewährt werden.
Als ersten Schritt würde ich die Menüpunkte und den Code von "System->Drucker", "System->Drucker->Drucker hinzufügen" und "System->Drucker->Drucker anzeigen" in Abhängigkeit von "ACCESS=config_printer" blockieren.
Da ganze als Patch für die 2.6.1 und "ab Werk" in der 2.6.2-unstable.

2.) Als nächster Schritt könnte "ACCESS=batch_printing" folgen, welches den Menüpunkt "Druck" ein-/ausblendet. Zusätzlich müssten, der Logik wegen, in allen Frontends nur noch die Bildschirm-Druck Optionen verfügbar sein.
Das ist nützlich für Systeme, die sowieso ausschließlich HTML, PDF oder ODF ausliefern und es ist etwas aufwändiger.

3.) Die Anregung von Moritz, die feste Anbindung an CUPS betreffend, finde ich auch sehr gut. Damit sollte sich fast alles abdecken lassen, was mit Drucken zu tun hat. Oder?
Das wäre dann eine "extra long term solution". :-)

Ich finde eine starre Anbindung an CUPS im Gegenteil eher schlecht, weil sie die Flexbilität nimmt -- oder gewisse Mechanismen (Dokumentenarchiv, Faxversand) erheblich verkompliziert. Eine CUPS-Anbindung hat weiterhin den Nachteil, dass nicht jedes System, auf dem Lx-Office momentan läuft, auch wirklich CUPS zum Drucken verwendet (Windows z.B. nicht, die BSDs eventuell auch nicht). Alles nicht schön.

Normalerweise würde ich sagen, dass das Anlegen von Druckern dem Administrator
vorbehalten sein sollte.

Würde ich auch. Oder zumindest entsprechend vertrauenswürdigen Mitarbeitern.

Ich würde vorschlagen:

• Drucker anlegen in die Adminmaske, und sauber auf Adminzugriff prüfen

Das finde ich als "long term solution" gut.

1.) Als Sofortlösung, und um bestehende Installationen zu schützen, vote ich
für zusätzliche ACCESS-Rechte, die per default _nicht_ gewährt werden.
Als ersten Schritt würde ich die Menüpunkte und den Code von "System->Drucker",
"System->Drucker->Drucker hinzufügen" und "System->Drucker->Drucker anzeigen"
in Abhängigkeit von "ACCESS=config_printer" blockieren.
Da ganze als Patch für die 2.6.1 und "ab Werk" in der 2.6.2-unstable.

2.) Als nächster Schritt könnte "ACCESS=batch_printing" folgen, welches den
Menüpunkt "Druck" ein-/ausblendet. Zusätzlich müssten, der Logik wegen, in
allen Frontends nur noch die Bildschirm-Druck Optionen verfügbar sein.
Das ist nützlich für Systeme, die sowieso ausschließlich HTML, PDF oder ODF
ausliefern und es ist etwas aufwändiger.

3.) Die Anregung von Moritz, die feste Anbindung an CUPS betreffend, finde ich
auch sehr gut. Damit sollte sich fast alles abdecken lassen, was mit Drucken zu
tun hat. Oder?
Das wäre dann eine "extra long term solution". :-)

Den Begriff "long törm soljuschon" mal beiseite. Ich werde das mal so umbauen, dass folgende Dinge passieren:

1. Drucker sind nicht mehr im normalen Userbereich anlegbar. Auflisten ja, anlegen nein.
2. Drucker anlegen wird verlagert in die admin Maske, und kann da nur noch vom Administrator gemacht werden.
3. Dazu ein paar Warnungen was fehlerhafte Drucker anrichten können.

4. Das checke ich dann in die derzeitig unstable ein.

5. Ich rebase den ganzen Commit auf die 2.6.1 stable, und baue ein tar.gz, dass die geänderten Dateien austauscht. Das können dann sicherheitsbewusste Admins einspielen.

(In reply to comment #4)

Ich finde eine starre Anbindung an CUPS im Gegenteil eher schlecht, weil sie
die Flexbilität nimmt -- oder gewisse Mechanismen (Dokumentenarchiv,
Faxversand) erheblich verkompliziert.

Wird die Sache dadurch nicht einfacher? Ich habe CUPS nicht studiert, aber soweit ich den kenne und verwende erlaubt er z.B. das Drucken

• in PDF-Dateien
• auf Netzwerkdrucker
• auf USB-Drucker
• auf Parallel-Portdrucker
• auf im Windows-Netzwerk freigegebene Drucker
• auf andere CUPS-Server

Es stehen massenhaft Druckertreiber und ppd-Files zur Verfügung. Da ist für jeden Drucker was dabei.
CUPS ist bei vielen Desktop-Linux-Distributionen Standard. Wer also sein Lx-Office lokal auf der Desktop-Maschine hat, hat CUPS meist standardmäßig dabei.
Mac OS verwendet den glaube ich auch als Printserver.

Eine CUPS-Anbindung hat weiterhin den
Nachteil, dass nicht jedes System, auf dem Lx-Office momentan läuft, auch
wirklich CUPS zum Drucken verwendet (Windows z.B. nicht, die BSDs eventuell
auch nicht). Alles nicht schön.

Windows kann auf IPP-Druckern drucken, die CUPS über das Netzwerk bereitstellt.

Man könnte ja zweigleisig fahren. Die CUPS-Anbindung für die Anwender und parallel für Admins die Möglichkeit frei Befehle verwenden zu können wie bisher.
Allerdings habe ich wirklich richtige Bauchschmerzen mit der aktuellen Lösung, solange fast jeder damit Code einschleusen kann.

(In reply to comment #5)

Den Begriff "long törm soljuschon" mal beiseite. Ich werde das mal so umbauen,
dass folgende Dinge passieren:

1. Drucker sind nicht mehr im normalen Userbereich anlegbar. Auflisten ja,

anlegen nein.

Okay.

2. Drucker anlegen wird verlagert in die admin Maske, und kann da nur noch vom

Administrator gemacht werden.

Okay.

3. Dazu ein paar Warnungen was fehlerhafte Drucker anrichten können.

Naja, nicht, dass dann einer, der das Admin-Passwort herausgefunden hat, das als Einladung sieht. Ich kenne Leute, welche zum Beispiel "erdbeere" als Passwort für den Admin nehmen! :-D

4. Das checke ich dann in die derzeitig unstable ein.

Prima.

5. Ich rebase den ganzen Commit auf die 2.6.1 stable, und baue ein tar.gz, dass

die geänderten Dateien austauscht. Das können dann sicherheitsbewusste Admins
einspielen.

Wunderbar. :-)

Naja, nicht, dass dann einer, der das Admin-Passwort herausgefunden hat, das
als Einladung sieht. Ich kenne Leute, welche zum Beispiel "erdbeere" als
Passwort für den Admin nehmen! :-D

Dictionary Protection... schreibs auf die große Liste...

Patch ist drin als a3f90d6fa23d0a8d026682511e7624bd847d532f. Testet das mal bitte, während ich den 2.6.1 Patch vorbereite.

Der Aufruf aus der Adminmaske führt zu folgendem Fehler:

Can't locate object method "get_user_dbh" via package "SL::Auth" at SL/Printer.pm line 10.

fcgi version und Server nicht neu gestartet?

fcgi version und Server nicht neu gestartet?

ok, ok. tut

Patch für die 2.6.1 stable

Patch für die 2.6.1 stable (release-2.6.1 - baf072736bc20b4d4da2261aeb5c66741f168d22).

Lässt sich in Lx-Office Verzeichnis einspielen mit git:

git am /path/to/0001-Maint-Version-des-Printer-Patches.patch

und ohne git:

patch -p1 < /path/to/0001-Maint-Version-des-Printer-Patches.patch

Ein entpackbares tar.gz kommt nachher noch.

Und der Patch als tar.gz

Patch für 2.6.1 stable als tar.gz Einfach ins Lx-Office Verzeichnis packen und dort entpacken mit:

tar xzf printer_patch,tar.gz

(In reply to comment #8)

... Ich kenne Leute, welche zum Beispiel "erdbeere" als
Passwort für den Admin nehmen! :-D

Dictionary Protection... schreibs auf die große Liste...

Als Sofortlösung könnte man eine Wartezeit einbauen, wenn jemand ein
falsches Admin-Passwort eingegeben hat, bis die Fehlermeldung erscheint und
ein weiterer Versuch gestartet werden kann. Sperren nach drei mal falsch
wäre zu viel des Guten. Oder?

Patch ist drin als a3f90d6fa23d0a8d026682511e7624bd847d532f. Testet das mal

Ich freue mich und danke Dir und Moritz im Namen der Lx-Office Community für die sehr schnelle Reaktion und Umsetzung! :-)

Das fiel mir beim Testen auf:

Nach Klick auf "Druckeradministration" in der
Maske "Lx-Office ERP Administration" erschient diese:

--------

|Drucker |

--------

------

Bitte wählen Sie einen Benutzer aus: | demo |

------

Aus Anwendersicht hat die Benutzerauswahl hier keinen Sinn bzw. es scheint sich nichts zu ändern, wenn man da etwas auswählt.

Alles in Allem funktioniert die Druckerverwaltung, aber es wirkt irgendwie inkonsistent und verwirrend.
Frag mich nicht warum. Vielleicht komme ich noch dahinter.

Eigentlich müsste doch diese zuerst kommen:

-----------------------

| Druckeradministration |

-----------------------

Drucker werden für eine Benutzerdatenbank erzeugt. Bitte wählen Sie einen
Benutzer aus. Die Drucker werden in der verknüpften Datenbank angelegt.

------

Bitte wählen Sie einen Benutzer aus: | demo |

------

-------- --------

| Weiter | | Zurück |

-------- --------

Das Vorhandensein von Zurück-Buttons gefällt mir sehr.

Am Tabellen-Design habe ich was zu meckern: ;-)

Spalte Beschreibung: linksbündig
Spalte Druckbefehl: rechtsbündig
Spalte Vorlagenkürzel: linksbündig

Alle linksbündig wäre schöner. :-)

(In reply to comment #14)

Das fiel mir beim Testen auf:

Nach Klick auf "Druckeradministration" in der
Maske "Lx-Office ERP Administration" erschient diese:

--------

|Drucker |

--------

------

Bitte wählen Sie einen Benutzer aus: | demo |

------

Aus Anwendersicht hat die Benutzerauswahl hier keinen Sinn bzw. es scheint sich
nichts zu ändern, wenn man da etwas auswählt.

Technisch notwendig weil die Drucker in den einzelnen User Datenbanken gespeichert werden, und Lx-Office durchaus mit mehr als einer aktiven Datenbank umgehen kann (und auch einige Nutzer das so praktizieren).

Dass der Anwender in seiner beschränkten Sicht diesen Sinn nicht erkennt ist nicht mein Problem. Es ändert sich sehr wohl etwas. Allerdings habe ich den Versuch das in einen Satz zu pressen der nicht nach Passierschein A38 klingt aufgegeben.

Eigentlich müsste doch diese zuerst kommen:

[snip]

Die sollte auch zuerst kommen, sofern die Abfrage nach dem login noch nicht passiert ist. Wenn Du noch eine aktive Session hast, wird das aus der voraktiviert, da kann ich zu dem Zeitpunkt nicht viel dran machen.

Das Vorhandensein von Zurück-Buttons gefällt mir sehr.

Am Tabellen-Design habe ich was zu meckern: ;-)

Spalte Beschreibung: linksbündig
Spalte Druckbefehl: rechtsbündig
Spalte Vorlagenkürzel: linksbündig

Alle linksbündig wäre schöner. :-)

Fix es. templates/webpages/admin_printer/* sind die templates. :)

(In reply to comment #15)

Dass der Anwender in seiner beschränkten Sicht diesen Sinn nicht erkennt ist
nicht mein Problem. Es ändert sich sehr wohl etwas. Allerdings habe ich den
Versuch das in einen Satz zu pressen der nicht nach Passierschein A38 klingt
aufgegeben.

Beim durchlesen ist mir aufgefallen, dass das deutlich härter klingt als es gedacht war.

Was ich meinte war: Ich habe versucht das einigermaßen klarzustellen, in dem Text, den Du nicht zu Gesicht bekommen hast, weil Du schon eine aktive Session hattest. Evtl. sollte der Text später auch noch eingebaut werden und nochmal anders formuliert werden.

(In reply to comment #16)

Jetzt sind eben unsere Replys kollidiert. :-O

(In reply to comment #15)

(In reply to comment #14)

Aus Anwendersicht hat die Benutzerauswahl hier keinen Sinn bzw. es scheint sich
nichts zu ändern, wenn man da etwas auswählt.

Technisch notwendig weil die Drucker in den einzelnen User Datenbanken
gespeichert werden, und Lx-Office durchaus mit mehr als einer aktiven Datenbank
umgehen kann (und auch einige Nutzer das so praktizieren).

Das ist mir klar. Aber an _der_ Stelle werden die Drucker _aufgelistet_ und man
kann dann "Erfassen" oder "Zurück" wählen.
Wenn ich "Erfassen" wähle bekomme ich die User-Auswahl wieder präsentiert, wo
es dann auch einen Sinn hat.

Ich würde es ja noch verstehen, wenn ein JavaScript?-Schnipsel die Tabelle in
der List-Ansicht reloaden würde.
Dann würden die Drucker aufgelistet, die zu der Datenbank des nun ausgewählten
Benutzers gehören.
Oder denke ich in die falsche Richtung?

Dass der Anwender in seiner beschränkten Sicht diesen Sinn nicht erkennt ist
nicht mein Problem. Es ändert sich sehr wohl etwas.

Na, na, na! Nicht den Anwender beleidigen! ;-)

Allerdings habe ich den
Versuch das in einen Satz zu pressen der nicht nach Passierschein A38 klingt
aufgegeben.

Ich kann mich ja noch mit der Neuvertextung beschäftigen. :-)

Alle linksbündig wäre schöner. :-)

Fix es. templates/webpages/admin_printer/* sind die templates. :)

Habe ich gemacht. :-)

8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< (snip)

Ein Seiteneffekt ist nun aufgetreten (in untable).

Wenn man auf "Programm-Einstellungen" klick sieht man diese
Fehlermeldung:

'Can't locate object method "all_printers" via package "SL::Printer" (perhaps
you forgot to load "SL::Printer"?) at bin/mozilla/am.pl line 2498.'

Ich versuche das gerade zu fixen.

(In reply to comment #17)

Ein Seiteneffekt ist nun aufgetreten (in untable).

Wenn man auf "Programm-Einstellungen" klick sieht man diese
Fehlermeldung:

'Can't locate object method "all_printers" via package "SL::Printer" (perhaps
you forgot to load "SL::Printer"?) at bin/mozilla/am.pl line 2498.'

Ich versuche das gerade zu fixen.

gnampf. Und ich habs sogar noch getestet an der Stelle, dummes Caching. Der Fix steht mehr oder minder direkt in der Fehlermeldung. -.-

(In reply to comment #18)

(In reply to comment #17)

Ein Seiteneffekt ist nun aufgetreten (in untable).

Wenn man auf "Programm-Einstellungen" klick sieht man diese
Fehlermeldung:

'Can't locate object method "all_printers" via package "SL::Printer" (perhaps
you forgot to load "SL::Printer"?) at bin/mozilla/am.pl line 2498.'

Ich versuche das gerade zu fixen.

gnampf. Und ich habs sogar noch getestet an der Stelle, dummes Caching. Der Fix
steht mehr oder minder direkt in der Fehlermeldung. -.-

Das war ja einfach! :-)
Jetzt geht es.

Im Rahmen unseres Zeitbudgets sehe ich das Problem als behoben an.