tomcat6-6.0.24-111.AXS4
エラータID: AXSA:2017-2380:03
リリース日:
2017/11/01 Wednesday - 17:30
題名:
tomcat6-6.0.24-111.AXS4
影響のあるチャネル:
Asianux Server 4 for x86_64
Asianux Server 4 for x86
Severity:
High
Description:
以下項目について対処しました。
[Security Fix]
- HTTP PUT が有効な状態で Apache Tomcat を実行する際に,
リモートの攻撃者が、巧妙に細工されたリクエストにより
サーバに JSP をアップロードし,またアップロードされた
JSP ファイルをリクエストすることにより任意のコードを
サーバが実行する脆弱性があります。
(CVE-2017-12615,CVE-2017-12617)
- Apache Tomcat には、パイプライン化されたリクエストの処理に
バグが存在し,send file を用いた場合,あるリクエストが完了
した際にパイプライン化されたリクエストが消失し,クライアントが
誤った応答を得る可能性がある脆弱性があります。(CVE-2017-5647)
- Java Servlet 仕様のエラーページのメカニズムは,エラーが生じ,
エラーが生じたエラーに関してエラーページが設定されている場合,
元のリクエストとレスポンスはエラーページに転送されることを要求し
ています。DefaultServlet が書き込み可に設定されている場合,元の
リクエストにより,静的なエラーページに対して,カスタムのエラー
ページの置換,削除を含む,予期できない,望まない結果につながる
脆弱性があります。(CVE-2017-5664)
一部CVEの翻訳文はJVNからの引用になります。
http://jvndb.jvn.jp/
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2017-12615
When running Apache Tomcat 7.0.0 to 7.0.79 on Windows with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
When running Apache Tomcat 7.0.0 to 7.0.79 on Windows with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
CVE-2017-12617
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
CVE-2017-5647
A bug in the handling of the pipelined requests in Apache Tomcat 9.0.0.M1 to 9.0.0.M18, 8.5.0 to 8.5.12, 8.0.0.RC1 to 8.0.42, 7.0.0 to 7.0.76, and 6.0.0 to 6.0.52, when send file was used, results in the pipelined request being lost when send file processing of the previous request completed. This could result in responses appearing to be sent for the wrong request. For example, a user agent that sent requests A, B and C could see the correct response for request A, the response for request C for request B and no response for request C.
A bug in the handling of the pipelined requests in Apache Tomcat 9.0.0.M1 to 9.0.0.M18, 8.5.0 to 8.5.12, 8.0.0.RC1 to 8.0.42, 7.0.0 to 7.0.76, and 6.0.0 to 6.0.52, when send file was used, results in the pipelined request being lost when send file processing of the previous request completed. This could result in responses appearing to be sent for the wrong request. For example, a user agent that sent requests A, B and C could see the correct response for request A, the response for request C for request B and no response for request C.
CVE-2017-5664
The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.
The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.
追加情報:
N/A
ダウンロード:
SRPMS
- tomcat6-6.0.24-111.AXS4.src.rpm
MD5: f107bb6a7d2326e060a4d222e15e1bc9
SHA-256: d67cd1105f796b2f63d55cb5eca3811f15853c1f19f6912dfe20601b43bf8bfb
Size: 3.65 MB
Asianux Server 4 for x86
- tomcat6-6.0.24-111.AXS4.noarch.rpm
MD5: 104e842dd4334ffde5553be1b036d579
SHA-256: 4e143a4d3c1acccf0517b360aab38852f64afd40fddc5c248261bddbfb7d9a69
Size: 95.81 kB - tomcat6-el-2.1-api-6.0.24-111.AXS4.noarch.rpm
MD5: a15c4b4acc2f94d20434a410aa81f9d4
SHA-256: a3b25c62ac072bccfe4fa232942aab46ee5e9f6dfe9c943041d89d7b7a178f47
Size: 51.59 kB - tomcat6-jsp-2.1-api-6.0.24-111.AXS4.noarch.rpm
MD5: b9ce40873bd7267f67af440602442db0
SHA-256: c48cdb4feb7f7d7061f58dcae9f430f83728cbf93310b996160aaead87e2e8ed
Size: 88.04 kB - tomcat6-lib-6.0.24-111.AXS4.noarch.rpm
MD5: 92833592e8ae2fd4cc6cc5398e5a3277
SHA-256: fe9a0e126b70aee22cfdcdc25da3c2ff5cf5f5e1073bd6c235e5fb3d7b4bb07b
Size: 2.92 MB - tomcat6-servlet-2.5-api-6.0.24-111.AXS4.noarch.rpm
MD5: 7f09c8e3532a1d26419729021f014f04
SHA-256: 930cce5d97ca956836d5daee0a497bab6f6fb08e0a74f0dcbfbeae366877f086
Size: 122.07 kB
Asianux Server 4 for x86_64
- tomcat6-6.0.24-111.AXS4.noarch.rpm
MD5: 7b30980ff714c4f84cd96750b1de1682
SHA-256: 4ee122b3c8cbc8af55458585ecb0bbaa8c352a4cb437ec77f2befb51729a01c5
Size: 95.38 kB - tomcat6-el-2.1-api-6.0.24-111.AXS4.noarch.rpm
MD5: d75bfc69ccd514b9bae9ba20acf75619
SHA-256: 635ad48c600f758b171e4546a28c4b5c1c5e7b5f2cbf5400afdaba45360789c6
Size: 51.14 kB - tomcat6-jsp-2.1-api-6.0.24-111.AXS4.noarch.rpm
MD5: d22b712097975bf677217be3f4222a03
SHA-256: 7ac824d7fd1d0eec4152099774dc2df6151f375395ae48c77dd00afaf077633a
Size: 87.60 kB - tomcat6-lib-6.0.24-111.AXS4.noarch.rpm
MD5: 06b8edba75eb5cb85501a2e2ef383fca
SHA-256: 06f675fd9d3d98bb02c38af4358ceccec72f26a7dce232e79c043ac441735a33
Size: 2.92 MB - tomcat6-servlet-2.5-api-6.0.24-111.AXS4.noarch.rpm
MD5: fe31ec333d244fb991c3d36f00579215
SHA-256: fd3d593b579b8775d52a2e9b150221c6bb8949860cb83c21b3009ce1cf7da6bb
Size: 121.62 kB