Skip to content
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

tried to connect to the internet #334

Open
ghost opened this issue Jun 6, 2022 · 8 comments
Open

tried to connect to the internet #334

ghost opened this issue Jun 6, 2022 · 8 comments

Comments

@ghost
Copy link

ghost commented Jun 6, 2022

Expected behaviour

don't connect to the internet withou me asking for it and a image viewer should never try to reach the internet

Actual behaviour

trying to access the internet, this time was trying to access an IP 191.101.31.104 in Chile
found out was EOM because my internet firewall log says /usr/bin/eom

Steps to reproduce the behaviour

hard, it only tried once, trying to open more pictures to see if it goes again

MATE general version

Eye of MATE Image Viewer 1.26.0

Package version

latest in ArchLinux

Linux Distribution

ArchLinux

Link to bugreport of your Distribution (requirement)

@ghost
Copy link
Author

ghost commented Jun 6, 2022

Manged to make it try to connect again, this time I took not of the executable: /usr/bin/eom /tmp/ark-xxxx-random-chars created by the ark program that unzipped the picture.
this time the IP is 81.17.x.x
anyway, the program should not make any connection.

@lukefromdc
Copy link
Member

lukefromdc commented Jun 7, 2022 via email

@lukefromdc
Copy link
Member

lukefromdc commented Jun 7, 2022 via email

@ghost
Copy link
Author

ghost commented Jun 7, 2022

These were a few pictures downloaded from sites, compressed. I just double click to open and the image appears, because it was created a temp file and eom shows the pictures.
But even if the picture has a link in its properties, eom should never open it. If it is not eom, then it's the jpeg uncompress lib that asks for the connection. Still the program name that tries to open a link is eom.
I just wanted to understand who is trying to open that IP.
If there is no way eom try to open a link... then the jpg lib has a serious fault.

@lukefromdc
Copy link
Member

lukefromdc commented Jun 7, 2022 via email

@ghost
Copy link
Author

ghost commented Jun 7, 2022

Ok thanks. I don't have them but I will try to download again and open. I do have VM's where I can test that out safe.
I'm on Archlinux Plasma Wayland so I don't know it that applies for that XORG exploit.

@lukefromdc
Copy link
Member

An xorg exploit would play no role in wayland, as with eom supporting wayland since an "enable wayland support" commit it should not have to run xwayland. Check on Xorg as well if possible to see if a wayland specific bug exists.

Also look for DIFFERENT urls being sought by different files, which would suggest malicious files

@lukefromdc
Copy link
Member

lukefromdc commented Jun 8, 2022

Also, I just did a test with a known good online photo I had posted myself: opening the URL of an online/remote photo in eom works, so code to connect to the Internet, fetch a photo, and display has to be included. This is not a terminal feature: replacing
eom
with
hexdump
gets
No such file or directory
from the terminal

Note that long ago, browsers depended on plugins for a lot of media handling, though I have no idea if that ever extended all the way down to images. Also note that the first browsers were text only and some like lynx are still in use. For that use case, for eom to be able to handle a remote file is useful. Now we need to find out why a downloaded file is trying to access a remote link. Make sure you have the actual files and not just links to them. If the image opens with the network disabled,you definately have a local image. I would presume any embedded call back to the network from such an image to be malicious until proven otherwise

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant