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: Jeffrey Walton via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 7 Jan 2021 07:29:40 -0500
On Thu, Jan 7, 2021 at 4:03 AM Daniel Stenberg via curl-library
<curl-library_at_cool.haxx.se> wrote:
>
> 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.
Correct.
The problem use case is managed languages, like Java and C#, and
shared objects. The problem platforms are Android and Windows Phone.
There may be more problem platforms, but they are the ones I am aware
of.
In the managed language the platform will load and unload a shared
object hundreds or thousands of times. Each time the shared object is
unloaded the memory leaks. Each time the shared object is reloaded,
new memory is used. The old, unclaimed memory just accumulates against
the process.
This use case caused the OpenJDK folks a lot of problems with OpenSSL
on Android in the past. Devices were running out of memory. There's a
mailing list message somewhere about it.
> 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.
All memory leaks accumulate in managed languages. Size does not
matter. If it's a long running process then there's a risk of resource
exhaustion.
I believe the OpenSSL leak giving the OpenJDK folks trouble was only a
few hundred bytes. The problem was, it happened frequently and the
process lasted a long time. Eventually the device ran out of memory.
> 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 server is probably not going to be a problem. Shared objects on
servers usually don't get loaded/unloaded multiple times. The shared
object is loaded once when the process is started, and the shared
object stays loaded for the lifetime of the process.
> 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.
If the use case is *not* a long running process, then the device
probably won't witness the problem.
> D) It is not a scurity problem (in libcurl) if the leak happens as a result of
> wrong/bad use of the API
Correct.
This use case (incorrect API usage) is like the one cURL had because
of the Windows Network Redirector. There's only so much cURL can do...
> 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.
Memory issues are fixed everyday. Some of them are probably more
severe and probably deserve a CVE. You cannot count how many memory
issues were cleared without a CVE but were CVE worthy. The kernel and
all those shared libraries... uncountable...
I would not lose a moment's sleep over it. Fix the issue, document it
and move on.
Jeff
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-01-07
Date: Thu, 7 Jan 2021 07:29:40 -0500
On Thu, Jan 7, 2021 at 4:03 AM Daniel Stenberg via curl-library
<curl-library_at_cool.haxx.se> wrote:
>
> 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.
Correct.
The problem use case is managed languages, like Java and C#, and
shared objects. The problem platforms are Android and Windows Phone.
There may be more problem platforms, but they are the ones I am aware
of.
In the managed language the platform will load and unload a shared
object hundreds or thousands of times. Each time the shared object is
unloaded the memory leaks. Each time the shared object is reloaded,
new memory is used. The old, unclaimed memory just accumulates against
the process.
This use case caused the OpenJDK folks a lot of problems with OpenSSL
on Android in the past. Devices were running out of memory. There's a
mailing list message somewhere about it.
> 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.
All memory leaks accumulate in managed languages. Size does not
matter. If it's a long running process then there's a risk of resource
exhaustion.
I believe the OpenSSL leak giving the OpenJDK folks trouble was only a
few hundred bytes. The problem was, it happened frequently and the
process lasted a long time. Eventually the device ran out of memory.
> 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 server is probably not going to be a problem. Shared objects on
servers usually don't get loaded/unloaded multiple times. The shared
object is loaded once when the process is started, and the shared
object stays loaded for the lifetime of the process.
> 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.
If the use case is *not* a long running process, then the device
probably won't witness the problem.
> D) It is not a scurity problem (in libcurl) if the leak happens as a result of
> wrong/bad use of the API
Correct.
This use case (incorrect API usage) is like the one cURL had because
of the Windows Network Redirector. There's only so much cURL can do...
> 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.
Memory issues are fixed everyday. Some of them are probably more
severe and probably deserve a CVE. You cannot count how many memory
issues were cleared without a CVE but were CVE worthy. The kernel and
all those shared libraries... uncountable...
I would not lose a moment's sleep over it. Fix the issue, document it
and move on.
Jeff
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-01-07