Hi,

thanks for packaging minigalaxy. Unfortunately it's unusable as you
can't conscientiously login to GOG:

On startup it shows a login window which looks suspiciously like a GOG
login window in a web browser, but without without any possibility to
check its origin: It has no location bar, i.e. shows no URL, it doesn't
indicate if the entered credentials are transmitted encrypted via HTTPS
or not, and it offers no chance to review the HTTPS TLS certificate if
present.

Proof that it actually is a browser window:

It has "Back, Forward, Reload, etc. in the right click context menu and
I see two "WebKit" processes being forked from minigalaxy:

abe      24326  2.6  0.1 86076304 113572 pts/16 Sl+ 00:12   0:10          \_ /usr/bin/python3 /usr/games/minigalaxy
abe      24799  7.1  0.2 86563632 160396 pts/16 SLl+ 00:12   0:27              \_ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 7 16
abe      24802  0.0  0.0 86442844 59232 pts/16 SLl+ 00:12   0:00              \_ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess 8 16

Possible solution: Don't use an embedded browser windows but call
sensible-browser or so to use the browser which the user is probably
already logged in to GOG anyways.

Or just show the location bar of the browser window which lets the user
have a look at the URL and certificates being used.

Hi Alex Beckert,

Thanks for the report and the suggestions. I'm developer for Minigalaxy
and your concerns make sense.

To address the suggested solutions. Using an external browser for
authentication is unfortunately not possible with Minigalaxy, because
after the login Minigalaxy takes the page URL to get the code which is
used to authenticate with the API. With an external browser retrieving
this would not be possible. Showing the URL of the browser window could
be implemented.

Some additional information about how the systems works at the moment:

- It uses the girl1.2-webkit2-4.0 package for the webkit engine.

- It uses HTTPS for all API calls and for the login screens. In the code
you can see HTTPS is used here:
https://github.com/sharkwouter/minigalaxy/blob/1.0.1/minigalaxy/api.py

Having said all that, this does not seem like a security issue to me.
Authentication happens using the same page the official GOG client for
Windows does. The user could be concerned, but there does not seem to be
an actual security risk.

Hopefully this helps understand how Minigalaxy does authentication a bit
better and makes you feel less worried. An issue has been created in our
issue tracker to address the visibility of the URL in the browser window.

Kind regards,

Wouter Wijsman

Hi,

thanks for your bug report. I've taken a look into it and I reduced the
severity for a couple of reasons.

Since Minigalaxy is open source, it's very easy to check if it connects
actually to GOG via https. I checked the code and it is fine.

This problem actually isn't solved by showing an address bar or the
certificate, since that can easily be spoofed. It could just connect
to GOG to show the certificate but also connect to a different, similar
looking website and show it to the user. This applies to all browsers,
that is why open source is important.

In the forwarded bug report the maintainer states that an external
browser is not a solution at the moment. Their argumentation sounds
reasonable to me.

However, I will look into adding the address, as it probably is not a
bad idea. But this is more of a wishlist thing, not an actual security
concern (at least to me).

Regards,
Stephan

Hi Axel,

I had checked it before sponsoring the initial upload too. This is one of
those things I tend to assume from Debian: that the packages provided in the
archives are safe.

Yup, exactly, it would be quite easy for a malicious client to present a
reassuring UI; having such a UI wouldn’t prove anything.

See also lgogdownloader which does pretty much the same thing.

Regards,

Stephen

Hi Stephen and Stephan,

(JFYI: I only got Stephen's mail.)

Stephen Kitt wrote:

Ack. But MITM attacks happen outside of the software. Think DNS
spoofing. Before I enter a password anywhere, I should be able to
check at least the certificate.
packages provided in the Debian archives are safe. I just can't assume
that the network I'm in is safe.

Feared that.

As mentioned, I haven't got Stephan's mail. I now see that this has
been downgraded to wishlist with that mail. I disagree. This is a clear issue.

I though must admit that the login window at least says "Unacceptable
TLS certificate" if I try to do a MITM attack on auth.gog.com.

I am nevertheless still of the opinion that this is not a feature
request but a security issue.

Actually I tried that one first as it was in Debian first. Horrible
user experience:

It's a Qt written tool according to its dependencies (i.e. a GUI)
which asks me "E-Mail:" on the commandline (!) without any context,
which e-mail address is wanted and for what it is used. I assume it's
the e-mail address used in the GOG account, but that UI is
inacceptable. (Didn't write a bug report for that. Just uninstalled
it. But this one has security impact.)

		Regards, Axel

Hi Axel,

Le 03/02/2021 02:09, Axel Beckert a écrit :

Ah yes, that is a good point!

Agreed, we can’t trust the network.

Hmm, right, I must just be unlucky and always hit the reCAPTCHA... The
GUI pops up then. Perhaps it would be useful to provide an option to
always use the GUI.

Regards,

Stephen