3 ms·

Size. A payload of one million characters should probably be rejected without further analysis. As well as checking the total size, it is good to check the

Size. A payload of one million characters should probably be rejected without further analysis. As well as checking the total size, it is good to check the sizes of the parts. Another thing to check, that is often overlooked, is Quantity. Every loop should have a limit. There should be no unbounded object allocation. Usually, it's not the big things that get you but the sheer number of small things. For example, a 20 MB email with 4 million empty attachments: https://snyk.io/blog/how-to-crash-an-email-server-with-a-single-email/ https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin... Further examples that affected ClamAV and SpamAssassin: https://blog.clamav.net/2019/11/clamav-01021-and-01015-patches-have.html https://blog.clamav.net/2019/11/clamav-01021-and-01015-patch... http://mail-archives.apache.org/mod_mbox/spamassassin-announce/201912.mbox/%3C4867fdb1-eaba-98c9-661a-9b5cd974d5c1@apache.org%3E http://mail-archives.apache.org/mod_mbox/spamassassin-announ...

dkersten 7y ago
> Every loop should have a limit. There should be no unbounded object allocation. I’ve recently created some mini-languages (DSL’s) for everyone users to control various software and I’ve found that using a synchronous transformational language[1], which has no unbounded loops (or anything) and is therefore guaranteed to complete, and which runs in a stop-the-world fashion (ie each invocation acts as if atomic, whether it actually is or if implementation tricks like transaction rollback + retries are used) makes it easier both to develop and for end users especially ones who aren’t programmers. I’m a huge fan of this approach for correct and secure software. [1] https://en.m.wikipedia.org/wiki/Synchronous_programming_language https://en.m.wikipedia.org/wiki/Synchronous_programming_lang...
arethuza 7y ago
The only problem with this approach that I have encountered is that is requires defining fairly arbitrary limits that are either so small that some user will inevitably run into them or so large that you're not getting as much protection as you think. NB I don't know what the answer to this is, but pretty much any time a system I have been involved with contains a "reasonable" limit then people want more than that pretty quickly!
- JadeNB 7y ago
  > The only problem with this approach that I have encountered is that is requires defining fairly arbitrary limits that are either so small that some user will inevitably run into them or so large that you're not getting as much protection as you think. Would an answer be to have limits that are tunable? I.e., something like "Attachment limit exceeded. Enter new temporary attachment limit for re-scanning: _____"?
- jorangreef 7y ago
  The problem you describe is not actually specific to this approach, the same would apply to any Size check, or any limit in general. In fact, I think the problem is less relevant to a Quantity check, where an order of magnitude headroom above normal usage goes a long way, more so than a Size check. For example, do you know of people who receive 10,000 attachments per email? This limit would be far and away above any reasonable usage and yet provide decent protection at the same time.
  - arethuza 7y ago
    It's essentially the arbitrariness of that 10,000 number that I'm queasy about. e.g. When I thought of a "reasonable" maximum number of attachments on an email I'd probably say 64.
    - xyzzy_plugh 7y ago
      It can be a random number between 64 and 10000, inclusive, the arbitrariness of it is the point: there is a bound; the (loop/size/whatever) is not unbounded.
      - arethuza 7y ago
        But that's just from the 'security' perspective - if it is a low number then users are likely to hit it and complain, and for bug tracing I suspect everyone would want the number to be constant.
    - jorangreef 7y ago
simonw 7y ago
One of the things I learned working on software with millions of users is that ANYTHING that does not have a limit will eventually be abused by someone - often not even maliciously. Got a feature that lets users add multiple additional options? Someone will use it to add 10,000 options, and now pages which display them in a <select> widget will slow to a crawl.
- jorangreef 7y ago
  "Anything that does not have a limit will eventually be abused by someone." There should be a law named for this. What about Limit's Law?
  - coldacid 7y ago
    The Law of Limits would probably be better. X's Law only really works well as a name if X is itself a name. Law of X is better when X is a topic.
WalterBright 7y ago
I put limits on things in the D compiler. One thing is certain, I'll get a bug report because the limit was exceeded. Who'd have thought programs would be built with a hundred thousand symbols in them? Or that 65,000 lines in a source file isn't enough?
- machinecoffee 7y ago
  >Or that 65,000 lines in a source file isn't enough? I would hope that was from auto generated code somehow..?!!
  - WalterBright 7y ago
    I've long since stopped caring why people do that, I just fix it so their programs work :-)
someguyorother 7y ago
> Every loop should have a limit. There should be no unbounded object allocation. See also total functional programming, which applies the same logic to runtime.

dkersten 7y ago

> Every loop should have a limit. There should be no unbounded object allocation. I’ve recently created some mini-languages (DSL’s) for everyone users to control various software and I’ve found that using a synchronous transformational language[1], which has no unbounded loops (or anything) and is therefore guaranteed to complete, and which runs in a stop-the-world fashion (ie each invocation acts as if atomic, whether it actually is or if implementation tricks like transaction rollback + retries are used) makes it easier both to develop and for end users especially ones who aren’t programmers. I’m a huge fan of this approach for correct and secure software. [1] https://en.m.wikipedia.org/wiki/Synchronous_programming_language https://en.m.wikipedia.org/wiki/Synchronous_programming_lang...

arethuza 7y ago

The only problem with this approach that I have encountered is that is requires defining fairly arbitrary limits that are either so small that some user will inevitably run into them or so large that you're not getting as much protection as you think. NB I don't know what the answer to this is, but pretty much any time a system I have been involved with contains a "reasonable" limit then people want more than that pretty quickly!

JadeNB 7y ago
> The only problem with this approach that I have encountered is that is requires defining fairly arbitrary limits that are either so small that some user will inevitably run into them or so large that you're not getting as much protection as you think. Would an answer be to have limits that are tunable? I.e., something like "Attachment limit exceeded. Enter new temporary attachment limit for re-scanning: _____"?
jorangreef 7y ago
The problem you describe is not actually specific to this approach, the same would apply to any Size check, or any limit in general. In fact, I think the problem is less relevant to a Quantity check, where an order of magnitude headroom above normal usage goes a long way, more so than a Size check. For example, do you know of people who receive 10,000 attachments per email? This limit would be far and away above any reasonable usage and yet provide decent protection at the same time.
- arethuza 7y ago
  It's essentially the arbitrariness of that 10,000 number that I'm queasy about. e.g. When I thought of a "reasonable" maximum number of attachments on an email I'd probably say 64.
  - xyzzy_plugh 7y ago
    It can be a random number between 64 and 10000, inclusive, the arbitrariness of it is the point: there is a bound; the (loop/size/whatever) is not unbounded.
    - arethuza 7y ago
      But that's just from the 'security' perspective - if it is a low number then users are likely to hit it and complain, and for bug tracing I suspect everyone would want the number to be constant.
  - jorangreef 7y ago

simonw 7y ago

One of the things I learned working on software with millions of users is that ANYTHING that does not have a limit will eventually be abused by someone - often not even maliciously. Got a feature that lets users add multiple additional options? Someone will use it to add 10,000 options, and now pages which display them in a <select> widget will slow to a crawl.

jorangreef 7y ago
"Anything that does not have a limit will eventually be abused by someone." There should be a law named for this. What about Limit's Law?
- coldacid 7y ago
  The Law of Limits would probably be better. X's Law only really works well as a name if X is itself a name. Law of X is better when X is a topic.

WalterBright 7y ago

I put limits on things in the D compiler. One thing is certain, I'll get a bug report because the limit was exceeded. Who'd have thought programs would be built with a hundred thousand symbols in them? Or that 65,000 lines in a source file isn't enough?

machinecoffee 7y ago
>Or that 65,000 lines in a source file isn't enough? I would hope that was from auto generated code somehow..?!!
- WalterBright 7y ago
  I've long since stopped caring why people do that, I just fix it so their programs work :-)

someguyorother 7y ago

> Every loop should have a limit. There should be no unbounded object allocation. See also total functional programming, which applies the same logic to runtime.