Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to show that taking data as an input and writing directly to a file without parsing, checking or sanitizing it is a security risk.

Can anyone show an example of how this can be exploited. I was thinking that there may be a way to start writing to a new file instead of the one it should. if this is possible I may be able to write to a file named ls or less etc.

Sorry I forgot to mention the OS. It is Solaris.

The files are just data files possibly to be read into a database later but I don't want to count on the database as the only exploit.

A program on this servers is listening on a port and I can connect and send it data and I know that it will write this data to a file called output.dat later.

share|improve this question
Buffer overflow is the only obvious one I can think of – Gaius Oct 27 '10 at 15:13
Care to add more details? Like what OS? – Zoredache Oct 27 '10 at 16:33
Added more info to the question. – Brian G Oct 27 '10 at 17:46
actually it can be more secure if you don't parse it, the darn parsers could have buffer overflows etc.. Actually I'd state that the more transistions you have the less secure things will be. – tony roth Oct 27 '10 at 20:53

It really depends on what you're doing with that data. If the data gets used later as inputs to shell commands then you can just sneak in commands that subshell and execute arbitrary commands (install backdoor, add user, change passwords...) If the data gets inserted into SQL without prepared statements, then you have a standard SQL injection. The simplest case would be blowing up your partition's space; if you can generate data freely and without limits, then there's nothing stopping the attacker from overfilling the drive/partition. Most programs don't check for such condition, so it would go into an unknown condition, DoS'ing at best, exploitable at worst.

share|improve this answer
The only thing I can think of is a DOS by using all the disk bandwidth or filling a partition. Then all the standard security risks of a DOS come into effect. Is this a homework question? – Mark Wagner Oct 27 '10 at 17:24

Something very similar is a well known security mistake many websites make. If you take uploads from users (say, avatar images for a forum) and don't verify that they are actally valid image files, an attacker can upload a PHP file instead and execute it on your server by requesting it in a web browser from your images directory. It is often not adequate just to check the extension on the filename either, you must validate the contents of the file or run the risk of having a malicious file on your system.

The same is probably generically true of any situation where you accept a file upload and don't verify its contents. The file may be a Solaris executable just waiting for a careless chmod -R 777 /var/www or a perl script that adds a new user or a malformed PDF file destined to compromise the users of your website or a .htaccess file that redirects users to the attacker's site or even a symlink to /etc/passwd. (Actually, I'm not sure if it's possible to "upload" a symlink but it would certainly be possible to imagine a scenario where an untrusted user could create a symlink on your system.)

Verifying that a file's contents match what they are supposed to be makes it harder for an attacker to get his exploit code on your system. You are right in thinking that not validating is a security mistake.

Once the malicious file is on the system it still requires a second mistake/vulnerability to exploit the file but it puts the attacker one step closer to compromising your system.

Adding to this, you must also sanitise the filename if one is supplied. The .htaccess example earlier is one way an attacker could exploit a filename but filenames like "../index.php" or |/usr/bin/wget or ; wget or && wget could all do nasty things to your system depending on the file handling code.

If we are talking about Apache, it would be difficult to coerce it into overwriting a system binary like ls but if it's a server you have written yourself that doesn't drop privileges and is running as root then it would have the permission needed to overwrite system binaries and would just be waiting for the right file path.

share|improve this answer

It entirely depends on what platform you are on. For instance if this is a lamp system it can be as simple as writing a .php file to the web root or a more complex approach is an advanced LIF attack.

Under windows you can use some named-pipe trickery to get remote code execution.

share|improve this answer
yes but how can you switch what files you are writing to. Like if you know its written to input.dat . – Brian G Oct 27 '10 at 17:45
@Brian - it depends on what is writing the file. You don't tell us what's writing the file, or where it's getting the input from. – mfinni Oct 27 '10 at 17:49
@Brian G without any specifics relating to this vulnerably i am posting on how other exploits are able to gain remote code execution by uploading a file. – Rook Oct 27 '10 at 19:04
@Brian G being forced to write to input.dat isn't an issue alone unless you can pair it with another attack like an LFI vulnerability. Usually being able to write arbitrary files comes up in a directory traversal attack. In short this doesn't sound like a vulnerability. – Rook Oct 27 '10 at 23:37

As long as the attacker cannot change the file name or file metadata and there is a limit to the amount written, I cannot see an issue.

Otherwise, it would be dangerous to store any random data in a file. Provided the above is true, a file is just a container.

That is not to say that there is not a bug in the reading application that could be exploited. For instance, if there was an exploit in notepad or something and the user was able to write a sequence that utilized the exploit to what should be a text file.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.