Community
Participate
Working Groups
Steps to reproduce: 1. Open a new Android project in Eclipse or download a existing project (for example: GitHub). 2. Add XXE payload to the AndroidManifest.xml file. 3. Open the project with Eclipse and the payload will be executed. An attacker can build a malicious project library containing XXE payload and distribute it. Anyone who downloads the malicious project and open it using Eclipse will be affected. An Attacker can extract any file he wishes to from the victim's file system.
I don't understand the attack scenario, but let me still: - move the bug to Andmore, assuming that this would be the component that handles AndroidManifest.xml (JDT doesn't) - hide this bug until we understand and/or have a solution. Specific question regarding the scenario: If a user opens a malicious file on his/her local machine, how will the attacker benefit from this? What kind of code can be executed and by which component?
Hello, An example for an attack scenario: A user clones a project from GitHub. The GitHub project was created with XXE payload in AndroidManifest.xml. The user opens the cloned project in Eclipse and the payload is being executed. The attacker can steal any file from the file system (or the whole file system...). This is just an example for a benefit that the attacker can have using this attack.
Again, I have close to no knowledge about XXE attacks, but my initial understanding was: typically this approach can be used to trick a webserver into answering some secret information. Inside the IDE there's no webserver involved. The attacker cannot see the result of retrieving, e.g., a local file UNLESS the attack can execute code that will connect to the network and send information back to the attacker. Is that what you are thinking about? Can XXE payload be executable Java code, e.g.? If not by actively connecting to the network, I don't see the attacker anywhere in the picture during runtime of Eclipse.
Hello again Stephan, You are very close to understand the issue, however XXE attack can be launched against any user PC and not only against web application servers. This allows an attacker to create a malicious project and infect the victim with it. Once the victim will load the project, the AndroidManifest.xml file, containing the XXE payload, will get executed on the victim PC.
Hi Stephan, Two weeks have passed since the last message. Any updates? Best Regards, Alon
One: I still don't understand which part of an IDE would *execute* portions of an XML file. Two: All seems to be specific to Android development, of which I know close to nothing. This is why I moved the bug to the Andmore component, in the hope a developer of Andmore would pick it up.
Hi Stephan/David, Any update?
I still haven't seen explanations for all of my questions. All I tried was to mediate between bug reported and a responsible developer, and since I can't help further I'm leaving this bug now.
(In reply to Stephan Herrmann from comment #8) > I still haven't seen explanations for all of my questions. All I tried was > to mediate between bug reported and a responsible developer, and since I > can't help further I'm leaving this bug now. Yeah, I need to research it myself.
More information around what XXE actually is. https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
Configuration options on combatting XXE for various Java related ways of parsing the XML can be found here. https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet I'll add this to my queue of stuff to look at, but I would not be surprised if other Eclipse related projects might be vulnerable to this if they use an XML parser that understands DTDs. This is something that has to be specificially added by the User to the XML. While we can handle this on the Andmore side by looking at how the XML Parsers are configured once it is built by the Android tooling and packaged as part of the APK it is out of our hands. From our side, I think we can safely disable any DTD processing or use of external entities.
My weekend looks like it has freed up a bit, so I should be able to try get a simple fix for this by disabling DTD support within the Stax2 readers that are being used. I don't think this will affect any down stream consumers, but we'll find out. May have to make this configurable long term.
Hi David, you are right saying that this vulnerability should be fixed for the long term. Thank you for the acknowledgement.
(In reply to Alon Boxiner from comment #13) > Hi David, you are right saying that this vulnerability should be fixed for > the long term. > Thank you for the acknowledgement. Last weekends plans fell through, I have some pto coming up so will address what I can here this coming weekend.
Hi, We are going to publish the story today. almost 5 months have past and we did not get an update if the issue was solved. Please let me know what is the version number that it was solved on. Thank you, Alon
Created attachment 271649 [details] Test Case attached a test case. Please update me as quick as you can as it meant to go out today...
(In reply to Alon Boxiner from comment #16) > Created attachment 271649 [details] > Test Case > > attached a test case. > Please update me as quick as you can as it meant to go out today... While this is a potential vulnerability, the risk here is pretty low. Thanks for the test case, I've analyzed this vulnerability, and from experience, this is pretty low, as somebody would have to bring in the source code from an unknown source to be affected by it. I'll keep this issue open so that we do address it, but there may be some valid reasons to allow Doctypes and custom entities to be created, to this affect one needs to be able to define System refernces. This was also reported to Google back in 2015 as well, and so far they have not addressed the issue that I'm aware. http://www.securityweek.com/android-manifest-file-attacks-can-make-devices-inoperable
(In reply to David Carver from comment #17) > While this is a potential vulnerability, the risk here is pretty low. Earlier discussion suggests that import from GitHub is a hazard. Provision of a GitHub repro is a common mechanism for supporting bug reports, so it appears that there is a major hazard for Eclipse committers. How can I review the content that I am provided?
(In reply to Ed Willink from comment #18) > (In reply to David Carver from comment #17) > > While this is a potential vulnerability, the risk here is pretty low. > > Earlier discussion suggests that import from GitHub is a hazard. > > Provision of a GitHub repro is a common mechanism for supporting bug > reports, so it appears that there is a major hazard for Eclipse committers. > How can I review the content that I am provided? The thing with this particular bug, is that it pretty much makes any use of DTDs in XML documents useless. So it means no importing of DTD that define other items that may be store via a URL. In order to reproduce this, one would have to clone a repository that contains the vulnerability attached as a Test Case... then open that XML file, either through the Android tooling or another XML tool that did not have DTD support disabled. This means tools like WTP which supports DTDs could be vulnerable to this if they opened an XML file that contained the bad System file. The balancing point here is disabling needed functionality with the possiblity that you get a file that has this issue.
What is the status of this issue? We are long past the time to disclose (by removing the committer-only flag).
