Re: On memory-leaks as security problems

From: James Fuller via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 7 Jan 2021 11:54:38 +0100

it is good to try to put some boundaries/rules in place but ultimately
(esp for corner cases) I am fine with a circular caveat stating that a
security issue are those bugs which the curl security team has denoted
as a security problem.

The judging of memory leaks and c, being what it is ... maybe a
tractable first step is to tag issues with security related meta data
(reproducibility, leak impact/size, frequency).

Jim

On Thu, 7 Jan 2021 at 11:26, Stefan Eissing via curl-library
<curl-library_at_cool.haxx.se> wrote:
>
> Daniel,
>
> I'd appreciate if there were a definition, since in my work at apache security, we come across issues of categorisations often as well.
>
> D: is very clear: if someone mis-uses the API, it may trigger an update in documentation, but it is not a security issue. Same with a mis-configuration of the https server.
>
> C: if there is an alternate way of using the curl API (and alternate configuration of the httpd server) that mitigates the problem, it should not be a security issue (of libcurl or httpd, maybe of the overall bundling product, like an IoT device).
>
> A+B: the tricky area of DoS. It is tricky, because it is often not clearly documented what the guarantees and limits are.
>
> Speaking about httpd: it cannot defend against all sorts of DoS attacks. A powerful attacker can spam us with valid requests, making the server almost useless to others. So, the argument often goes: "But I can do that attack from my laptop alone!" Which is a good indicator that we need to make it harder and have a security issue. But it is not defined how many laptops we define the server to be safe against (nor would that make sense as many other parameters are in play).
>
> Speaking of libcurl: if libcurl guarantees that you can contact any malicious server and no harm will come to the hosting application, then you A+B are security issues. But if there are limits in this protection (e.g. where the app has to take care, for example huge response sizes), maybe writing a definition of those might make things more clear.
>
> I should bring that to the httpd dev list.
>
> Cheers, Stefan
>
> > Am 07.01.2021 um 09:59 schrieb Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>:
> >
> > Hi friends,
> >
> > In the curl security team, we have a discussion going on with someone who wants a set of memory-leaks we fixed in the past to be highlighted and reported as "security problems". This, because a memory leak in a long-running process may eventually lead to a Denial-of-service where the application can't fulfill its purpose anymore when it runs out of memory.
> >
> > I've tried to find existing established rules and guidelines for when other projects and software in general consider memory-leaks to be security problems and when not, but I've found no establishled "rules" to guide me. So I'm here now, to learn from the curl community!
> >
> > For me it is very important to properly and accurately recognize and alert users about security problems in curl. It is also very important to NOT report issues that aren't actual security problems as such, as security problems cause much more friction and upgrade "churn" out there and we don't want that to happen without proper motivation.
> >
> > (I'm talking of memory leaks as in failure to free a local resource/memory region, without that resource being used ever again.)
> >
> > What would you say about this attempted checklist?
> >
> > When is a memory-leak in libcurl a security issue?
> >
> > A) If the memory leak is so large that it is likely to cause a memory related failure in near-term for the application. This would mean in the tens to hundreds of kilobytes, at least.
> >
> > and/or
> >
> > B) If a malicious server can willingly trigger the memory leak, and even more so if it can affect the size and rate of the leak allowing the remote party to effectively control the point of the DOS.
> >
> > A memory-leak is *not* a security issue for us when:
> >
> > C) It is small and infrequent enough to be likely to not cause a problem short term (within minutes) with expected normal use. It should also not be controllable by the remote party. Applications are likely to survive tens or hundreds of kilobytes extra memory use several minutes into the future.
> >
> > D) It is not a scurity problem (in libcurl) if the leak happens as a result of wrong/bad use of the API
> >
> > Finally:
> >
> > A memory-leak is *always* a bug and it can even be a bad one. We do our best to never have them. The specific question I'm focusing on here is when this bug is also a security issue.
> >
> > --
> >
> > / daniel.haxx.se
> > | Commercial curl support up to 24x7 is available!
> > | Private help, bug fixes, support, ports, new features
> > | https://www.wolfssl.com/contact/
> > -------------------------------------------------------------------
> > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> > Etiquette: https://curl.se/mail/etiquette.html
>
>
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-01-07