debianforum.de

Guten Morgen zusammen,

ich habe gerade ein massives Sicherheitsproblem in freerdp entdeckt.

- man verbindet sich mit freerdp zu einem RDP Server - anschließend lockt man seine Session (win+L)
- jetzt zieht man das Netzwerkkabel
- sobald die Netzwerkverbindung unterbrochen wurde, steckt man das Kabel wieder ein
- JETZT wird man wieder OHNE EINGABE des PASSWORT eingelockt

Das sollte dringend überprüft und angepasst werden!

joe2017 hat geschrieben:

28.08.2023 08:54:23

ich habe gerade ein massives Sicherheitsproblem in freerdp entdeckt.

Dann schreibe einen Bugreport mit reportbug. Das Forum hier ist die falsche Anlaufstelle.

Danke für die Info.
Entweder bin ich blind, oder ich sehe den Punkt nicht wo ich auf der Seite einen Bug melden kann.

Du musst das Paket "reportbug" auf Deinem Debiansystem installieren und dann ausführen. Der Rest ist interaktiv.

Ich würde aber empfehlen, dass Du erst prüfst, ob hierfür bereits ein offener Bug gemeldet wurde...

joe2017 hat geschrieben:

28.08.2023 08:54:23

- JETZT wird man wieder OHNE EINGABE des PASSWORT eingelockt

Wo wirst Du eingeloggt, in die RDP Session?

Win+L lockt hier bei mir die lokale Arbeitsstation, nicht die RDP-Session? Ein Abziehen und anstecken des Netzwerkkabels ändert daran natürlich nichts ... hier kommt es aus sicht des rdp-Clients lediglich zu ein paar Paketverlusten, die aber nicht zum sperren der RDP-Sitzung führen. Dennoch muss ich mich am lokalen Rechner wieder anmelden.

Edit: wenn ich die RDP-Sitzung sperre, kann ich das nachstellen, der Reconnect meldet sich wohl mit dem übergebenen Kennwort neu an ...

Ist das nicht Sinn und Zweck der Option auto-reconnect?

/auto-reconnect
automatically reconnect on failure (also works over SSH tunnel)

Kann ich nicht nachstellen (xfreerdp 2.10.0). Ich habe aber das Passwort auch nicht auf der CLI als Option mitgegeben ...
Wenn ich den Remote Host sperre (windows Server 2022), dann komme ich nach dem simulierten Netzwerk-Ausfall auch wieder genau auf diesen Sperrbildschirm.

Allerdings: Wenn ich die verbindung bei aktivem Sperrbildschirm schließe und neu aufbaue, komme ich in eine Session ohne Sperrbildschirm. Das scheint mir aber eher ein Feature als ein Bug zu sein - denn immerhin hat man das Passwort ja selber angegeben.
Evt ist das so gebaut, dass wenn du das Kennwort auf der CLI als Option mitgibst, es bei einem re-connect automatisch verwendet wird.

rjh hat geschrieben:

28.08.2023 17:58:40

Ist das nicht Sinn und Zweck der Option auto-reconnect?

/auto-reconnect
automatically reconnect on failure (also works over SSH tunnel)

Nein, dass ist nicht Sinn und Zweck des ganzen. Der reconnect sollte lediglich die Verbindung bei einem Netzwerkverlust neu aufbauen. Eine erneute Anmeldung muss normalerweise nicht erfolgen, da man bei einer normalen Netzwerkunterbrechung nicht gelockt wird.

Wenn ich jedoch meine Session bewusst LOCKE und meinen Arbeitsplatz verlasse (z.B. als Geschäftsleitung), möchte ich nicht, dass durch diesen Bug jemand Zugriff auf meinen Account und meine Daten bekommt.
Das ist ein massives Sicherheitsproblem und keine Kleinigkeit!

joe2017 hat geschrieben:

30.08.2023 14:25:33

Das ist ein massives Sicherheitsproblem und keine Kleinigkeit!

Wie verhält sich remmina was ja auch auf freerdp aufbaut?

Sprechen wir eigentlich von freerdp2-wayland oder freerdp2-x11 ?

slu hat geschrieben:

30.08.2023 15:06:19

joe2017 hat geschrieben:

30.08.2023 14:25:33

Das ist ein massives Sicherheitsproblem und keine Kleinigkeit!

Wie verhält sich remmina was ja auch auf freerdp aufbaut?

Sprechen wir eigentlich von freerdp2-wayland oder freerdp2-x11 ?

remmina habe ich noch nicht getestet. Wir haben aktuell freerdp2-x11 in Verwendung.

joe2017 hat geschrieben:

30.08.2023 14:25:33

Wenn ich jedoch meine Session bewusst LOCKE und meinen Arbeitsplatz verlasse (z.B. als Geschäftsleitung), möchte ich nicht, dass durch diesen Bug jemand Zugriff auf meinen Account und meine Daten bekommt.
Das ist ein massives Sicherheitsproblem und keine Kleinigkeit!

Naja Moment. So wie ich das sehe geht das nur wenn du das Passwort als Option mitgibst. Oder wirst du beim reconnect auch eingeloggt wenn du das Passwort interaktiv eingibst? Das ist bei mir nämlich nicht der Fall.
Für den Fall, dass du das Passwort als Option mitgegeben hast, hast du es sowieso "veröffentlicht" und die Sicherheit weggeworfen.
So wie ich das verstehe sagst du mit dieser Angabe dem Programm "bei einem reconnect gib das Passwort auch gleich ein".

Übrigens haben die eine Mailingliste: https://sourceforge.net/projects/freerd ... erdp-devel ich würd das einfach mal dort fragen.

Siehe auch hier: https://github.com/FreeRDP/FreeRDP/secu ... nerability

rjh hat geschrieben:

01.09.2023 08:03:23

Siehe auch hier: https://github.com/FreeRDP/FreeRDP/secu ... nerability

Ich denke nicht, dass es eine Sicherheitslücke ist.
Es wäre eine, wenn ohne ein Passwort anzugeben der Lock weg wäre - aber nachdem man ganz wissentlich das Passwort angibt und auch als Argument übergibt, ist es mMn ein Feature - wenn auch vllt ein nicht gut dokumentiertes.
Ich glaube nicht, dass man das in einem privaten Advisory schreiben braucht.

reox hat geschrieben:

01.09.2023 09:05:18

rjh hat geschrieben:

01.09.2023 08:03:23

Siehe auch hier: https://github.com/FreeRDP/FreeRDP/secu ... nerability

Ich denke nicht, dass es eine Sicherheitslücke ist.
Es wäre eine, wenn ohne ein Passwort anzugeben der Lock weg wäre - aber nachdem man ganz wissentlich das Passwort angibt und auch als Argument übergibt, ist es mMn ein Feature - wenn auch vllt ein nicht gut dokumentiertes.
Ich glaube nicht, dass man das in einem privaten Advisory schreiben braucht.

Das sehe ich bisher auch so, aber dem TE scheint es ein wichtiges Anliegen zu sein, deshalb kam von mir noch der Hinweis auf die "offiziellen" Meldewege.

Gut, der "offizielle Weg" ist ja hauptsächlich darauf ausgelegt die Sicherheitslücke eben genau nicht öffentlich zu diskutieren, bevor nicht ein patch da ist.
Selbst wenn es jetzt eine Lücke ist, wurde sie mit diesem Thread veröffentlicht, incl PoC.
Demnach kann man wohl auch einfach auf deren mailingliste fragen oder ein öffentliches github issue aufmachem.

Das Problem existiert ebenfalls in Windows mit mstsc.exe
Somit scheint das ein generelles Problem zu sein.

Das ist natürlich super unschön!

Interessant ist, dass mstsc keine option zum setzen des Passwortes hat - zumindest hab ich es in der msdn nicht gesehen. dH mstsc speichert das passwort nach der Eingabe ab und verwendet es bei einem reconnect wieder? Das macht freerdp ja offenbar nicht, sondern nur wenn man es auch per option angibt. Demnach würde sich freerdp sogar sicherer verhalten.
Ich würde die Frage mal direkt an die Entwickler adressieren. Ich glaube kaum, dass hier im Forum jemand die Antwort darauf kennt.

Ich habe bereits mit den Entwicklern gesprochen.
Die Antwort war, dass mstsc das selbe Verhalten zeigt und somit das Problem bei der RDP Verbindung zu Microsoft Betriebssystemen zu suchen wäre.