Carding Forum
Professional
- Messages
- 2,788
- Reaction score
- 1,334
- Points
- 113
Fedor Indutny, author of the platform Io.js (Node fork.js), a member of the technical committee that manages Node development.js, tried to draw attention to the problem with assigning CVE identifiers to incorrect vulnerability reports that do not correspond to reality or do not adequately represent the level of danger. The CVE number used to identify vulnerabilities is assigned without proper verification and without consulting the developers of vulnerable programs, which leads to the appearance of abuse, in which insignificant errors are presented under the guise of dangerous vulnerabilities that do not actually pose a security threat.
False CVEs not only undermine the reputation of projects, but also create a significant additional burden on maintainers, who have to sort out the flow of emails and messages referring to such CVEs. The most unpleasant thing in such situations is that developers cannot challenge the assigned level of danger or get the CVE canceled.
In the case of Fedor, the problem affected Node.The node-ip js library, which was downloaded about 30 million times a week before the vulnerability report was published, but in 5 months the number of downloads decreased to 17 million per week. It is assumed that the presence of a critical vulnerability report contributed to a drop in the library's popularity.
The node-ip library is used as a dependency for more than 3,500 projects that are built with a false CVE warning when running the "npm audit" command. A flood of complaints and messages related to a false CVE led to the fact that after several months of trying to achieve changes in the level of danger in the CVE, the node-ip developer switched the project repository to archive mode, freezing the development process (the repository was in archive mode for 5 days and was removed a few hours ago).
Information about the vulnerability CVE-2023-42282 was published in early February, but before that, the researcher who identified the problem had been trying to get a reward on the Huntr platform since December 2022 (the level of danger is probably overestimated as it affects the reward). Judging by the information from the vulnerability report, Huntr representatives tried to contact the node-ip developers for more than a year to fix the problem, and only then revealed the details publicly.
The problem is that the IsPublic() and isPrivate() functions provided by the library process only the canonical representation of IP addresses, which allows you to get an incorrect result when checking whether an address is in the ranges for internal use (10. x. x. x, 192.168. x.x., 127. x.x. x, 172.16-31. x. x) when transmitting an address in other formats, for example, 0x7f.1, and 127.1 instead of 127.0.0.1. It was claimed that the problem can be used to bypass SSRF protection and checks when granting access to resources. The CVE assigned the issue a critical hazard level (9.8 out of 10), and the GitHub report marked the issue as dangerous.
The author of node-ip expressed disagreement with the fact that the problem is a dangerous vulnerability. In particular, to perform an attack, you need to pass its value to the IsPublic() and isPrivate () functions, while information about the IP address of the connecting client is usually obtained from system functions or the web server environment variable, which initially give only correct values. The situation when unverified data about the verified IP address is transmitted via external input forms or sources controlled by the attacker looks speculative.
Due to the abundance of requests for correction, in mid-February, the node-ip 1.1.9 and 2.0.1 correction releases were formed, which added checks taking into account atypical IP address representation forms. However, given the popularity of the project, the flow of related messages and user requests has not stopped. In the MITRE database, the vulnerability is still marked as critical, but GitHub representatives were persuaded to reduce the level of danger in the GitHub Advisory Database to a minimum.
From recent reports with an overestimated level of danger, you can also note the vulnerability in LibreOffice 24.2.4 CVE-2024-5261, which is assigned a critical level of danger (10 out of 10). The issue, which was fixed a few days ago, affects the LibreOfficeKit library, which allows you to access LibreOffice features from external C/C++ applications, such as calling functions to convert formats. The vulnerability is caused by using the default libCurl setting (CURLOPT_SSL_VERIFYPEER=0), which disables certificate verification when loading external resources over HTTPS, for example, external images specified in the document.
False CVEs not only undermine the reputation of projects, but also create a significant additional burden on maintainers, who have to sort out the flow of emails and messages referring to such CVEs. The most unpleasant thing in such situations is that developers cannot challenge the assigned level of danger or get the CVE canceled.
In the case of Fedor, the problem affected Node.The node-ip js library, which was downloaded about 30 million times a week before the vulnerability report was published, but in 5 months the number of downloads decreased to 17 million per week. It is assumed that the presence of a critical vulnerability report contributed to a drop in the library's popularity.
The node-ip library is used as a dependency for more than 3,500 projects that are built with a false CVE warning when running the "npm audit" command. A flood of complaints and messages related to a false CVE led to the fact that after several months of trying to achieve changes in the level of danger in the CVE, the node-ip developer switched the project repository to archive mode, freezing the development process (the repository was in archive mode for 5 days and was removed a few hours ago).
Information about the vulnerability CVE-2023-42282 was published in early February, but before that, the researcher who identified the problem had been trying to get a reward on the Huntr platform since December 2022 (the level of danger is probably overestimated as it affects the reward). Judging by the information from the vulnerability report, Huntr representatives tried to contact the node-ip developers for more than a year to fix the problem, and only then revealed the details publicly.
The problem is that the IsPublic() and isPrivate() functions provided by the library process only the canonical representation of IP addresses, which allows you to get an incorrect result when checking whether an address is in the ranges for internal use (10. x. x. x, 192.168. x.x., 127. x.x. x, 172.16-31. x. x) when transmitting an address in other formats, for example, 0x7f.1, and 127.1 instead of 127.0.0.1. It was claimed that the problem can be used to bypass SSRF protection and checks when granting access to resources. The CVE assigned the issue a critical hazard level (9.8 out of 10), and the GitHub report marked the issue as dangerous.
The author of node-ip expressed disagreement with the fact that the problem is a dangerous vulnerability. In particular, to perform an attack, you need to pass its value to the IsPublic() and isPrivate () functions, while information about the IP address of the connecting client is usually obtained from system functions or the web server environment variable, which initially give only correct values. The situation when unverified data about the verified IP address is transmitted via external input forms or sources controlled by the attacker looks speculative.
Due to the abundance of requests for correction, in mid-February, the node-ip 1.1.9 and 2.0.1 correction releases were formed, which added checks taking into account atypical IP address representation forms. However, given the popularity of the project, the flow of related messages and user requests has not stopped. In the MITRE database, the vulnerability is still marked as critical, but GitHub representatives were persuaded to reduce the level of danger in the GitHub Advisory Database to a minimum.
From recent reports with an overestimated level of danger, you can also note the vulnerability in LibreOffice 24.2.4 CVE-2024-5261, which is assigned a critical level of danger (10 out of 10). The issue, which was fixed a few days ago, affects the LibreOfficeKit library, which allows you to access LibreOffice features from external C/C++ applications, such as calling functions to convert formats. The vulnerability is caused by using the default libCurl setting (CURLOPT_SSL_VERIFYPEER=0), which disables certificate verification when loading external resources over HTTPS, for example, external images specified in the document.
