In order to facilitate members or members to upload movies or exchange files, many movie websites, forums or other institutions allow users to upload movies or exchange files, because only by allowing this permission can users upload files, but this permission can cause big problems in the ftp server that allows breakpoints to be transmitted again.
All ftp server programs that allow breakpoints to be transmitted must support a "Rest" command. If this command is used before uploading the command (send command), it tells the ftp server that the file I want to upload will start from where the file exists in the ftp server.
example:
Suppose there is a file in the ftp server with a file size of 1000 bytes, and connect to this ftp server (assuming I have write permissions, the ftp server supports breakpoint transmission), and I also have a file called in the local area with a file size of 500 bytes. OK, I started doing bad things.
1. Connect to this ftp server (using the system's own ftp:///, it may not be able to use on the intranet, because ftp:/// is in port mode)
2. dir (check the size, it is confirmed that it is 1000 bytes)
3. quote rest 1000 (tell the ftp server that the file I will transfer starts from file location 1000)
4、send
5. dir (check the size again, now Readme.txt has become 1500 bytes)
Why did it get bigger? It's very simple, because the 500 bytes of my local one was uploaded successfully and written to the 1000 bytes file that exists in the ftp server. The problem is in the second command. If there is no second command, my fourth command (Send) will get a Permission Deny error. The second command is to make the ftp server trust us to perform a breakpoint and pass again. If there is no second command, the ftp server will think that we are performing an operation to cover the original file (the operation to cover the original file requires additional permissions to be performed).
Speaking of this, everyone should understand the meaning of the topic. Through very simple operations, any user with write permission can change the files uploaded by other users. This alone has a big security vulnerability. If the upload is an important file, random modification can completely destroy the file; if it is an executable file or some zip or rar file, will there be some genius crazy people who are familiar with various file structures add some malicious code to those files, causing the executor system to be damaged or their backdoor code or other? Since I am not familiar with these file structures, I only say that this is an unknown number.
But in the computer world, many impossible things are finally created into possibility, so I can't make a conclusion. But it is already very destructive to just destroy files. Think about a 500M film and television file. If someone adds bytes in it, it will probably not be able to be viewed anymore. The program that plays these files generally says that it is not a legal film and television file and cannot be played, etc. As for files such as zip, rar, winzip or winrar will definitely say that the compressed file has been corrupted, the crc verification code is incorrect, etc.
This problem only exists in FTP services that allow breakpoints to be transmitted again, but now 90% of FTP service programs allow breakpoints to be transmitted again, so this problem exists in general FTP servers.
Prevention method:
If you must upload permissions to the user, the best way to prevent them is to create a directory for each user and lock the user's permissions completely in this directory, then the user does not have permission to view the directories of other users, which means that the damage mentioned above cannot be caused.
The above mentioned was tested in Serv-U V4.0, and the test platform was Win 2K Server. If other ftp service programs do not have this problem, it is not within the scope of this article. Now that the ftp server is set up in the Windows system, the most popular one is Serv-U, so administrators should pay more attention. This article is not about teaching people to do bad things. If you use this method to destroy the ftp server files, the only person who is responsible is you. To quote a sentence from Gu Long's novel: "There is nothing wrong with the knife itself, the wrong thing is the hand holding it."
All ftp server programs that allow breakpoints to be transmitted must support a "Rest" command. If this command is used before uploading the command (send command), it tells the ftp server that the file I want to upload will start from where the file exists in the ftp server.
example:
Suppose there is a file in the ftp server with a file size of 1000 bytes, and connect to this ftp server (assuming I have write permissions, the ftp server supports breakpoint transmission), and I also have a file called in the local area with a file size of 500 bytes. OK, I started doing bad things.
1. Connect to this ftp server (using the system's own ftp:///, it may not be able to use on the intranet, because ftp:/// is in port mode)
2. dir (check the size, it is confirmed that it is 1000 bytes)
3. quote rest 1000 (tell the ftp server that the file I will transfer starts from file location 1000)
4、send
5. dir (check the size again, now Readme.txt has become 1500 bytes)
Why did it get bigger? It's very simple, because the 500 bytes of my local one was uploaded successfully and written to the 1000 bytes file that exists in the ftp server. The problem is in the second command. If there is no second command, my fourth command (Send) will get a Permission Deny error. The second command is to make the ftp server trust us to perform a breakpoint and pass again. If there is no second command, the ftp server will think that we are performing an operation to cover the original file (the operation to cover the original file requires additional permissions to be performed).
Speaking of this, everyone should understand the meaning of the topic. Through very simple operations, any user with write permission can change the files uploaded by other users. This alone has a big security vulnerability. If the upload is an important file, random modification can completely destroy the file; if it is an executable file or some zip or rar file, will there be some genius crazy people who are familiar with various file structures add some malicious code to those files, causing the executor system to be damaged or their backdoor code or other? Since I am not familiar with these file structures, I only say that this is an unknown number.
But in the computer world, many impossible things are finally created into possibility, so I can't make a conclusion. But it is already very destructive to just destroy files. Think about a 500M film and television file. If someone adds bytes in it, it will probably not be able to be viewed anymore. The program that plays these files generally says that it is not a legal film and television file and cannot be played, etc. As for files such as zip, rar, winzip or winrar will definitely say that the compressed file has been corrupted, the crc verification code is incorrect, etc.
This problem only exists in FTP services that allow breakpoints to be transmitted again, but now 90% of FTP service programs allow breakpoints to be transmitted again, so this problem exists in general FTP servers.
Prevention method:
If you must upload permissions to the user, the best way to prevent them is to create a directory for each user and lock the user's permissions completely in this directory, then the user does not have permission to view the directories of other users, which means that the damage mentioned above cannot be caused.
The above mentioned was tested in Serv-U V4.0, and the test platform was Win 2K Server. If other ftp service programs do not have this problem, it is not within the scope of this article. Now that the ftp server is set up in the Windows system, the most popular one is Serv-U, so administrators should pay more attention. This article is not about teaching people to do bad things. If you use this method to destroy the ftp server files, the only person who is responsible is you. To quote a sentence from Gu Long's novel: "There is nothing wrong with the knife itself, the wrong thing is the hand holding it."