Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 602550

Summary: <net-misc/peervpn-0.044-r2: root privilege escalation
Product: Gentoo Security Reporter: Michael Orlitzky <mjo>
Component: VulnerabilitiesAssignee: Gentoo Security Audit Team <security-audit>
Status: RESOLVED FIXED    
Severity: trivial CC: zmedico
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard: ~1 [noglsa]
Package list:
Runtime testing required: ---

Description Michael Orlitzky gentoo-dev 2016-12-13 16:06:27 UTC
The ebuild for peervpn does,

  fowners ${PN}:${PN} /var/log/${PN}

after which the "peervpn" user controls the contents of /var/log/peervpn. In particular, he can overwrite /var/log/peervpn/peervpn.log with a symlink to any file on the system. The init script then does,

  start_post() {
      chown "${user}":"${group}" "${logfile}"
  }

which will call "chown" on the symlink. In that manner, the peervpn user can take ownership of any file on the system.
Comment 1 Zac Medico gentoo-dev 2016-12-13 17:13:07 UTC
In peervpn-0.044-r1 it's fixed to use chown --no-dereference:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=012351c00a0b366bbf052222306cf939e9471db1
Comment 2 Michael Orlitzky gentoo-dev 2016-12-13 17:29:34 UTC
The --no-dereference flag avoids the issue for symlinks, but not for hardlinks. Fortunately, on newer Linux kernels, there are hardlink restrictions governed by the fs.protected_hardlinks sysctl (default: 1) that prevent me from creating the link to a root-owned file in the first place:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7

On the other hand... why chown the log file at all? It will be created by the peervpn user/group in a directory that it owns, so I think it will be owned by $user:$group anyway.
Comment 3 Michael Orlitzky gentoo-dev 2016-12-13 17:40:34 UTC
Crap, those defaults were changed. You can see now that those protections are OFF by default in the vanilla kernel:

  https://github.com/torvalds/linux/blob/master/fs/namei.c

We have a patch (1510_fs-enable-link-security-restrictions-by-default.patch) that turns them back on in gentoo-sources and hardened-sources.
Comment 4 Zac Medico gentoo-dev 2016-12-13 17:44:23 UTC
(In reply to Michael Orlitzky from comment #2)
> On the other hand... why chown the log file at all? It will be created by
> the peervpn user/group in a directory that it owns, so I think it will be
> owned by $user:$group anyway.

The thing is, start-stop-daemon creates the logs owned by root, because it starts peervpn as root (which later drops privileges). I suppose we could simply allow the log to be owned by root.
Comment 5 Zac Medico gentoo-dev 2016-12-13 17:56:40 UTC
Removed the chown call in peervpn-0.044-r2:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f36646ec19b50b45cbf6def47e8e34ac2237b3c8
Comment 6 Thomas Deutschmann gentoo-dev Security 2016-12-13 18:08:23 UTC
From my understanding /var/log/${SVCNAME}/${SVCNAME}.log is only used by s-s-d because the application itself doesn't create any logs nor provides a real daemon. I.e. peervpn always run in foreground and that's our solution to save the output.

So if peervpn itself doesn't write to that log file, the peervpn user/group doesn't need access to that file, right? And maybe not even to /var/log/peervpn folder ...

Am I wrong and peervpn needs access to that file and folder?
Comment 7 Zac Medico gentoo-dev 2016-12-13 18:32:25 UTC
(In reply to Thomas Deutschmann from comment #6)
> From my understanding /var/log/${SVCNAME}/${SVCNAME}.log is only used by
> s-s-d because the application itself doesn't create any logs nor provides a
> real daemon. I.e. peervpn always run in foreground and that's our solution
> to save the output.
> 
> So if peervpn itself doesn't write to that log file, the peervpn user/group
> doesn't need access to that file, right? And maybe not even to
> /var/log/peervpn folder ...

Right, so that's why peervpn-0.044-r2 removes the chown calls.
Comment 8 Thomas Deutschmann gentoo-dev Security 2017-01-09 00:58:45 UTC
Public via https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f36646ec19b50b45cbf6def47e8e34ac2237b3c8

Should be all done now, tree is clean, no GLSA required because package was never stable.