-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RCE vulnerability when copying full system paths #453
Comments
As I said, I'm not an |
The clipboard content type may be a filename represented by a variety of mime-types, so double-check it is supported type before loading the contents. closes Tudmotu#447 closes Tudmotu#453
Thank you @Edu4rdSHL for reporting this. @andyholmes would you mind explaining why does this happen (I assume you understand because you fixed it)? I cannot understand how would the extension execute a command 😳 |
To be honest, I didn't trace it all the way down. The only thing that makes sense is that I guess maybe some image formats, like maybe animated GIFs, are executables in some sense so it's capable of doing that? It sure sounds like something ridiculous an image processing library would do :/ |
The thing is that it's opening binary files too, such as |
I would even be that optimistic that if the affected mimetype is removed from the list, the issue wouldn't happen anymore, but that just a naive assumption. |
Yeah, I understand it for images, but why for a UTF-8 string. |
I can't answer why the extension loads the contents of text files, rather than just displaying the filename. Either way the bug would still exist, since I doubt there's a way for the clipboard implementation or anyone else to determine whether the mime-type is actually accurate. The source application just says "here's a blob of data, and here's the mime-type you should advertise it as". In this case, it's just fortunate we can rely on Gio checking the content type (somewhat slowly) and not have to trust the mime-type. |
Oh damn, ok. @Edu4rdSHL I think it's like this:
The [incomplete] theory goes like this: sometimes, the extensions tries to create an
If these two things happen, the extension will load the binary data of the path you copied and try to create an What I'm still missing here is: Why does the extension identify the But I understand how @andyholmes' solution solves this. |
Thank you so much for the detailed explanation @Tudmotu, and thanks @andyholmes for the fix! Will be there a release including this fix on the extensions website soon? |
@Edu4rdSHL Yes, I uploaded it to e.g.o now: It might take a bit before it's approved. |
Thanks! I will try to get it approved asap with the extensions team. |
Ah, I found this in const char *supported_mimetypes[] = {
"text/plain;charset=utf-8",
"UTF8_STRING",
"text/plain",
"STRING",
}; I would not count on that being a complete list though, because honestly why are there four to begin with, and |
Yeah, currently the extension tries to mimic I hope this will be solved once I get to implementing the multi-mimetype support in Mutter. Unfortunately I'm not sure when I'll get to that. Once Mutter has multi-mimetype support, this extension will no longer be opinionated on which mimetype it should keep in the history file ― it would just keep all of them. Right now it kind of "guesses" which mimetype is the most appropriate (based on the first mimetype that returns a value from the clipboard). |
Ah gotcha, that would be good. I didn't realize Mutter was missing that, since I believe the portal-side advertises API support. |
Yeah technically the interface supports multiple mimetypes, both Wayland and X11 have multi-mimetype implementations but |
The entry parsing is broken, and I don't even know whether the underlying issue is the extension or something the extension depends on. It leads to a RCE, basically. If you copy a full system path, e.g
/usr/bin/ls
and the mimetype gets set toUTF8_STRING
it will get executed/opened on the system! And thecontents:
key is replaced by that. For the example mentioned before about/usr/bin/ls
, it's what you get:https://gist.githubusercontent.com/Edu4rdSHL/20d05e03dfe4777eca76dba3c68d0f63/raw/587b6f38a62329e0d09d9bd992616195835a5b62/gistfile1.txt
It does look bad, and I'm not familiar with developing extensions to see where and why is this happening.
Regards,
Ed
The text was updated successfully, but these errors were encountered: