2

CVE-2017-12617 is a remote code execution vulnerability via JSP upload. It requires the HTTP PUT method to be enabled on a vulnerable tomcat instance.

Why is this considered a vulnerability and CVE worthy? Doesn't enabling HTTP PUT on web servers always imply that files can be uploaded to the server, which are consequently processed / executed in the context of the web server when requested?

Onderbetaald
  • 141
  • 2
  • 1
    Maybe this makes it more clear: https://www.alphabot.com/security/blog/2017/java/Apache-Tomcat-RCE-CVE-2017-12617.html – Tom K. Nov 17 '17 at 12:28
  • Ah right, so the vulnerability is actually in the filter that should prevent uploading JSP-files. Thanks for clearing this out. – Onderbetaald Nov 17 '17 at 12:38

1 Answers1

2

From the CVE

This JSP could then be requested and any code it contained would be executed by the server.

PUT suggests a resource will be placed. But unless the API explicitly states so it does not imply it will change execution behaviour of the server.

Hector
  • 10,893
  • 3
  • 41
  • 44
  • I think this is not well-stated in the CVE. The JSP is not automatically executed after it is uploaded. You have to access the JSP via HTTP to let the server execute it. – Tom K. Nov 17 '17 at 12:56
  • @Tom - yes, but any attacker can send a GET request. It explicitly states that to be executed it has to be requested. What could they change? – Hector Nov 17 '17 at 12:59
  • Ah... don't mind my comment then. I misread that. – Tom K. Nov 17 '17 at 13:00
  • This is true, but I don't think this should be considered the vulnerability. This statement holds for any JSP file that is somehow uploaded and requested. Tom's comment linking to the actual blog contains the answer: _It was discovered that the filter that prevents the uploading of JavaServer Pages (.jsp) can be circumvented._ – Onderbetaald Nov 17 '17 at 15:15
  • @Onderbetaald - Sure. But that is just a bug. The exploit/vulnerability is that it can then be executed which leads to remote code execution. – Hector Nov 17 '17 at 15:18
  • @Hector Yes, it is the exploit, but it is not the vulnerability. The vulnerability lays in the defective filter as stated in the blog post. – Onderbetaald Nov 17 '17 at 15:24
  • @Onderbetaald - No, again that is the bug. The application is vulnerable because of the combination of the filter bug and that it will happily execute the uploaded object. If either wasn't true it wouldn't be vulnerable. – Hector Nov 17 '17 at 15:26
  • @Hector I think executing JSP-files from within the web root by the tomcat web server should not be considered a vulnerability. Even when they are uploaded via PUT. This is perfectly normal web server behavior. How else would any web server execute server-side code? This is exactly why I asked the question. – Onderbetaald Nov 17 '17 at 15:38
  • @Onderbetaald - Yes the server needs to be able to execute its own code. Ordinarily you would use a separate directory for user files and anything in that directory would not be executed by the server if requested and instead returned as is. Just filtering by extension/file type isn't suitable for all use cases. What if the server needs to host a downloadable JSP file? – Hector Nov 17 '17 at 16:08
  • @Hector, again your right. But this does not apply when you enable HTTP PUT for the web root, because you can now create files anywhere. The web server won't discriminate between a JSP-file created by PUT or created locally, but this is not the vulnerability. As discussed on the original [Tomcat bugtracker](https://bz.apache.org/bugzilla/show_bug.cgi?id=61542), the vulnerability is actually in the defective filter. Apparently, if a trailing / is added to a JSP-file in a PUT request (e.g. something.jsp/) you can upload JSP-files because the filter fails to recognize this as a JSP-file. – Onderbetaald Nov 18 '17 at 13:06