Introduction
GzTx is an Simple File Transfer Application. Additionally, the files are compressed on-the-fly using the GZip algorithm, thanks to Java's in-built library.
Background
The reader is assumed to have basic knowledge of Java and Socket Programming. It also involves stream shovelling which has been discussed in my previous article.
This program is a follow up of my last Java program Shove.
What is It?
It's a pseudo FTP program...
The only distinguishing "feature" is that all files are compressed using GZip algorithm during the transfer.
The files are compressed on-the-fly... Therefore no temporary files are created. The utility can work both as server and client...
Rules
- Server cannot issue any commands.
- Server can access only the working directory. (Files outside the directory cannot be downloaded.)
- Client connects to server and issues commands.
- Client can upload or download a file to/from the server.
How to Use gzTx?
//*Setup a Sever*
c:\>java -classpath . GzTx -p45
//gzTx Server at port 45
//*Client Download*
c:\>java -classpath . GzTx -h200.x.x.x -fhaha.txt -D
//(200.x.x.x = remote host) and (haha.txt = remote filename to download)
//-D tells client to download
//*Client Upload*
c:\>java -classpath . GzTx -h200.x.x.x -p45 -fhaha.txt -U
//(200.x.x.x = remote host),(45 = remote port) and (haha.txt = Local filename to upload)
//-U tells client to upload
Netcat Compatibility
Using Netcat to Download Files Off a GzTx Server
//*Server*
c:\>java -classpath . GzTx
//*Client*
nc x.x.x.x 90 < get.txt >temp.gz
gzip -d temp.gz
------------->8 get.txt 8<-----------------
haha.txt|D
------------->8 get.txt 8<-----------------
Note the carriage return after the first line... haha.txt is the remote filename... NetCat uploads are not possible without additional processing...
Technical Discussion
The Protocol
The protocol is pretty trivial. It's "< filename >|< character >\r\n" followed by raw compressed data...
< filename > is the filename that will be used to upload/download
< character > is 'D' or 'U'
Bugs
When I first wrote it, I found out GzTx is susceptible to "relative path addressing" (using "..\..\win.ini" as filename). A remote attacker can overwrite arbitrary files using such an exploit string. So I tried to filter the path out... Now, using the GzTx application, this problem is circumvented but as you've seen above ("Using Netcat....") I've made it possible for non-gzTx clients to interact with GzTx servers... So technically, one can still send a "..\..\winnt\win.ini|U\r\n" exploit string... Now, in this case, the GzTx server will filter out the path and assume only 'win.ini'. but I can see cases where you can still exploit this bug using other "path addressing" ways. To rectify it, I'll need to strengthen the protocol, but I will loose my netcat compatibility with it... :(
Todo
Currently, GzTx supports only ONE(1) file transfer per client session... Need to implement multiple file transfer procedures... gzTx server can support one at a time...
History
- Original draft : 2 March, 2008