2

Is it possible for an uploaded PDF file to harm an Apache server, if the filepath can't be found? That is, the PDF file can't be viewed from the browser or accessed by a known path once uploaded.

I have a feature within a Drupal site that allows anyone to upload a PDF file in order to have some ImageMagick processing done to it. The resulting file is a JPEG.

The PDF file is automatically deleted a soon as the JPEG is viewed. But I'm concerned that even during the short processing time, a malicious PDF could do harm to the server. Or that the IMageMagick processing can be interrupted and allow the PDF file to live on the server.

Here's the procedure:

User browses for and chooses the PDF file.

User Saves the node.

  • the ability to view the uploaded PDF prior to saving the node has been disabled (unset in the form, not just hidden)
  • on upload, the PDF file name changes, and the upload directory name contains a random string
  • there is a file size limit
  • supposedly the mimetype is detected using PHP FileInfo but I can't tell if that's working (a test indicates it's not)

ImageMagick processing occurs.

The new node is automatically displayed.

  • PDF file is automatically deleted as soon as the node is viewed
  • The new node contains only a link to the resulting JPEG
1

It could harm. Consider that a malicious user may build a malicious PDF in order to exploit your imagemagick implementation and gain access to your system.

Another question would be "can a file for its mere existence damage your business?". Let's take different security approaches:

  1. Integrity: I can't see a file compromising the server integrity if nobody and no process uses it. Of course your original file set in your server will be different after leaving this file there. But it is somewhat fine...
  2. Confidentiality: this is a point, if you tell your users their PDF is secret but it can actually be download if someone knows the path, then you are lying to them. And this will be a vulnerability in your service. Since you say it is unavailable to anyone, I can't see any vulnerability here.
  3. Availability: normally it wouldn't but if eventually more and more PDFs are left there by errors you eventually will have no space in your disk to continue with your service so, here you have another vulnerability. Even only one could trigger this problem for some design error.
  4. Non repudio: I can't see any problem here for this service.
  • Another potential for harm is an automated previewer or indexing service might look inside each file in order to make it searchable. A malicious PDF could be designed to attack the indexer. (Such attacks have occurred in the wild, using metadata in an image file, as I recall.) – John Deters Feb 21 '14 at 21:04
  • @John Deters: If I don't have such an indexer on my site, or I keep it out of this particular file folder (which is outside the public_html directory) would there still be this potential? – keva Feb 21 '14 at 22:29
  • @kiBytes: thank you for the analysis. What is "Non repudio"? Also, you mention that "Consider that a malicious user may build a malicious PDF in order to exploit your imagemagick implementation and gain access to your system" but also "I can't see a file compromising the server integrity if nobody and no process uses it" ... this look like a contradiction, but perhaps I don't understand? – keva Feb 21 '14 at 22:35
  • @keva the first paragraph refers to the processing of the PDF the point #1 refers to the file once has been left behind in a folder. Non repudio refers to another security characteristic, maybe in English is referred as another term (also is long enough so it should be explained as an answer to a question). – kiBytes Feb 22 '14 at 1:13
  • You reduce the risk, certainly, but it's hard to say with 100% certainty. What if a working copy of the file is copied to a temp folder by imagemagick, and that folder is indexed? You're probably OK, but it's something to be cautious about. – John Deters Feb 22 '14 at 2:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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