VSV00002 Data leak - '-sfile' Stevedore transient objects

[Poul-Henning Kamp]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

VSV00002 Data leak - '-sfile' Stevedore transient objects
=========================================================

CVE-2017-8807

Date:	2017-11-15

A wrong if statement in the varnishd source code means that synthetic
objects in stevedores which over-allocate, may leak up to page size of
data from a malloc(3) memory allocation.

In a unpredictable percentage of the cases where this condition
arises, a segmentation fault will happen instead.

All the following conditions are required to trigger the problem:

* A `-sfile` or `-spersistent` stevedore must be configured

* A synthetic object must be created in `vcl_backend_error{}`

* The synthetic object ends up in the `file` or `persistent` stevedore.

For the third condition can arise in two different ways:

* The stevedore named `Transient` is configured as `-sfile` or `-spersistent`
  (The default is `-smalloc`)

* The default stevedore is `-sfile` or `-spersistent` and the synthetic
  object is given a TTL larger than the `shortlived` parameter
  (default: 10 seconds.)

It is not inconceiveable that an attack can provoke this situation
on vulnerable varnishd instances, where the leaked memory contains
confidential data and therefore we have classified this as a security
vulnerability.

Mitigation is possible from VCL or by updating to a fixed version
of Varnish Cache.

Versions affected
- -----------------

* 4.1.0 to 5.2.0

Versions not affected
- ---------------------

* All releases up to but not including 4.1.0
* Varnish Cache Plus from Varnish Software.

Fixed in
- --------

* 4.1.9 and forward
* 5.2.1 and forward

Mitigation from VCL
- -------------------

Do not configure the Transient storage with `-sfile` or `-spersistent`
stevedores.

Do not assign ttls longer than the parameter `shortlived` in
`vcl_backend_error{}`

Source code fix
~~~~~~~~~~~~~~~

	https://github.com/varnishcache/varnish-cache/commit/176f8a075a

Thankyous and credits
~~~~~~~~~~~~~~~~~~~~~

Github user @shamger submitted a fix for the segmentation fault issue.

Carlo Cannas of Altervista.org pointed out that the data-leak was
a security issue.

Martin and Espen from Varnish Software has done most of the work
on this security incident.

And yes: I apologize for getting the code wrong in the first place.

*phk*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJaC/66XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0MzU3NTkyM0I4RTExRDcwM0M2NjU1NDA4
RTVGNDRCQTY4RTY4OUM1AAoJEI5fRLpo5onFEBEP/iWoBJzZosNLJsW0o2+EwQZ7
MiZCrD6GV/Bte6mlgARjEkULOzyugZltmbK9mH8g5MoNMhy/nxVS5L7/NWACk7BM
TOd34oq2beSX4E+YTHJjtz1t38rl9U5nbSMt/MW6fwUEjdsLk7v6ZUtLoPKyAf3E
9/yNGxbjpss6Zvh2QA7g1B5mKrsP/hAzIIbFc6aUIDdcckiHnYKM1JZxLJzx6kBI
KbeDU95OtuZnM5vFbrSLd8AraYm2gYsMub0A4QAilkNCbPDit1C17YLByotvFbyu
7V0F04oyBy+FhxI4SfvXJ/8eSWjIxPXO/HnXTBpzIhxujH8bZ4rJvhI/AnpkTHQ+
J6ayFoc4sapgWmpHiXuhjypRKQwIMNohtyPxP79Zo96/v0haBGv0529Y9e+G0CKq
pNQv1WxfYoq9r2xMYGfo90sHkgOaDajIiSo8hqXwR8Qr2UNSHrZ2MdguUfpSo395
NLVsRDeZIUSvX+1ciRCibFV27BdlPLt7WW4hMOozXBPbCo2W11iuxLv3h1IgS9q4
BDBC6Fg0kZfQyp3XDKtZ8BRf4e2dOOOdl76213ryH9hF8c1/o4PcFGZVgcVfGJ/2
pmGhhWrhXNE3lnv1i2TPRtf3ABLCBJCCQwCHVKUPscDrDKz+O/LjghhSpmWjlda0
evMCWKZTOJP/MoVTfHVE
=g5Hx
-----END PGP SIGNATURE-----

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.