(asking young nephew for help with this thread thing), Bugtraq is closed? 2/
Conversation
Chrome SOP bypass CVE-2020-6516 HTML sent by attacker can access any file in /sdcard. Bad
1
5
36
\o WhatsApp stores SSL/TLS secrets and some useful info for attackers in /sdcard. Bad. Attackers can get the secrets from JS code in a HTML attachment and use them to hijack connections between WhatsApp and servers. Bad but ehhh2eeehh encryption ...
1
20
73
o/ The first time a user attempts to use a photo filter a .zip archive is downloaded from static.whatsapp.net/downloadable?c and extracted. Attackers can intercept the request (using the stolen SSL secrets) to send a malicious .zip insted. Can you guess? Yes ../../../
2
7
34
../ To make this RCE chains easier WhatsApps stores native libraries in /data/data/com.whatsapp/files/decompressed/libs.spk.zst 🤷♂️attackers can use the .zip bug to overwrite any of them (I would go for the Rust ones) and execute arbitrary code.
2
8
37
Replying to
A lot of apps use this anti-pattern instead of using the standard approach.
The legacy approach has the package manager extract your libraries. Same permissions as the apk so the app can't write to them. The modern approach maps them directly from the apk, saving a lot of space.
1
1
This Tweet was deleted by the Tweet author. Learn more
Replying to
It's probably twitter.com/DanielMicay/st like Firefox. I would say ignorance, essentially. They don't realize how much more efficient it would be to map libraries directly from apk, don't realize the OS implements it for them now and that there's a Chromium library for legacy OS.
Quote Tweet
Replying to @DanielMicay and @julianor
It's probably to save space compared to the legacy standard approach. They can use a better algorithm than DEFLATE and compress them together instead of separately.
It's very wasteful compared to the standard approach of mapping libraries directly from apks like other resources.
1
The apk format always used the approach of storing files uncompressed and page aligned for other assorted things. Chromium adopted it for libraries and then that ended up in the OS itself, easily usable by others. An apk is meant to be compressed in transport even without this.
1
Firefox did this particularly horrifying thing where they only extract the data from the apk on-demand by reserving the address space for the libraries and handling the segmentation faults. They have code for monkey patching libc to support their own form of signal chaining, etc.
1
1
1
Android stopped allowing apps targeting modern API levels to run executables from their app data directory (execute_no_trans) but they haven't removed execute for mapping code as executable from there yet. I assume they intend to remove it eventually but it's more disruptive.
The remaining ways of doing dynamic *native* code execution for a modern app are execmem, ashmem execute, tmpfs execute and app_data_file execute. We remove them in GrapheneOS for base OS.
Intend to provide a way to enforce that for non-base OS apps too. Can't really by default.
1
Of course, you can still screw up with Java class loading, POSIX shell, WebView set to be non-contained or your own interpreters, etc. The OS could make it hard to screw up though.
IMO, Google would have pushed a lot harder on this if only ART hadn't decided to add back JIT...