Vulnerability Review: Apache Struts CVE-2017–5638

综合编程 2017-07-06 阅读原文

Earlier this year, a remote code execution (RCE) vulnerability in Apache Struts 2 became widely known to the public. Known as CVE-2017–5638, the bug allows malicious users to execute arbitrary commands. It made headlines to “patch without delay .” The form and function of the CVE-2017–5638 was so severe, the National Vulnerability Database documented the vulnerability with its highest impact score, requiring low attack complexity, and no privileges to execute.

Luckily, the fix for end-users was easy (if not delayed) — upgrade software to the latest version and servers would remain safe. But what was so dangerous about CVE-2017–5638? Let’s take a deeper look into the exploit, potential consequences, and how to prevent similar vulnerabilities from being developed in the future.

Small Mistakes, Big Problem

Apache Struts 2 is an open source Web application framework that’s widely used by banks, government agencies, and large Internet companies. The Jakarta Multipart Parser allows file uploads based on the the Content-Type HTTP header, but inadvertently allows malicious users to execute commands on vulnerable servers.

Due to a feature in the way exceptions are handled, some version of Apache Struts could execute the content of exceptions if they contained a triggering string %{...} . But in certain situations, like parsing the Content-Type HTTP header, the string used in the HTTP request was also used to form the exception. An attacker can craft a certain value for the header in a certain way to purposely trigger an error, allowing the attacker to run arbitrary commands on the system.

Although the context (error generation) and execution (error handling) generate a single action, it’s highly likely they were created by two separate developers or teams. Open source development means that software increasingly becomes more assembled from different parties, leading to more scenarios like Apache Struts. The risk of open source is that innocuous and unintended functions can lead to dangerous consequences.

Speed or Security?

Unsurprisingly, the burden of remediation falls to the users to upgrade to the most updated and patched versions of software. If the developers were more security-minded, they could have removed the %{...} function entirely, or had it clearly documented for the rest of the team. But no amount of perfect patching stops the inherent problem of complex software development: monitoring and stopping code from functioning outside the norm.

Software assembly rewards shipping quickly, not security – we are tasked to meet the needs of customers, but often “kick the can” and push security further down the production cycle at enormous risk. The quest for both speed and security demands an automated way of checking for context mismatches that can result in vulnerabilities. We need intelligent solutions to find potential vulnerabilities early, and make it as agile and data-driven as possible. We need Speed and Security .

责编内容by:ShiftLeft Blog 【阅读原文】。感谢您的支持!


My Little CVE Bot I published the following diary on “ My Little CVE Bot “. ...
Apache Tomcat远程代码执行漏洞(CVE-2017-12617)... Apache Tomcat远程代码执行漏洞(CVE-2017-12617) 发布日期:2017-09-20 更新日期:201...
Apache Foundation rebuffs allegation it allowed Eq... The Apache Software Foundation has defended its development practices in the fa...
Struts2学习之使用PreResultListener PreResultListener是什么? PreResultListener 是一个监听器接口,它可以在Action完成控制处理之后,系统转入实...
Linux内核存在TCP安全漏洞(CVE-2018-5390)... 作者: 启明星辰ADLab 0x01 漏洞简介 2018年7月15日,国外安全研究人员Juha-Matti Tilli发现并报告了Linux内核的T...