oss-sec mailing list archives
veyon: Veyon uses fixed logfile paths in /tmp in versions prior v4.4.0
From: Matthias Gerstner <mgerstner () suse de>
Date: Tue, 7 Jul 2020 11:11:31 +0200
Hello list, during a review [1] of the veyon classroom management software [2] for inclusion on openSUSE Tumbleweed I noticed that it uses fixed logfile paths in /tmp in various code components. # Issue Description I reported the issue for the `veyon-configurator` component to upstream as follows: I noticed that by default a fixed logfile path is used by veyon-configurator. The path is /tmp/VeyonConfigurator.log. It's a bit hard to find where this directory and file are actually assigned. - There is core/src/Logger.h:57: static constexpr const char* DefaultLogFileDirectory = "$TEMP"; - $TEMP is expanded to `QDir::tempPath()` in `Filesystem::expandPath()` - QDir::tempPath on Linux uses either the environment variable `$TMPDIR` or the hardcoded '/tmp' path as a fallback. - in `Logger::initLogFile()` we finally have: ``` m_logFile = new QFile( logPath + QString( QStringLiteral( "%1.log" ) ).arg( m_appName ) ); openLogFile(); ``` and ``` void Logger::openLogFile() { m_logFile->open( QFile::WriteOnly | QFile::Append | QFile::Unbuffered | QFile::Text ); m_logFile->setPermissions( QFile::ReadOwner | QFile::WriteOwner ); } ``` This means that veyon-configurator will use whatever file is found at /tmp/VeyonConfigurator.log and append its logfile data there. If an unprivileged local user places a symlink there then this symlink will be followed unless the Kernel symlink protection is in place. This is the case for openSUSE by default at least. When following symlinks succeeds, then this attack can be used to corrupt arbitrary files in the system. Even when symlink protection is in place then a user can prepare a regular file at /tmp/VeyonConfigurator.log with arbitrary content. This has the following security effects: - any prepared content will remain at the beginning of the logfile and could confuse an admin / developer. - although in `openLogFile()` the mode of the file is set to 0600, the attacker is still the owner of the file and can access the logfile contents and possibly sensitive information. - since the attacker is the owner, he can replace the complete logfile information to mislead an admin / developer. A quick look showed that not only veyon-configurator is affected but all other Veyon components that use the Logger class. For example there's also /tmp/VeyonServer.log and /tmp/VeyonService.log. # Bugfix Upstream fixed the root cause of the issue based on a patch suggestion I sent them in a new release v4.4.0. There was an intermediate insufficient bugfix [4] that was amended by follow-up commits [5], [6]. # Timeline 2020-06-08: I reported the issue to the upstream main developer 2020-06-09: Upstream immediately published a bugfix [4] that was insufficient, however. 2020-06-12: Upstream incorporated better fixes, based on a suggestion I provided them [5], [6]. [1]: https://bugzilla.suse.com/show_bug.cgi?id=1172318 [2]: https://veyon.io/ [3]: https://bugzilla.suse.com/show_bug.cgi?id=1172659 [4]: https://github.com/veyon/veyon/commit/55440755d59362e721504ef28f680488ef40c85b [5]: https://github.com/veyon/veyon/commit/131d9a35208e5b6a639fc2757a0b7f74922c537f [6]: https://github.com/veyon/veyon/commit/76497b54b30ed66bf5a3dc9f413509dc6dd371b1 Cheers Matthias -- Matthias Gerstner <matthias.gerstner () suse de> Dipl.-Wirtsch.-Inf. (FH), Security Engineer https://www.suse.com/security Phone: +49 911 740 53 290 GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Felix Imendörffer
Attachment:
signature.asc
Description:
Current thread:
- veyon: Veyon uses fixed logfile paths in /tmp in versions prior v4.4.0 Matthias Gerstner (Jul 07)