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: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 7 Jan 2021 15:07:20 +0100 (CET)
On Thu, 7 Jan 2021, Jeffrey Walton wrote:
>> The difficulty lies in that grey area between "all" and "none".
>
> All memory leaks can lead to resource exhaustion on platforms that use
> managed languages due to the process lifecycle model.
We don't need managed languages to reach resource exhaustion. We only need a
long-living application that uses something that leaks memory every now and
then. Eventually that application will run out of memory if it just runs long
enough and the leak is big enough.
I think what I'm saying is that if you make such a long-living application,
wouldn't you ALSO: either
A) make sure that if the amount of free memory goes below a certain threshold,
it restarts itself (or similar soft reboot). Or maybe they restart on a given
schedule or after N transfers or similar.
and/or
B) tested your application with the used 3rd party libraries to make sure that
truly don't leak for any use case
and/or
C) if it runs out of memory the app restarts with little to no lost
productivity
I would imagine such precautions could be expected of developers of such
software.
If we agree on that, then the leaks that are security problems are those that
are likely to circumvent or make such precautions difficult to maintain.
For example, I really cannot with a straight face write up a security advisory
for a memory leak in libcurl that leaks a few bytes for a transfer in a
specific setup even if there is a single user somewhere who runs an up that
*never* exits and makes 1000 transfers per second for months and then
eventually runs out of memory after many months due to this. That would not be
a security bug in curl.
Because if we would go with that logic, all bugs would be security related and
I don't think we make anyone any favors by going down that road.
Date: Thu, 7 Jan 2021 15:07:20 +0100 (CET)
On Thu, 7 Jan 2021, Jeffrey Walton wrote:
>> The difficulty lies in that grey area between "all" and "none".
>
> All memory leaks can lead to resource exhaustion on platforms that use
> managed languages due to the process lifecycle model.
We don't need managed languages to reach resource exhaustion. We only need a
long-living application that uses something that leaks memory every now and
then. Eventually that application will run out of memory if it just runs long
enough and the leak is big enough.
I think what I'm saying is that if you make such a long-living application,
wouldn't you ALSO: either
A) make sure that if the amount of free memory goes below a certain threshold,
it restarts itself (or similar soft reboot). Or maybe they restart on a given
schedule or after N transfers or similar.
and/or
B) tested your application with the used 3rd party libraries to make sure that
truly don't leak for any use case
and/or
C) if it runs out of memory the app restarts with little to no lost
productivity
I would imagine such precautions could be expected of developers of such
software.
If we agree on that, then the leaks that are security problems are those that
are likely to circumvent or make such precautions difficult to maintain.
For example, I really cannot with a straight face write up a security advisory
for a memory leak in libcurl that leaks a few bytes for a transfer in a
specific setup even if there is a single user somewhere who runs an up that
*never* exits and makes 1000 transfers per second for months and then
eventually runs out of memory after many months due to this. That would not be
a security bug in curl.
Because if we would go with that logic, all bugs would be security related and
I don't think we make anyone any favors by going down that road.
-- / 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