eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Polish firm Security Explorations claims it has discovered more than two-dozen vulnerabilities in the Google App Engine Java environment, some of which allow native code execution and Java security sandbox escape.
There are potentially several more vulnerabilities in the environment that the company has not been able to verify so far, Adam Gowdiak, CEO of Security Explorations, wrote in a Sept. 7 advisory on Full Disclosure, a mailing list for discussing security vulnerabilities and exploits.
Google App Engine (GAE) is a Google-hosted service that allows businesses to build and maintain applications written in Java, Python, PHP, Go and other programming languages. The company offers software development kits in the supported languages. Each contains the APIs and libraries available to App Engine, a secure sandbox environment that emulates App Engine services on the developer’s local computer and numerous deployment tools for the cloud.
The flaws enable attackers to bypass GAE’s Java Runtime Environment (JRE) Class whitelist, escape the Java Virtual Machine security sandbox and issue arbitrary library and system-level calls. At least 22 of the vulnerabilities allowed an escape from the security sandbox, Gowdiak said, adding that Security Explorations was able to exploit 17 of them via proof-of-concept code.
Google’s Java security sandbox is designed to prevent Web-hosted applications from interfering with each other. According to Google Applications, running in this environment can execute code and store and query data in the App Engine data store but cannot write to the file system or make other kinds of system calls.
“We gained access to the files (binary/classes) comprising the JRE sandbox, that includes the monster libjavaruntime.so binary,” Gowdiak said. Security Explorations was also able to learn a lot about the GAE environment’s Java sandbox by extracting information from debugging tools and protocol buffering methods, he said.
“There are more issues pending verification—we estimate them to be in the range of 30+ in total,” Gowdiak wrote.
Security Explorations has been forced to halt its research because Google has suspended its GAE account. “This week we did poke a little bit more aggressively around the underlying OS sandbox [and] issued various system calls in order to learn more about the nature of the [sandbox],” he conceded. “Without any doubt, this is an opsec failure on our end,” he added, expressing hope that Google would reinstate the company’s account.
“Taking into account an educational nature of the security issues found in GAE Java security sandbox and what seems to be an appreciation Google has for arbitrary security research … we hope the company makes it possible for us to complete our work,” Gowdiak said. Reinstating the account will allow researchers at Security Explorations to verify the remaining vulnerabilities and potential exploits and to provide a report documenting all the findings for the security community.
In an email response to an eWEEK query, Gowdiak said it is impossible presently to assess the severity of the discovered flaws because Security Explorations no longer has access to its GAE account. “We broke out of GAE Java security sandbox and gained native code execution in the environment,” he said. That meant Security Explorations had the ability to execute code outside the sandbox and start poking into the operating system sandbox layer. “This is still local code execution though, not a remote one,” he said.
The flaws are the result of some simple mistakes pertaining to known Java security problems, he said. “Google is currently looking into the material we delivered to the company. We don’t know of any other status regarding the reported issues,” he said.
In an emailed comment, a Google spokesman said the company takes all reports of vulnerabilities in its products very seriously. “We are investigating Security Explorations’ posting to the Full Disclosure mailing list,” the spokesperson said. “We have no reason to believe that customer data and applications are at risk.”