Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 30 Apr 2016 11:52:50 +0200
From: Salvatore Bonaccorso <>
Subject: Re: CVE Request: vtun: denial-of-service: high CPU usage after SIGHUP


On Wed, Apr 27, 2016 at 05:58:00PM -0400, wrote:
> Hash: SHA256
> >
> Can you describe how this crosses a privilege boundary?
> >> When you send a SIGHUP to a vtun client process and it cannot connects
> >> to the remote server, vtun try to reconnect without sleep between each attempt.
> >> In result, the vtun process uses lot of CPU, and write to syslog without limit.
> Is there an important way in which this differs from "The vtun client
> is not installed. The attacker simply writes their own program to
> reconnect without sleeping and make many syslog calls"?
> For example: does vtun's resource consumption belong to the root
> account in a common scenario, but SIGHUP is accepted from an
> unprivileged user? Are different unprivileged users successfully
> sending SIGHUP to one another's vtun client processes? Do you mean
> that there's a potentially common attack pattern in which a
> man-in-the-middle attacker intentionally blocks connections to the
> remote server in order to trick the victim into sending a SIGHUP, and
> (in some sense) this man-in-the-middle attacker is thereby able to
> trigger the excessive resource consumption?
> Sometimes there are CVE IDs for "a client application inadvertently
> starts launching a network DoS attack" but this is typically only in
> cases where someone can send forged packets to the client application
> in order to start the attack.

You are right -- I cannot think of a situation (or seems hard to find
a realistic example) right now where this issue would cross a
privilege boundary, and thus might just be considered as bug, but not
a vulnerability.

Thanks for your feedback, I'm fine to not have assigned an identifier
for this.


Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ