> 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".
Hi, I think a bug is a security issue when an unauthorized person can deliberately exploit it. It may still not be that serious, unless an adversary can take control over a system or data leaks occur. But of course mission critical applications exist where a denial of service is also a serious security issue. In your list: A can not be controlled by an adversary, so not a security issue. B can be controlled by an adversary without authorization, so yes, security issue C can't be controlled by an adversary, not a security issue D: if an adversary can, unauthorized, make an application issue a particular sequence, that application has a security-issue. The severity will be very low due to very low likeliness. libcurl would be mentioned as in 'it allows for a flaw in libcurl due to bad coding practice'. So that street should be wiped (if that's a way to say it in English) up front. How unlikely is it? You can't be really sure. An issue may be found over path X but there could be path Y and Z as well. So a memory leak should always get prioritized to fix as a security best-practice. When to flag as security issue for libcurl? The usefulness of the label dilutes when used too often for theoretical cases. On the other hand to be a serious project you have to report when the risk is real. When somebody proves a D-issue using a real world application based on libcurl within reasonable runtime, then it is a security issue. Or someone shows a proof-of-concept that shows something more severe: remote code execution/obtaining control/data leakage then I think it is also a security issue. I mean proof, not this 'may theoretically be abused to...' which scares off everybody who only half understands it or gives room for commercial abuse. I think the rest is just a crash, e.g. - impact is only (potential) denial of service - the sequence to cause memory leak requires disregarding common engineering practices. - no exploit in a real world program is known or likely Type B issues could also be just theoretical but as they are direct they are easier to achieve = more likely = more severe. As for the risk of small leaks in long running tasks. For the mission critical ones you would expect some mitigation strategies in place. E.g. it is tested for leaks and the developers track and apply open source updates. So if a leak can’t kill a serious application within the time of a reasonable update cycle it is not a security issue, or only very low severity. I think the risk is only real if libcurl can tip into a leaking state after a legitimate call, after which it goes quickly. Because then you can use it for a targeted attack My 2cts Erik ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
