AlmaLinux makes Red Hat reconsider after refusing to accept a patch
The AlmaLinux developers have been presented with the opportunity to demonstrate to Red Hat that they are not "a threat" that only duplicates other developments and creates a simple rebuild (this in reference to to the comment made by Red Hat for restricting access to RHEL code)
And it is that just shortly after having made the announcement in the change to a new distribution maintenance model, allowing the application of their own patches, the AlmaLinux developers fixed the vulnerability in the iperf3 package (already listed under CVE-2023-38403 ) and attempted to push the prepared fix to the CentOS Stream, as the vulnerability remained unpatched on RHEL and CentOS Stream.
Initially Red Hat refused to accept the solution, citing the rule that "only important problems can be solved", since to Red Hat developers, this vulnerability was not important and it did not present a "significant" risk to mark it as "priority" since another of their comments was that solutions to these types of problems are included in the packages only when necessary, due to customer requests or business needs.
Thanks for the contribution. At this time we do not plan to address this in RHEL, but will keep it open for evaluation based on customer feedback.
Poco after "evaluation" by Red Hat from the solution to the vulnerability, andThe Alma Linux representative expressed bewilderment, since a patch ready to fix the problem was submitted for inclusion in the CentOS Stream and:
Red Hat was not required to create a fix itself, but only needed to review the final accepted change to the iperf project's code base.
The developer of Alma Linux tNeither did he agree to classify that vulnerability is less, since the fixed bug leads to an integer overflow and process memory corruption when an incorrect value is passed to the data size field.
And it is that the developer of AlmaLinux mentions that as such vulnerability in iperf3, allows to send a specially crafted message and cause memory corruption (An attack from both the client to the server and from the server to the client is possible.) This is because iperf3 is designed to test network performance, it uses a client-server model in which the client sends a request with parameters to the server process over a TCP connection, and the server performs the testing and returns the result.
In practice, the vulnerability allows an attacker to attack publicly accessible iperf3 servers. or create your own server and attack users who connect through it. Exploitation of the vulnerability is supposed to be limited to crashing the process, but even in this case, the ability to remotely cause the iperf3 server process to crash on publicly accessible servers needs to be fixed.
In response, a Red Hat employee explained that the matter is not limited to a finished patch, and that developing a fix is just one of the stages in preparing for a package update: you need to make sure that the fix passes check. of quality and after being applied in the package, it does not lead to regressive changes.
We are committed to addressing important and critical security issues as defined by Red Hat. Security vulnerabilities with low or moderate severity will be addressed upon request where there are customer or other business requirements to do so.
Therefore, only critical and important vulnerabilities are fixed without fail, and low and medium severity issues are fixed as the need arises.
Finally, it should be mentioned thate After the discussion, Red Hat's security team reconsidered its position, classified the problem as important, accepted the patch and released a package update to fix the vulnerability.
If you are interested in knowing more about it, you can check the details in the following link