Tomcat執行任意代碼漏洞，請檢查!
近期有朋友在后臺反饋 Tomcat 的漏洞，
到 Tomcat 的mail-list里查看郵件，果然郵件組里官方已經發布公告。
我們本次分析兩個 CVE 中的一個漏洞，該漏洞比官方公告影響范圍還要廣，除了 Windows 平臺之外，其他平臺也以另外的一種利用形式受到影響，具體執行任意代碼的風險，故在此描述，各位朋友查看自己的應用，如果有影響請盡快修復。
免責聲明
本文僅做技術分析及漏洞提醒，任何基于此從事的行為與本文無關。
漏洞描述
9月19日晚， Apache Tomcat 官方公告稱 所有 Windows 平臺上 開啟了 HTTP PUT 方法支持的， 都有遠程代碼執行的風險。漏洞代碼： CVE-2017-12615
官方描述如下：
詳細說明：
我們很久之前的文章介紹過， Tomcat 里包含了兩個默認的 Servlet， 用于處理特定的請求，一個是 DefaultServlet，一個是 JspServlet。這兩個 Servlet 都是在 Tomcat 默認的 web.xml 里被包含進來，與自定義的web.xml 進行 merge，所以每個應用都會有這兩個 Servlet。
由于每個 Servlet 都可以設置一些初始化參數(init-param) ，所以在默認的web.xml 里包含一些常用的，例如是否允許文件列表，是否debug，fileEncoding， sendFile的大小 等等。 這其中就可以設置是否允許HTTP PUT 方法。
參數配置項：readOnly, 主要用于對于HTTP 的 PUT / DELETE 方法是否進行拒絕。
- <init-param>
- <param-name>readOnly</param-name>
- <param-value>false</param-value>
- </init-param>
readOnly 默認是true, 也就是默認并沒有啟用PUT、DELETE這些方法。 如果有些朋友的容器由于應用依賴，開啟了readOnly ，一定要注意!!!
我們來看，在 DefaultServlet 的 PUT處理邏輯中，會先判斷readOnly
對于 DefaultServlet 的mapping 配置如下：
此時，如果請求URL 類似這樣：
請求方法: PUT
- 請求方法: PUT
- path: http://xxx/context/abc.jsp/
- data: 使用raw格式 <%out.println("Hello World");%>
使用Postman可以輕松構造一個(使用方法可以參考：Web開發神器之PostMan，接口測試再也不愁了)
PUT 的內容實際在處理時，會提取，并進行寫操作
- if(this.resources.write(path, (InputStream)resourceInputStream, true)) {
- if(resource.exists()) {
- resp.setStatus(204);
- } else {
- resp.setStatus(201);
- }
- } else {
- resp.sendError(409);
- }
這里的路徑，雖然是abc.jsp/ ，但在實際處理時，會進行處理，由于文件名規范的限制，***的一個/ 會被處理，所以就創建出了一個名為abc.jsp的文件，文件內容就是我們傳來的raw 里的內容。而這里的內容是可以隨意寫的。
當PUT請求返回后，再次請求 abc.jsp， 此時 raw里隨意寫的內容就會被執行，也就是我們前面所說的任意代碼執行的風險。
Apache Tomcat 官方描述的在 Windows 平臺中的漏洞，也是和命名問題，如果請求時url里是以abc.jsp%20這樣的 PUT 請求,到達 DefaultServlet 處理時，創建文件依然會把%20這個空格過濾掉，風險同上。
解決方案：
處理這個問題需要把 readOnly 設置為 true，或者保持初始值，不在web.xml中增加配置。
【本文為51CTO專欄作者“侯樹成”的原創稿件，轉載請通過作者微信公眾號『Tomcat那些事兒』獲取授權】
