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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
