Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
XXE in PwDatabaseV4 #200
An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.
Where the Issue Occurred:
Throwaway account, but wanted to put some info out there.
KeePassDX (as of now) does not have the required permissions for internet access (not sure about localhost - that is potentially another attack vector if KeePassDX does open itself up in any way over localhost of course).
This doesn't mean that KeePassDX isn't vulnerable to XXE attacks (it is), but when it comes to stealing passwords with this attack via sending payloads to an external server, the way in which an attack like this is conducted is severely limited.
On the other hand, MANY other attacks that utilize XXE-processing exploits are still possible, and aren't affected by the lack of internet access!
As a Side Note:
Hypothetical DOS Attack Example
One such attack would be a Denial of Service attack where the app would crash upon attempting to parse a KDBX file. The attack would assume that:
By referencing a device (/dev/*) that is inaccessible to non-root apps, a security exception will be thrown in KeePassDX, causing the app to crash (if unhandled).
This is just one of many potential attacks and attack vectors that XXE processing allows for.
Patching the Exploit:
The Android Developer documentation for the XMLConstants class only exposes one feature that we can turn off to prevent this attack (FEATURE_SECURE_PROCESSING). However, let it be noted that I have not tested to see if this feature was implemented correctly in the Android SDK. It is possible that the DocumentBuilderFactory's XML parser is not implemented correctly, and that it will still be vulnerable to an XXE-processing exploit, but while possible, it's improbable for this to be the case as it has been implemented since SDK Level 1.
Saying this, I highly suggest that this is checked (or further researched to see if this has been checked) before fully accepting the following solution. I also suggest researching more about this before you implement a fix for it and accept the fix as a fully-secure solution.
Nevertheless, here is the solution to be implemented for ALL database versions and their respective classes. The code may need to be refactored and an additional class added to handle this without needing to think about it when supporting future database versions, but this decision is left up to the community.