[squid-users] Survey on assertions: When the impossible happens

[Amos Jeffries]

On 28/02/2016 7:52 a.m., joe wrote:
> right Asserts is the best choice for critical function im with you

define "critical". It is not always obvious.


> on that in the other hand some function its not critical to have 
> asserts just trace() or some other function to notify the cache log 

Now your cache.log / syslog fills with many KB per request as someone
DDoS your proxy with just a few bytes of input per request. That is
called a DoS amplifier.

Whole machine (not just Squid) crashes with disk space exhausted - DDoS
successful after sending only a few dozen MB or GB of traffic. Keep in
mind that DoS are reaching TB of traffic quickly, and the machine which
dies may not be Squid but a separate logging server, and the nature of
the crash may leave no clear evidence pointing back at the problem being
Squid or the small-DDoS.

There is no simple "do this" action to solve all _impossible_ situations.

People like yourself jumping to quick solutions, or baseing them on
outdated/wrong ideas without thinking the consequences over is why the
topic of letting admin have any control at all is controversial in the
first place.


> for warning and do not halt just keep running its choice of what
> function need to have asserts or if the function not critical just
> notification will do as of compiled code but for testing in lab some
> function still has bad bug asserts is good for it don't know if other
> guys agree so....

If that were true no assertions would ever occur in production machines.
We could thread the code with them and never worry. Perfect code and all
that.


The truth is as Alex said. That assertion happening is because an
"impossible" situation happened in production. If it did happen in
testing *at all* the dev changing the code would have removed the
assertion and added code to handle that case.
 It simply did not happen in testing. The dev thought it was impossible,
but had just enough paranoia to add an assert to bring attention to it
if it did.


This past weeks CVE is a very good example of that.

Squid has rather extensive controls over the size of messages it received:

 * request_header_max_size and reply_header_max_size place an absolute
limit of 64KB or less on any mesage *total* mime header size
  - multiple lines and surrounding syntax bytes all less than 64KB total.

 * each individual line of that header must also be within 64KB if by
chance the admin chooses to raise that limit.

 * these are carefully checked and enforced on arrival of data from all
network inputs *and* from disk cache.
 - in case someone fiddled with the disk entry. We have seen that happen.

Reasonable to assume that its impossible to receive a HTTP message with
single header line >64KB, yes?
 Well, no. CVE-2016-2569 still happens. A single message header line can
reach far more than 64KB. The proof is an assertion.

Oh, and handling that situation instead of assert/crash and restarting
makes at least 3 other impossible situations / asserts happen later on
for Squid (well, 3 that we know of so far).


PS. Can you use some punctuation in future please.

Amos