GHSA-HVP5-5X4F-33FQ
Vulnerability from github – Published: 2024-04-22 15:56 – Updated: 2024-04-22 15:56Summary
when jadx parses a resource file, there is an escape problem with the style file, which can overwrite other files in the directory when saving the decompile result.
Although I don't think this vulnerability realizes path traversal in the true sense of the word , I reported it anyway
Details
I see that getResAlias does something with the filename.
private String getResAlias(int resRef, String origKeyName, @Nullable FieldNode constField) {
but type style will return the original filename directly.
so our goal is to take a malicious file that was originally of type raw, modify its type to style, trick jadx into
step1
create an android project using androidstudio and create a raw folder with the name attack_file_sayhiiiiiiiiiiiii, it doesn't matter what the content is!
generate an initial APK
step2
extract this initial APK using ZIP software to get resources.arsc
drop resources.arsc into 010editor
step3
search for the previous filename attack_file_sayhiiiiiiiiiiiii , two will appear here, we choose the second one
let's change the name of the file here. I'll change it to ../../_file_sayhiiiiiiiiiiiii
note that you can only overwrite files in the folder where the decompile was saved.
step4
change the type of this file to style
modified to 0E
step5
After saving, re-compress the whole folder into a zip, then change the extension to APK.
open it with JADX and you can see that it has been changed to a style type.
click save all
you can see the file escaping.
so we can also construct a
so the classes.dex file is also replaced here
PoC
the details above have been written
Impact
latest version
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.github.skylot:jadx-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-22T15:56:04Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\nwhen jadx parses a resource file, there is an escape problem with the style file, which can overwrite other files in the directory when saving the decompile result.\n\nAlthough I don\u0027t think this vulnerability realizes path traversal in the true sense of the word , I reported it anyway\n\n### Details\n\nI see that getResAlias does something with the filename.\n\n```java\nprivate String getResAlias(int resRef, String origKeyName, @Nullable FieldNode constField) {\n```\n\nbut type style will return the original filename directly.\n\n\nso our goal is to take a malicious file that was originally of type raw, modify its type to style, trick jadx into\n\n#### step1\n\ncreate an android project using androidstudio and create a raw folder with the name attack_file_sayhiiiiiiiiiiiii, it doesn\u0027t matter what the content is!\n\n\ngenerate an initial APK\n\n#### step2 \n\nextract this initial APK using ZIP software to get resources.arsc\n\n\ndrop resources.arsc into 010editor\n\n#### step3\n\nsearch for the previous filename attack_file_sayhiiiiiiiiiiiii , two will appear here, we choose the second one\n\n\nlet\u0027s change the name of the file here. I\u0027ll change it to ../../_file_sayhiiiiiiiiiiiii\n\nnote that you can only overwrite files in the folder where the decompile was saved.\n\n\n#### step4 \nchange the type of this file to style\n\n\nmodified to 0E\n\n\n#### step5 \n\nAfter saving, re-compress the whole folder into a zip, then change the extension to APK.\n\nopen it with JADX and you can see that it has been changed to a style type.\n\n\nclick save all\n\n\nyou can see the file escaping.\n\n\nso we can also construct a \n\n\nso the classes.dex file is also replaced here\n\n\n\n### PoC\nthe details above have been written\n\n### Impact\nlatest version \n",
"id": "GHSA-hvp5-5x4f-33fq",
"modified": "2024-04-22T15:56:04Z",
"published": "2024-04-22T15:56:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/skylot/jadx/security/advisories/GHSA-hvp5-5x4f-33fq"
},
{
"type": "WEB",
"url": "https://github.com/skylot/jadx/commit/d86449a8ea26381d0ce6fafaed7deb7542dfd70b"
},
{
"type": "PACKAGE",
"url": "https://github.com/skylot/jadx"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "JADX file override vulnerability"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.