If there is a memory leak in #libcurl that leaks N bytes per new connection. Is that a security problem? If so, at which N does it start?
- 500 bytes (39%, 132 votes)
- 10 KB (10%, 35 votes)
- 100 KB (5%, 19 votes)
- never (44%, 146 votes)
Fabian ¯\_(ツ)_/¯
in reply to daniel:// stenberg:// • • •nitsa 🌸
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to nitsa 🌸 • • •nitsa 🌸
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to nitsa 🌸 • • •ouuan
in reply to daniel:// stenberg:// • • •jens persson
in reply to daniel:// stenberg:// • • •No, i would say its a stability problem. It might become a security problem for the using application though.
But most likely its AI slop.
LangerJan
in reply to daniel:// stenberg:// • • •Sir l33tname
in reply to daniel:// stenberg:// • • •Gregory
in reply to daniel:// stenberg:// • • •Haley
in reply to daniel:// stenberg:// • • •For even as small as 500 bytes, I would argue that it qualifies as a potential Denial of Service issue, since this could still cause problems in a program which makes many connections, and is running on a container/microcontroller with only a small amount of memory allocated.
It probably wouldn't get a very high severity rating or anything but I'd argue that it at least qualifies for a score.
Ondřej Surý
in reply to daniel:// stenberg:// • • •If the attacker can trigger a new curl connection from the user of the library, it becomes a security problem.
As much as I hate the CVEs, the Denial of Service is in the CVSS scoring chart, and the CVSS says: Assume vulnerable configuration.
So personally, I would treat this as security vulnerability even if there would be a single leaked byte.
Kaki
in reply to daniel:// stenberg:// • • •Jonathan Yu
in reply to daniel:// stenberg:// • • •By itself, not a security problem, in my opinion. If someone embeds libcurl in a server side service, then it could cause a denial of service issue or result in unexpected reboots.
So my current perspective is that it's a possible ingredient for a security issue, but not a security issue in itself.
doragasu
in reply to daniel:// stenberg:// • • •Dietmar Hauser
in reply to daniel:// stenberg:// • • •So, on that condition, the correct answer is "0 bytes" (not offered) or "never". The results so far seem to bear that out.
Pixdigit
in reply to daniel:// stenberg:// • • •Douglas Kilpatrick
in reply to daniel:// stenberg:// • • •In curl, the command? Never.
Libcurl? Such that a long running daemon could actually be impacted? I think one byte...
abadidea
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to abadidea • • •abadidea
in reply to daniel:// stenberg:// • • •RootWyrm 🇺🇦
in reply to daniel:// stenberg:// • • •@0xabad1dea agreed; the line must be drawn on security problems.
However, I'd argue that it's still needs to be fixed at some priority. Is it a security concern? Unless it's leaking sensitive data, nah. But long uptime ESP32's and similar could conceivably experience A Problem.
What Problem? <shrug!> Maybe they just stop showing the weather. Maybe somebody ignored the "NOT FOR LIFE CRITICAL" labels on everything. But not a security problem.
Claus Holm Christensen
in reply to daniel:// stenberg:// • • •Security use the CIA model, Confidentiality, Integrity and Availability. This is not a threat to either C or I, but Availability may be impacted over time, leading to a Denial of Service situation. Thus the size of the memory leak is not relevant, the precense is enough to call it a security problem.
Also, will the systems overall react correctly in a situation with limited resources?
Jim Fuller
in reply to daniel:// stenberg:// • • •Jim Fuller
in reply to daniel:// stenberg:// • • •