Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 7 Jul 2020 11:11:31 +0200
From: Matthias Gerstner <>
Subject: veyon: Veyon uses fixed logfile paths in /tmp in versions prior

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 ) );



  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].




Matthias Gerstner <>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.