Luigi Auriemma

Maybe it is possible to create and execute a remote PHP shell on a Quake 3 server (if a PHP-based site is hosted on the same server, of course)
How do I imagine that:

1) Connect to the server via rcon
2) Overwrite first cvar (it's com_maxfps in my cfg) with "/*"
3) Some variables are overwritten with "*/ <?php ... /*", so the shell code is written in 255 by 255 symbols and
4) Last of them goes "*/ ... ?>
5) Retrieve the path to a remote host using dir command
6) writeconfig path/to/shell.php (filename does not matter for q3 engine)
7) type hostname/shell.php in your address bar

The only issue I can spot is that I can't write my config to any dir except the current dir.

Any ideas how to resolve that? Am I wrong?

The shell code is easily written to a current folder with writeconfig command, and it's executable, the only problem is to place the file properly. But I can't write any file outside the current dir, neither I can change it.
Any ideas?

if you can't use writeconfig on parent folders (.. or directly /path) it's a matter of permissions that are not enough for the "user" under which runs the server.
so the user who runs the server can't write on the web folders.

anyway the hosters allow to upload mods and even chaning the game exe, isn't more easy to use this way instead the php one?

No, since I don't own the server but trying to perform a remote attack.

ah ok, so the idea is having system access from a rcon access (maybe gained with the directory traversal or cbuf bug).
I was thinking to use /tmp but then it's necessary that a php script on the server suffers of local file inclusion otherwise it's necessary to find a folder where the user who runs the quake process has access and its read by the webserver like could be ~/public_html (check Apache UserDir) or another user's directory (if used, like with the multi user hosting services)

The second method worked for me.
if there is a writeable dir on the server, it is possible to upload a PHP script via writeconfig and to gain control upon the whole machine.

A good hint for me was to look for other .cfg and .ini files in the game folder. I've found a path to a writeable dir in a .cfg for an extension which purpose was to parse the game's log files and write them to the folder for displaying online.I tested it on Jedi Academy, running JA+ v.2.3 mod and several other mods via QMM, but I think any other Quake3 engine-based game might be vulnerable.

So the conclusion is:

1) Steal the RCON
2) Write your PHP code into one or more variables
3) Find a writeable dir which is accessible from the web
4) writeconfig path/to/writeable_dir/shell.php
5) http://www.target.com/writeable_dir/shell.php

and that's it.

P.S.
Unfortunately, one of the largest JKA communities in Eastern Europe, which was the target of my experiment, exists no more because of remote shell execution, some dude who helped me with testing that and other(public) vulnerabilities, formatted their hard drives as soon as he gain access. I'm angry of it, and I suppose that everyone who hosts a q3-based game server and a PHP site on the same machine must be aware of this and check their folder permissions.

I have a question, after reading this I've checked the source code of the JA server (both windows and linux), and as far as i can tell there's no way you can change the directory just like that. First of all, paths containing '..' or '::' are refused, and secondly, the main directory of the server is prepended to the path specified, which would make paths like /tmp or ~/public_html useless, as they'll turn into something like /usr/jaserver//tmp or /usr/jaserver/~/public_html (assuming linux here).

So how exactly does this allow you to write to an entirely different directory? I'm assuming the host of that server was not stupid enough to place the server files in a directory accessible by a webserver.

I apologize for posting it without testing the bug in pure JKA server. It worked for me but it seems it might be not JA+ or Q3 vulnerability, but a particular case of the mod installed, but I'm not quite sure.

So
almost every directory on this server wasn't writeable, but I have read other .CFG in the japlus folder carefully, and found something like
set uag_dynamic_log "logs/main/", and that folder C:/logs/main was quite writeable.
Then I went to _www.target.com/logs/main/ and there I found dozens of parsed server log files in .html format, and then my config.php file.

To prove my words are worth something, I may give you the mod so you could have a test.

and what about the fs_homepath cvar?
doesn't it affect the default folder for reading/writing operations?
my memory doesn't help me to remember :)

They do affect the paths used, but the cvars are read-only.

in the Quake 3 engine the read-only flag applied to the cvars is enough "abstract".

when I tested it many years ago I was able to change any cvar on the client included the read-only ones through the bug I found (q3cfilevar) and I have seen that on the server they are not really read-only (CVAR_ROM) but set as CV_INIT so maybe it's possible to write the configuration with the needed cvars to change on a file (like the server.cfg file loaded by the server) and then force the restarting of the server.

CVAR_INIT says that the cvars can be changed only from the command-line but I guess it's valid also for the server.cfg file.

it's only an idea, I don't know much about this aspect of the engine.

Can you post plz an example config file with php code that prints out a text or something? I tested it on my root and got only errors when i execute some test php scripts. I dont know much about php so i maybe did something wrong. Writing in other directorys is not possible without changing the homepath i think. Your idea is realy cool but is it not easier to write an buffer overflow with a shellcode in the config file and then simply /execute shellcode.cfg ? Then you dont have the problem with the web directory and so on. Or maybe some other code that will be activated by the execute cmd or the touchfile cmd. I dont know if this is possible so when it is an crappy idea ignore it ^^

instead it's a good idea because you can exploit a format string vulnerability when you try to execute a command.
so it's enough that you type %s%s%s%s%s in the console or place it in a cfg to exploit it.

and there are for sure some buffer-overflow in some commands but this one was the first I found within 60 seconds :)