Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 14 Jun 2016 08:14:30 -0400 (EDT)
From: cve-assign@...re.org
To: tobias@...eckmann.org
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Request for Denial of Service in pacman 5.0.1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> The package manager of Arch Linux, pacman, is vulnerable to a denial of
> service attack based on signature files. This issue is located in libalpm
> and therefore affects any other frontend
> 
> While an endless loop on itself is no security issue per-se

We assign CVE IDs to infinite loops in libraries, as long as a real or
plausible library-using application runs unattended, and presents an
attack surface in which the loop may be triggered by not-fully-trusted
input.

Use CVE-2016-5434 for this libalpm vulnerability.

(For example, someone may plausibly use libalpm as part of a web
application that receives packages with signatures from authors and,
after validity checks, hosts those packages for public download.)


> such a
> crafted file might trick the end-user to disable signature verification
> to get his updates installed. This, on the other hand, would open up
> possibilities for malicious packages to be installed.

Maybe, but this would not, by itself, be a reason to assign a CVE ID
unless the package manager suggested that course of action, e.g., a
dialog stating "A signature-verification process is running slowly.
Terminate that process and disable all future verification? [y/N]."
For example, if there were a signature-verification infinite loop that
only affected a GUI package manager, without that type of dialog, then
a CVE ID seems unlikely. First, it's unclear whether there are many
end users who have the expertise to determine that a loop is related
to signature verification, but also would jump to the conclusion that
disabling signature verification was a reasonable solution to their
immediate problem. More generally, any DoS bug in any package manager
might trick a non-expert end user into not bothering to install new
packages, and instead leaving old vulnerable packages installed
permanently. That is arguably a security impact, but it seems much too
indirect, so we don't want to assign CVE IDs to 100% of DoS bugs in
all package managers.

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

iQIcBAEBCAAGBQJXX/SSAAoJEHb/MwWLVhi2koIP/0JPOJFLF7Fs582+6wD8RvFD
PsTEcWc5X/80uL0yGREFI8Hvm1n7YBuINexgTWoEMfwHPoxvrwtUY2aNDrhAY77X
SnBobg5B4mrFDGZh0VcmU0vYhriwCx8KDTWF5AfVyQZ4mjmru2MBxF5KyQEQuBuY
SqhohAlc856KjO0vns17Kw284Eqs34iwQXIZ3nxSwBkJhfrokRaMunA3jGawdJku
BjQi8RK0TXir2wdyGA95ySIQP6Z5HlsaCjoUa+miuA8Fu7TITBCo31aKxEHfrIFn
F3zai0bxXz0jaly1TWz4uyAn2P7WL24V2rLlmFIH0z8+tzEKiIiaXjIlzz3JasKp
0yTI8uUSvUu61WIcBSQcAwRmTYTZ+Rz8IYVsbAS8pnWysXwySBReEnR/rkaKzLX+
qbREp2oMEoAiEjDAZMM20ObuXzn7NW2S/sLx9jMTdr8OJW7n567SBCO31IbN5Inu
lopHPR8d5sA3EYL17MGfgkLH9DdHbeZaxDPw41smmNdA04G//bZFChgab02H8uai
DLWOeaiS1m1zmGpRWCvcS4xm55G1kEdTfJVvj45w9G63BZZuYqzgun1ejG3eTIfz
zw4Ot7TzyZ7icGAWbrb68eBCisHmzNM7hVHuhRlj5EUuGsrAVHD5fgUGDaV1wvC/
6XwLFN7kxp5XkLVuq/V3
=UySW
-----END PGP SIGNATURE-----

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