[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160427215800.7EB1B72E003@smtpvbsrv1.mitre.org>
Date: Wed, 27 Apr 2016 17:58:00 -0400 (EDT)
From: cve-assign@...re.org
To: carnil@...ian.org
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Request: vtun: denial-of-service: high CPU usage after SIGHUP
-----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.
- --
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJXITVqAAoJEHb/MwWLVhi2NQwP/37KVYfIc7/Z173IQyaV7NEh
i5ZFzn36q56XXT80nuMIYGH/SuXffuhou4YEUXscYf7FBC4/TgQKP6sy1UMcjmQ0
CawCkWIk9PTA98GvddXknMg2KfDwbM3p0UxzxYpzDT/jUflaaB9HOSruCElv++gu
ZlE4CF7WMgg4tmKjk7pK5IyoDkMX9a9TjJAxbT0hISUwjhVMrZNQsXQh84fby2iZ
BNnmFbWb7igvNKkxF+s2RN+8OPKIo4K0NWii+a53HcM3pxisvP7ras20FSMBJv5H
lmwvYC7NFYSMRCByp9G197RpBrOhQSUQMLgKhojHSW8LDfag/OHYH1g/5HGghnzp
dul8/kn8DsmH2oC2GnE8QaNkzhozp9ustIvn4xaPIi676I+nIG16XlRYDNWNVICc
OyxMegvBFRu779jXUDaIWUF4g8T+nrGq5EuIQI03LxczCo0Vr4WAd+uzSVZ7icWq
M7Qgk99dH7bfXVDQCfP1sz60wohuT03oUjjQwcorABLJoGB9BnAzUiWt6e/g0BG8
6fv648XOxzZO7dC516B4nkq5JesIjbmlQzcbA+vzVwB/4iRqMs5QiNRNjrvHghuc
JooYBuSoiTDBJ6C77/O/M9AdTA2fGa5/COAHiEsV/CuHJS2T9eRQTyVfdKDlMRdE
IN85CZw1R11EdMmLzsj+
=huSO
-----END PGP SIGNATURE-----
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.
