Hi x2go users/developers,
QStringList lst=string.split ( '|' );
x2goSession s;
s.agentPid=lst[0];
s.sessionId=lst[1];
s.display=lst[2];
s.server=lst[3];
s.status=lst[4];
s.crTime=lst[5];
s.cookie=lst[6];
s.clientIp=lst[7];
s.grPort=lst[8];
s.sndPort=lst[9];
If a line from the server, does not enough "|" we end up with out-of-bound array access. The source is full with such issues.
Finally I've also looked at the server. In short, the 90's called, they want their setuid bugs back. x2gosqlitewrapper.c just wrong, anyone can make it executing whatever binary he wants with higher privileges.
But it's not only the code that worries me. On Windows the client executes per default sshd and x11. Both are listening on all available IP-Addresses. You silently install a user "sshuser" on Windows, which has the password of the currently logged in Windows user and give him a login shell.
I haven't seen such a trainwreck of software for a long time. By installing it on my system you've successfully backdoor'ed my clients and the server.
Thanks, //richard
Hi, Richard.
You're right. But it looks like there is sad MS-style truth here: 1) a lot of usecases use assumption about trusted intranet environment 2) nobody pays for minor optimization and bugfixes and most parts of functionality were written by main developers as a part of their work (and they have very little amount of spare time to make clean-up then). Community helps somehow to clean the code but this community is still not enough large to test everything enough. After all, criticism and bug reports are important things but patches are what really matters. It's do-ocrasy, isn't it?
Hi all,
On Sa 18 Mai 2013 21:48:30 CEST Richard Weinberger wrote:
while reviewing x2go I've encountered issues which scared hell out of me. The client seems to perform zero input validation. A rough server
can easily crash the client and most likely execute arbitrary code. For example x2goSession ONMainWindow::getSessionFromString ( const
QString& string ), it is feed with input from the server.QStringList lst=string.split ( '|' ); x2goSession s; s.agentPid=lst[0]; s.sessionId=lst[1]; s.display=lst[2]; s.server=lst[3]; s.status=lst[4]; s.crTime=lst[5]; s.cookie=lst[6]; s.clientIp=lst[7]; s.grPort=lst[8]; s.sndPort=lst[9];
If a line from the server, does not enough "|" we end up with
out-of-bound array access. The source is full with such issues.
Can you please file a bug against X2Go Client, so that we do not loose
this on the list. Those issues have to fixed. Please mark them as grave:
To: submit@bugs.x2go.org Subject: <a-good-one> """ Package: x2goclient Version: 4.0.1.0 Severity: grave
<your-bug-description> """
Finally I've also looked at the server. In short, the 90's called, they want their setuid bugs back. x2gosqlitewrapper.c just wrong, anyone can make it executing
whatever binary he wants with higher privileges.
This one Richard and I have fixed during last night. The issues were
present in X2Go Server and the broker agent in X2Go Session Broker.
Please upgrade X2Go Server ( -> 4.0.0.2) and X2Go Session Broker ( ->
0.0.2.1). This is highly recommended!!!
But it's not only the code that worries me. On Windows the client executes per default sshd and x11. Both are
listening on all available IP-Addresses. You silently install a user "sshuser" on Windows, which has the
password of the currently logged in Windows user and give him a login shell.
Huuhhhh...
@Alex: this sounds wrong to me... isn't it possible to launch an SSH
daemon under the user's ID that is currently logged on (on some non-22
port)???
I haven't seen such a trainwreck of software for a long time. By installing it on my system you've successfully backdoor'ed my
clients and the server.
Let's continue working together to remove those trainwreck bits and
pieces and the X2Go possibly becomes suitable for you.
Improving X2Go... Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
This commits breaks session popping up on the client here in ArchLinux. Reverting it in 4.0.0.2 makes it working again.
http://code.x2go.org/gitweb?p=x2goserver.git;a=patch;h=011d14ae076ba6fec96cd...
We install the script to /usr/lib/x2go/x2gosqlitewrapper.pl. Something seems wrong here. Any idea? Anything from the logs I could provide?
-Andy ArchLinux
Am 20.05.2013 20:03, schrieb Andreas Radke:
This commits breaks session popping up on the client here in ArchLinux. Reverting it in 4.0.0.2 makes it working again.
http://code.x2go.org/gitweb?p=x2goserver.git;a=patch;h=011d14ae076ba6fec96cd...
We install the script to /usr/lib/x2go/x2gosqlitewrapper.pl. Something seems wrong here. Any idea? Anything from the logs I could provide?
I've reported the issue already to Mike. Looks like the build system is broken and $PREFIX is not honored.
Thanks, //richard
Hi Andreas, hi Jan
On Mo 20 Mai 2013 20:03:36 CEST Andreas Radke wrote:
This commits breaks session popping up on the client here in ArchLinux. Reverting it in 4.0.0.2 makes it working again.
http://code.x2go.org/gitweb?p=x2goserver.git;a=patch;h=011d14ae076ba6fec96cd...
We install the script to /usr/lib/x2go/x2gosqlitewrapper.pl. Something seems wrong here. Any idea? Anything from the logs I could provide?
I confirm this issue partly. I have to explicitly set PREFIX=/usr when
running the (Debian package) build logic (see /debian/rules for
details). Then the now-macro-coded path in
/usr/lib/x2go/x2gosqlitewrapper gets set correctly.
Can you check if that helps?
@Jan: probably this also affects the RPM based packaging...
Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hello Richard,
Am 18.05.2013 21:48, schrieb Richard Weinberger:
Hi x2go users/developers,
while reviewing x2go I've encountered issues which scared hell out of me. The client seems to perform zero input validation. A rough server can easily crash the client and most likely execute arbitrary code. For example x2goSession ONMainWindow::getSessionFromString ( const QString& string ), it is feed with input from the server.
QStringList lst=string.split ( '|' ); x2goSession s; s.agentPid=lst[0]; s.sessionId=lst[1]; s.display=lst[2]; s.server=lst[3]; s.status=lst[4]; s.crTime=lst[5]; s.cookie=lst[6]; s.clientIp=lst[7]; s.grPort=lst[8]; s.sndPort=lst[9];
If a line from the server, does not enough "|" we end up with out-of-bound array access. The source is full with such issues.
You are right, it is possible, that X2Go Client can be crashed with the wrong output from the server. This issue could (and should) be easily fixed by replacing operator "[n]" with method "value(n)". However, I don't think, that this issue is so dramatic as you described it. Why some one should open a SSH/X2GO connection to "rough" server? I didn't see such use case yet, when an administrator of server want to crash the client application on a machine of his user. If a user root on your Linux system is not an evil person, who want crash the X2Go Client on your desktop, you should not worry about this issue. But if you living in the world of BOFH, please don't use the X2Go Client until this issue will be fixed. I'll fix it very soon.
Finally I've also looked at the server. In short, the 90's called, they want their setuid bugs back. x2gosqlitewrapper.c just wrong, anyone can make it executing whatever binary he wants with higher privileges.
Sorry, I don't understand what are you talking about. I not found the file "x2gosqlitewrapper.c" in the source tree of package "x2go server". If you found a security problem in the recent x2goserver code, please open a bug report on bug tracker, describe the problem and show how it can be used. In best case show an example of exploit and send a bug fix. Saying "it is just wrong, anyone can do something" is just your opinion without any arguments.
But it's not only the code that worries me. On Windows the client executes per default sshd and x11. Both are listening on all available IP-Addresses.
Yes, this components are required by X2Go Client. This services are configured by default to listen all IP-Adresses. It is possible to configure them to listen for connections only on localhost, but I see it just as "nice to have" feature. Starting this services is not creating backdoor on the system, otherwise most UNIX machines would be backdoor'ed, because they running same services. Furthermore, SSHD used by X2Go is running only with user privileges and opening an access for only one user and only shortly for each SSHFS connection. The rest time SSHD don't accept a SSH-connections. In addition, each Windows system have a firewall that by default configured to drop incoming TCP-connections. This make SSHD and X11 to be only accessible from localhost.
You silently install a user "sshuser" on Windows, which has the password of the currently logged in Windows user and give him a login shell.
This is so untrue! X2Go Client can not install users on Windows system. To be able to do something like that, X2Go Client must have an administrator privileges. All X2Go Client components running with user privileges. A SSHD open SSH access for current user and this is required for SSHFS, which used to export client directories to server. If you don't trust your server, just don't export your directories. And you should not do this, independent what kind of network FS are you using. It is always possible, that untrusted server can manipulate your data or credentials. It's impossible to open a SSH-Connection to your client until you don't exporting directories to server.
I haven't seen such a trainwreck of software for a long time. By installing it on my system you've successfully backdoor'ed my clients and the server.
I appreciated your criticism, but writing something like that in the ML of a community project is just not respecting the work of people, who spent a lot of their time and costs to develop something useful for others.
Alex
Thanks, //richard
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Hi Richard,
On Di 21 Mai 2013 10:40:45 CEST Oleksandr Shneyder wrote:
Finally I've also looked at the server. In short, the 90's called, they want their setuid bugs back. x2gosqlitewrapper.c just wrong, anyone can make it executing whatever binary he wants with higher privileges.
Sorry, I don't understand what are you talking about. I not found the file "x2gosqlitewrapper.c" in the source tree of package "x2go server". If you found a security problem in the recent x2goserver code, please open a bug report on bug tracker, describe the problem and show how it can be used. In best case show an example of exploit and send a bug fix. Saying "it is just wrong, anyone can do something" is just your opinion without any arguments.
In x2goserver.git master the file has been renamed to
libx2go-server-db-sqlite3-wrapper.c. On x2goserver.git branch
release/4.0.0.x the file is still named x2gosqlitewrapper.c.
[1]
http://code.x2go.org/gitweb?p=x2goserver.git;a=blob;f=libx2go-server-db-perl...
A similar setuid/setgid wrapper is in use with x2gobroker.git. The
wrapper came in as a replacement for the deprecated perlsuid (removed
in Perl 5.12 and above).
Both wrappers (in x2goserver.git and x2gobroker.git) were
compromisable and I fixed both issues [2, 3] over the weekend.
[2]
http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=42264c88d7885474...
[3]
http://code.x2go.org/gitweb?p=x2gobroker.git;a=commitdiff;h=65d635943bb2a858...
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Alex, hi Richard,
On Di 21 Mai 2013 10:40:45 CEST Oleksandr Shneyder wrote:
Finally I've also looked at the server. In short, the 90's called, they want their setuid bugs back. x2gosqlitewrapper.c just wrong, anyone can make it executing whatever binary he wants with higher privileges.
Sorry, I don't understand what are you talking about. I not found the file "x2gosqlitewrapper.c" in the source tree of package "x2go server". If you found a security problem in the recent x2goserver code, please open a bug report on bug tracker, describe the problem and show how it can be used. In best case show an example of exploit and send a bug fix. Saying "it is just wrong, anyone can do something" is just your opinion without any arguments.
In x2goserver.git master the file has been renamed to
libx2go-server-db-sqlite3-wrapper.c. On x2goserver.git branch
release/4.0.0.x the file is still named x2gosqlitewrapper.c.
[1]
http://code.x2go.org/gitweb?p=x2goserver.git;a=blob;f=libx2go-server-db-perl...
A similar setuid/setgid wrapper is in use with x2gobroker.git. The
wrapper came in as a replacement for the deprecated perlsuid (removed
in Perl 5.12 and above).
Both wrappers (in x2goserver.git and x2gobroker.git) were
compromisable and I fixed both issues [2, 3] over the weekend.
[2]
http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=42264c88d7885474...
[3]
http://code.x2go.org/gitweb?p=x2gobroker.git;a=commitdiff;h=65d635943bb2a858...
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Am 21.05.2013 10:40, schrieb Oleksandr Shneyder:
You are right, it is possible, that X2Go Client can be crashed with the wrong output from the server. This issue could (and should) be easily fixed by replacing operator "[n]" with method "value(n)". However, I don't think, that this issue is so dramatic as you described it. Why some one should open a SSH/X2GO connection to "rough" server?
Scenario: DNS server is under the control of an attacker. Requests for "myserver.foobar.com" are answered with the IP of the rogue server.
Obviously, in case of SSH, there should be a fingerprint mismatch warning if the key of myserver.foobar.com is already known, which in case of the X2Go client cannot be overridden by clicking it away. But if it is a first-time connection, there will be a pop-up asking whether the key fingerprint is correct. If the user doesn't pay attention there (and to be honest - which average user does?), it would be possible to connect to a rogue server without wanting to.
-Stefan
Hi Stefan,
I didn't say that is not an issue. I'll fix it as soon as possible (I think today). I only saying, that in most cases it is very hard or impossible to use it to hack the client.
regards, Alex
Am 21.05.2013 11:49, schrieb Stefan Baur:
Am 21.05.2013 10:40, schrieb Oleksandr Shneyder:
You are right, it is possible, that X2Go Client can be crashed with the wrong output from the server. This issue could (and should) be easily fixed by replacing operator "[n]" with method "value(n)". However, I don't think, that this issue is so dramatic as you described it. Why some one should open a SSH/X2GO connection to "rough" server?
Scenario: DNS server is under the control of an attacker. Requests for "myserver.foobar.com" are answered with the IP of the rogue server.
Obviously, in case of SSH, there should be a fingerprint mismatch warning if the key of myserver.foobar.com is already known, which in case of the X2Go client cannot be overridden by clicking it away. But if it is a first-time connection, there will be a pop-up asking whether the key fingerprint is correct. If the user doesn't pay attention there (and to be honest - which average user does?), it would be possible to connect to a rogue server without wanting to.
-Stefan
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Am 21.05.2013 12:24, schrieb Oleksandr Shneyder:
Hi Stefan,
I didn't say that is not an issue.
And I didn't understand your comment in that way. But since you wrote
I didn't see such use case yet, when an administrator of server want to crash the client application on a machine of his user.
I figured pointing out one possible scenario where $BADTHINGS may happen wouldn't be a bad idea. ;-)
-Stefan