Possible Overwrite of dot files when Updating AppImage from Home Directory

[antony-jr]

This is just a Hypothesis, no experiments so far. POC is available -> https://youtu.be/PbNthAK2WKQ

Let's say you have a AppImage without GPG signs(not so uncommon) and it points to some url. Let's say a domain or Github. Let us assume that the attacker has found a way to somehow edit the update channels (DNS Spoofing?, or DNS hack so to redirect to his evil server?).

Now if he releases a new release but now he does the following,

• Use the legacy zsync tool to generate a zsync file of a bash script.
• Now edits the Filename entry to .bashrc
• Now renames his bash script to .bashrc
• Uploads all required files to Github or the release channel.

Now let us assume a AppImage is updated from the Home directory. AppImageUpdate would simply sync from the update channels and when every checksum is verified it will rename the file to the target file name as given in the zsync file. Now the updater is pointing to the home directory as the output directory.

The important thing to note here is that AppImageUpdate moves the old file i.e moves the original .bashrc file in home to .bashrc.zs-old and renames the temporary file(which is a bash script) to .bashrc.

It is worthy to note that the Qt version of the updater does not do this. I've implemented this many years ago when the library was first created.

Does not touch the host system , like AppImageUpdate does(i.e AppImageUpdate sometimes deletes user files without any content integrity checks but this library does not touch the host machine at all , if the target file name exists it will rename the new target file with the current date time in ISO 8601 format placed in the middle of the filename , Thus avoiding deleting any files in the host machine.)

But if .bashrc does not exists then even my library is vulnerable to this exploit.

Now the attacker has exploited the user and can launch the attack once the user opens the terminal or just logs in? i.e whenever the .bashrc is executed

Some users of linux can find this but not the layman.

If you say you can check if the downloaded file is a AppImage, I've spoofed the update tool to think a bash script is AppImage and still run as .bashrc.

# Warning don't execute this in home directory
dd if=appimagetool.AppImage of=.bashrc iflag=count_bytes count=11

Now simply write your bash code after 10 or so lines I guess, I wrote it right after the binary stuff and it still works.

Please correct me if I'm wrong and please verify if this hypothesis can be implemented. You can say that if the server gets hacked then the AppImage itself can be made into an exploit but if it runs from Firejail even with a simple profile then this exploit is useless. But the attacker can gain some sort of advantage by doing the hack this way since AppImageUpdate is not run inside the Firejail generally. I think the default settings of AppImageLauncher does store the AppImages away from Home directory which makes this exploit useless here.

But assume if the developer itself is evil then he/she builds some sort of trust and release first 10 releases clean without anything suspicious and one release he decides to exploit everyone. So does this intentionally. Again to note, if a AppImage is run from Firejail simple attacks like this can be mitigated, but this type of vulnerability allows the attacker to somehow bypass this because of a flaw in the AppImageUpdate

CC: @TheAssassin
EDIT: See POC -> https://youtu.be/PbNthAK2WKQ

[antony-jr]

Please feel free to close this anytime.

[probonopd]

Thanks @antony-jr for this consideration.

Please feel free to close this anytime.

Has it been proven to be wrong?

[antony-jr]

Has it been proven to be wrong?

Nope. But I do not have a POC.

EDIT: I was just hinting you that you can close this issue if you have other important work and think that this is not viable.

[antony-jr]

@probonopd Actually this exploit works pretty good, See the POC -> https://youtu.be/PbNthAK2WKQ

[antony-jr]

If you want to test my updater, It won't even update this type of thing because of a small bug but anyways even if it does, it renames the file. (Tested with the fix to bug, it updates as AppImageUpdate but at final stage it renames to revised).

[antony-jr]

So in a way, This exploit or hack allows an attacker to gain full access to the computer with just AppImageUpdate updating a untrusted AppImage which runs in Firejail or QEMU or Virtual Machine but still can hack because of a bug in AppImageUpdate or zsync2 if AppImageUpdate is not run from Firejail or QEMU or Virtual Machine.

So what this implies is that AppImageUpdate itself has to be run inside Firejail or QEMU or Virtual Machine along with the untrusted AppImage. I think Firejail itself is weak here if access to the real home directory is possible.

I never tried other location based attacks, like using ../filename hacks but if it is possible then this is something very bad.

[TheAssassin]

Well, next time, please use responsible disclosure for such discussions.

I'll have a look at this potential exploit. I could well imagine that the filenames need to be sanitized for the same reason as in appiamged/libappimage, too. But I'll have to have a look myself.

[antony-jr]

Well, next time, please use responsible disclosure for such discussions.

I'll have a look at this potential exploit. I could well imagine that the filenames need to be sanitized for the same reason as in appiamged/libappimage, too. But I'll have to have a look myself.

For testing you can use the releases on this repo -> https://github.com/antony-jr/AppImageUpdate-Exploit-001-POC

I don't have any way to contact the core developers(like you) of AppImage via secure channels like email, there is IRC but I can't really write in detail there. It would be nice to put up some official email in the official site and also your GPG Public key to encrypt my message.

I don't want you to rush this and please take your time. Thank you for your time.

[TheAssassin]

IRC is already significantly more private, as there's something like private/direct messages.

But publishing an official contact address is a good idea.

[antony-jr]

Even if the AppImage was signed I was able to execute this exploit. So even GPG signs won't save you here. So only way to know if a AppImage is tampered or not is to use the provided GPG signature file or digest file by the author. Trying to map the AppImage into memory will crash your program if the given file is not a valid ELF binary. So it would be good to check the current AppImage GPG signature and digest first before update itself to prevent attacks like this, Because crash before the update is better than after moving the files.

[antony-jr]

EDIT: Thanks to https://github.com/AppImage/zsync2/blob/10e85c0eab4da4a1a85a949fb0f69d77cef9972f/src/zsclient.cpp#L406 this is not possible. For now.

I can infer from https://github.com/AppImage/zsync2/blob/10e85c0eab4da4a1a85a949fb0f69d77cef9972f/src/zsclient.cpp#L874 and https://github.com/AppImage/zsync2/blob/10e85c0eab4da4a1a85a949fb0f69d77cef9972f/lib/libzsync/zsync.c#L209

That if the Filename entry is something like /usr/bin/firefox can actually replace firefox with a evil version. That too an AppImage because it can run without anything. Also the user has no idea where this stuff is saved. Makes this exploit more dangerous than before. Further more, the executable bit is set default by the so called "Desktop Integrations"

But thankfully the official AppImageUpdate fails with permission error. Fortunately. But if the user were to run with sudo then there is no saving.

[antony-jr]

EDIT: I think the update fails if filename has path component, which is nice so this is only Home directory exploit.
So it does not care if the AppImage is home directory, we just do ~/.bashrc in the filename entry of zsync file. (Not tested though)

Thanks to https://github.com/AppImage/zsync2/blob/10e85c0eab4da4a1a85a949fb0f69d77cef9972f/src/zsclient.cpp#L406