[Development] MaintenanceTool and/or InstallerFramework horribly insecure?

[Konrad Rosenbaum]

Hi Kai,

thanks for looking into this.

One more discovery: the Qt Account credentials are also stored with 0557
permissions - they really should be 0600 for the file and 0700 or 0755
for the directory. Credential storage permissions should always be
overridden anyway and not be left to some automatic mechanism, like umask.

In case this is of interest: my umask is 0022.

In an ideal world it would even ask permission to store credentials in
the first place, even better it could use a system service for storing
them securely (kwallet, Gnome Keyring, Windows credentials store, ...).
Wishful thinking...


On 2020-05-23 06:13, Kai Köhne wrote:
> thanks for the report. Volker forwarded it to the qt-project security mailing list. Feel free to send further security related issues there.
Thanks & I put it on Cc now.
>> When I call MaintenanceTool to install another version of Qt it wants to sudo into root when it starts to download Qt components.  It still asks
>> for the sudo password if I quit while selecting components!

> I assume you start a new installer here (not the MaintenanceTool of an existing installation). Is that really during the download, or in the extractio phase? Can you maybe create a bug report and attach the installation log (you can start the installer with --verbose)?

No, that was an existing MaintenanceTool, which first updated itself and
then restarted into normal updates. It switches into root as soon as you
leave the package selection screen.

Regardless of variant: it should never set insecure permissions, it
should correct insecure permissions when it encounters them on crucial
files/directories and it should not elevate its privileges unless
absolutely necessary - and then it should ask. (According to RFC2119
this "should" should really be "must"... ;-) )

BTW: it still has the bug that the default selection is "remove All" -
after discovering those bugs I granted that wish, killed it and
installed from source.

So sadly no traces of MaintenanceTool or its logs are left on this
machine. As far as I could see at the time there were no usable hints
about this directory or permissions in this log, I'm not sure about
starting the root process. If I have excessive amounts of time next
week, I might retry this on my work machine - but I really have strong
feelings about exposing it to such security nightmares.

>> Worse, if I normally have sudo set to NOPASSWD then it does not even ask, it just switches!
> This is now tracked in https://bugreports.qt.io/browse/QTIFW-1794

Thanks!


As I wrote in my first mail: I highly recommend TQtC invests in a
security audit for this tool - it is a crucial component that
potentially exposes a lot of paying customers. The presence of bugs like
the above seems to suggest that there may be more bad practices hidden
inside. E.g. is the network transfer really secure against MITM? From my
own experience: to have an audit performed on your code can be a pain in
the behind, but it is worth it - the code is significantly improved.


    Konrad



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200523/017ac67a/attachment.sig>