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.
On memory-leaks as security problems
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 7 Jan 2021 09:59:39 +0100 (CET)
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.
Date: Thu, 7 Jan 2021 09:59:39 +0100 (CET)
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.htmlReceived on 2021-01-07