[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Re: CVE Request: vtun: denial-of-service: high CPU usage after SIGHUP
From:       Salvatore Bonaccorso <carnil () debian ! org>
Date:       2016-04-30 9:52:50
Message-ID: 20160430095250.GA19211 () eldamar ! local
[Download RAW message or body]

Hi,

On Wed, Apr 27, 2016 at 05:58:00PM -0400, cve-assign@mitre.org wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> > https://bugs.debian.org/818489
> 
> 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.

Regards,
Salvatore
[prev in list] [next in list] [prev in thread] [next in thread]