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: Tomalak Geret'kal via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 8 Jan 2021 13:15:01 +0000
On 07/01/2021 14:07, Daniel Stenberg via curl-library wrote:
> 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.
Exactly this.
There are all sorts of bugs that have the potential to,
ultimately, deny service to users. But a /security issue/,
in the category we're discussing, is one where a malicious
user can knowingly trigger a series of events that result in
denial of any service on that system to other users.
To that end, the combination of a leak's frequency and
volume must be high enough to do so on reasonable timescales
during the run of a single process, and a malicious actor
must be able to wilfully control one or both of those factors.
This suggests that a leak would have to be more than a
couple of bytes, it would have to scale (e.g. it accumulates
on every HTTP request), and it would have to be dangerous
only in "sensible" applications in order to begin to be
considered a security flaw. Requiring 1000 transfers per
second for months does not really satisfy these criteria; I
don't know how you'd formally define the threshold, but
surely there is some common sense involved. Frankly I'm
happy that you have enough of that Daniel to be the judge,
and the fact that you've brought this question to us bears
that out!
Buggy use of the API certainly does not count. If that's a
security issue, it's a security issue in the calling
application.
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-01-08
Date: Fri, 8 Jan 2021 13:15:01 +0000
On 07/01/2021 14:07, Daniel Stenberg via curl-library wrote:
> 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.
Exactly this.
There are all sorts of bugs that have the potential to,
ultimately, deny service to users. But a /security issue/,
in the category we're discussing, is one where a malicious
user can knowingly trigger a series of events that result in
denial of any service on that system to other users.
To that end, the combination of a leak's frequency and
volume must be high enough to do so on reasonable timescales
during the run of a single process, and a malicious actor
must be able to wilfully control one or both of those factors.
This suggests that a leak would have to be more than a
couple of bytes, it would have to scale (e.g. it accumulates
on every HTTP request), and it would have to be dangerous
only in "sensible" applications in order to begin to be
considered a security flaw. Requiring 1000 transfers per
second for months does not really satisfy these criteria; I
don't know how you'd formally define the threshold, but
surely there is some common sense involved. Frankly I'm
happy that you have enough of that Daniel to be the judge,
and the fact that you've brought this question to us bears
that out!
Buggy use of the API certainly does not count. If that's a
security issue, it's a security issue in the calling
application.
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-01-08