Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bogusly large chunk sizes may cause assert #2379

Closed
mbgrydeland opened this issue Jul 31, 2017 · 5 comments
Closed

Bogusly large chunk sizes may cause assert #2379

mbgrydeland opened this issue Jul 31, 2017 · 5 comments

Comments

@mbgrydeland
Copy link
Contributor

mbgrydeland commented Jul 31, 2017

A client sending a request body using chunked encoding may cause the
Varnish daemon to assert and restart if sending a chunk size larger
than a signed 64-bit signed integer can hold.

This has been assigned VSV00001.

For more information see this page:

http://varnish-cache.org/security/VSV00001

@mbgrydeland mbgrydeland self-assigned this Jul 31, 2017
@mbgrydeland mbgrydeland changed the title Placeholder issue - please do not touch Bogusly large chunk sizes may cause assert Aug 2, 2017
hermunn pushed a commit that referenced this issue Aug 2, 2017
This fixes a denial of service attack vector where bogusly large chunk
sizes in requests could be used to force restarts of the Varnish
server.

This is Varnish Security Vulnerability VSV00001

For more information visit: https://varnish-cache.org/security/VSV00001

Fixes: #2379
hermunn pushed a commit that referenced this issue Aug 2, 2017
This fixes a denial of service attack vector where bogusly large chunk
sizes in requests could be used to force restarts of the Varnish
server.

This is Varnish Security Vulnerability VSV00001

For more information visit: https://varnish-cache.org/security/VSV00001

Fixes: #2379
hermunn pushed a commit that referenced this issue Aug 2, 2017
This fixes a denial of service attack vector where bogusly large chunk
sizes in requests could be used to force restarts of the Varnish
server.

This is Varnish Security Vulnerability VSV00001

For more information visit: https://varnish-cache.org/security/VSV00001

Fixes: #2379
@apoleon
Copy link

apoleon commented Aug 3, 2017

Hi,

we maintain an older version of varnish, 3.0.2. According to your security advisory versions up to 4.0.0 are not affected. However in 3.0.2 there is a similar code fragment in bin/varnishd/cache_fetch.c, function fetch_number

cl = (ssize_t)cll;
if((uintmax_t)cl != cll) /* Protect against bogusly large values */
return (-1);
return (cl);

I wonder whether the if condition should be extended to if (cl < 0 || (uintmax_t)cl != cll) as well in this case? Or can someone confirm that the vulnerability cannot be triggered by this function.

@dridi
Copy link
Member

dridi commented Aug 3, 2017

I would recommend taking the test case from 09731b2. Back-port it to your fork's varnishtest syntax and see whether you are vulnerable.

@mbgrydeland
Copy link
Contributor Author

It is true as was pointed out that the faulty line was there also before version 4.0.1. But what was new in 4.0.1 was that the code path containing the faulty line was exposed to client requests. Before 4.0.1, this code could only be run through backend fetches. While stil a bug, problems related to backend traffic are not considered a security problem, thus the advisory is only issued for version 4.0.1 and later.

@carnil
Copy link

carnil commented Aug 4, 2017

@mbgrydeland: CVE-2017-12425 has been assigned for this issue.

@apoleon
Copy link

apoleon commented Aug 5, 2017

Thank you both for your advice and comments.

dmatetelki pushed a commit to dmatetelki/varnish-cache that referenced this issue Mar 14, 2019
This fixes a denial of service attack vector where bogusly large chunk
sizes in requests could be used to force restarts of the Varnish
server.

This is Varnish Security Vulnerability VSV00001

For more information visit: https://varnish-cache.org/security/VSV00001

Fixes: varnishcache#2379
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants