Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: On memory-leaks as security problems
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Kamil Dudka via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 07 Jan 2021 10:43:08 +0100
On Thursday, January 7, 2021 9:59:39 AM CET Daniel Stenberg via curl-library
wrote:
> 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.
(A) is tricky. Desktop applications can survives a few gigabytes of leaked
memory without having any impact on security while embedded devices can die
rather quickly.
> 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.
Although I am not an expert in this area, I think that (B) should be the most
important criterion here.
> 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
(D) sounds totally obvious to me. Otherwise we would have an infinite number
of CVEs in the C run-time already. One can easily construct a program that,
for example, calls malloc() without ever using its return value. On the other
hand, there might be some corner cases where libcurl API is underspecified in
terms of freeing resources.
Kamil
> 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.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-01-07
Date: Thu, 07 Jan 2021 10:43:08 +0100
On Thursday, January 7, 2021 9:59:39 AM CET Daniel Stenberg via curl-library
wrote:
> 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.
(A) is tricky. Desktop applications can survives a few gigabytes of leaked
memory without having any impact on security while embedded devices can die
rather quickly.
> 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.
Although I am not an expert in this area, I think that (B) should be the most
important criterion here.
> 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
(D) sounds totally obvious to me. Otherwise we would have an infinite number
of CVEs in the C run-time already. One can easily construct a program that,
for example, calls malloc() without ever using its return value. On the other
hand, there might be some corner cases where libcurl API is underspecified in
terms of freeing resources.
Kamil
> 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.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-01-07