Repository navigation
Integer overflow in lib/vssh/libssh2.c #12983
Description
Activity
First, if you find and want to report security problems we clearly ask you to not report them here but instead do that at hackerone.com/curl. It is rude and inconsiderate to publish security risks in public at once.
But then: please explain exactly and with details which specific input a user needs to provide to curl or libcurl for this issue you mention to become a security problem.
The real risk I see here is that libcurl limits the transfer to an unexpected size. But then it is questionable if this can actually happen to a good-faith user.
Reacted by Sadarex, colinstu12, Jubilee, Kurt B., Valentin B., Iacopo Moles, Christian Nicolai, Martin Ligabue, McSinyx, Max Horn and 64 moreReacted by megagrumpThe issue was detected by our new AI-powered vulnerability scanner, detecting that a similar pattern exists in lib/curl_range.c where the overflow is avoided with:
totalsize = to - from; if(totalsize == CURL_OFF_T_MAX) return CURLE_RANGE_ERROR; data->req.maxdownload = totalsize + 1; /* include last byte */Integer overflows in C are undefined behavior, and the behavior of the application is unknown when they arise.
Reacted by Nicolai Søborg, Dan, Marcus Müller, Tim Yates, Phil Bordelon, Lars Mühlbauer, Thomas Frans, SuperIlu, Merlijn, Chris Mills and 186 moreReacted by locrianz, DerRockWolf, TheSunCat, lightonflux, 1.11e-1f64, Claudemirovsky, HD Moore, megagrump, Tomás Farías Santana, Corbin Simpson and 30 moreReacted by Joshua Harms and Álvaro Morales T.Integer overflows in C are undefined behavior, and the behavior of the application is unknown when they arise.
That's a ridiculous stance that helps no one. If no known compilers on any known platforms make anything else but put a funny value in in
sizehere, this is not a security problem. Unless you can prove me wrong.Reacted by Tod Beardsley, Thomas Frans, Tor Lillqvist, Arialdo Martini, fuomag9, Raine Godmaire, anthonypants, DerRockWolf, santiago fn, Ivailo Karamanolev and 40 more- added a commit that references this issue
on Feb 24, 2024 The issue was detected by our new AI-powered vulnerability scanner,
You really need to add some actual intelligence to the mix.
Reacted by RandomNumberGenerated91, nytpu, mirabilos, François Lamboley, unknowntrojan, Chlod Aidan Alejandro, TymanWasTaken, Drew Jose, colinstu12, DCoderLT and 131 moreReacted by Gert van Dijk, Joshix-1, Corentin Forler, Daniel Stenberg, Nina Kalinina, Felix Breidenstein, Reiner Herrmann, Denys Dmytriyenko, NoSharp, Nick Cao and 224 moreReacted by Henri Salo, epicEaston197, Stephanie Handsteiner, Nicolae Țugui, Ethan-Pixelate, emi, Bentley Smith, Travis71i, Bryan Müller, nam and 9 moreReacted by slonkazoid, Stephanie Handsteiner, Bentley Smith, Paolo Flores, nam, Innes Anderson-Morrison, Daniel Agafonov, Thea Juna Schwanke, Mcp613, Cian McElhinney and 1 moreReacted by RandomNumberGenerated91, Bentley Smith, Travis71i, Holden, nam, Daniel Agafonov and Thea Juna SchwankeThe issue was detected by our new AI-powered vulnerability scanner, detecting that a similar pattern exists in lib/curl_range.c where the overflow is avoided with:
totalsize = to - from; if(totalsize == CURL_OFF_T_MAX) return CURLE_RANGE_ERROR; data->req.maxdownload = totalsize + 1; /* include last byte */Integer overflows in C are undefined behavior, and the behavior of the application is unknown when they arise.
This is the baloney in the idiot sandwich that is this issue
Reacted by Mcp613@vulnerabilityspotter until you have explained yourself and fixed your faulty procedure, I don't think you should continue to file new invalid issues in other projects (or in other project's mirror repos). That's just going to get you reported and/or blocked.
Reacted by Thomas Frans, Jonas Wunderlich, Lars Müller, Alex S., fuomag9, Harry Sintonen, SuperIlu, Hammy, Kai Mechel, DerRockWolf and 58 moreIt can be noted that this is an integer overflow under the condition that the user asks for transferring the byte range "0 - 2^63" when at the same time the remote file has the size of at least 2^63 bytes. I think it's rare.
2^63 is 9223372036854775808 bytes. I believe it is about 8192 petabytes.
Reacted by Adam Williams, Agustín Borrego, DerRockWolf, Ben Eggers, Daniel W. Crompton, Dario Emerson, Ivailo Karamanolev, Lucy, fuomag9, arcctgx and 127 moreBro even wrote the post using AI. I'm now even more certain that AI can only replace lazy people.
Reacted by nicole mikołajczyk, jstm, Luca Scalet, Pete Brubaker, Tessa van der Heijden, CompactHermit, AntsyBoi, Clément, Georgi Lyubenov, billchenchina and 46 moreReacted by jack kuperman, Miss Manteater, Kevin Lyda, Ben V. Brown, Pete Brubaker, Alejandro, Ryan Hendrickson, AntsyBoi, Clément, hat_kid and 21 more@bagder The issue is preparing us for future where storage is limitless
Reacted by zimmerwald, heinwol, Daniele Scasciafratte, Honbra, Zachary Yaro, Luca Saalfeld, Antonio Albert, LinasKo, Milk-Cool, Michał Korczak and 19 moreReacted by Ricardo Fernández Serrata and KyWhy is this issue still open?
Reacted by Alejandro, Tessa van der Heijden, Nicolae Țugui, Ethan-Pixelate, Sayaka Halton, zocker-160, Johannes Mols and Ricardo Fernández SerrataReacted by Ricardo Fernández Serrata and Jiří Barouš- added a commit that references this issue
on Feb 25, 2024 For wget, we got a similar report. TBH, I find it worthy to try writing a tool for automated finding of software defects. Just because the AI tool isn't better than human experts on the first try doesn't mean the tool can't be improved. Other tools like static analyzers and fuzzers had their imperfect early days as well.
Reacted by Ricardo Fernández SerrataI do feel like the AI should be used to find potential vulnerabilities but should definitely be verified by a human before an issue is actually created the AI should be used as a tool not a replacement for a human making issues
Reacted by Alexis, Ashley Williamson, ZGURemixer, Kyle Smith, Jarett Millard, Joel, Ricardo Fernández Serrata, xliee, calad0i and Jiří Barouš
I did this
Security Vulnerability Report
File: lib/vssh/libssh2.c
Function: ssh_statemachact() (Starting at line 2512)
Vulnerability Type: Integer Overflow
Location: Line 2547
Severity: High
Description:
In the ssh_statemachact() function, at line 2547, there exists a vulnerability related to an integer overflow. The vulnerability arises from the calculation of the variable size, which is assigned the value of to - from + 1.
size = to - from + 1;
If the values of to and from are such that to is sufficiently close to the maximum representable value for the data type being used, subtracting from from to may result in an overflow. Adding 1 to this potentially overflowing value could exacerbate the overflow or lead to unexpected behavior.
Exploitation Scenario:
An attacker may craft a malicious request with carefully chosen values for to and from such that to is very close to the maximum representable value for the data type, triggering an integer overflow during the calculation of size. This could potentially lead to various security issues, such as memory corruption, buffer overflows, or unexpected behavior, depending on how the size variable is subsequently used.
Impact:
The impact of this vulnerability could be severe, potentially leading to:
Recommendations:
Severity Justification:
The presence of an integer overflow vulnerability at line 2547 poses a high risk to the security and stability of the application. Exploitation of this vulnerability could lead to severe consequences, including memory corruption, security bypass, or denial of service conditions.
Affected Versions:
This vulnerability affects all versions of the application that include the vulnerable ssh_statemachact() function.
References:
Conclusion:
The presence of an integer overflow vulnerability at line 2547 in the ssh_statemachact() function poses a high risk to the security and stability of the application. It is imperative to address this vulnerability promptly by implementing appropriate bounds checking and error handling mechanisms to prevent potential exploitation and associated security risks.
I expected the following
curl/libcurl version
7448054
operating system
All