Estudio técnico de la vulnerabilidad CVE-2025-5548
This work analyzes the vulnerability CVE-2025-5548, associated with a stack buffer overflow in FreeFloat FTP Server v1.0. The main objective of the lab is to understand how a vulnerable application behaves when faced with manipulated inputs and to observe, in a controlled environment, how a validation failure can end up affecting the program's execution flow.
The development of this repository is not limited to showing the final result; rather, it covers the entire investigation process: environment preparation, tool selection, failure observation, memory analysis, and validation of the real impact of the vulnerability.
The work is structured in two distinct blocks.
This section explains how the practice environment was set up, which operating system was used, which vulnerable application was chosen, and which tools were considered necessary to carry out the analysis.
The second part focuses on the practical side. It describes the process followed to detect the fault, confirm memory corruption, study register overwriting, and verify how the vulnerability can be exploited.
The practice was carried out on a virtual machine with Windows 11 Pro 25H2 (Build 26200.6584). The selected vulnerable software was FreeFloat FTP Server v1.0, an old application suitable for this type of exercise because it lacks many of the protections common in modern programs.
The virtual machine's network was configured in NAT mode, allowing Internet access to install dependencies, download tools, and maintain basic lab connectivity.
To cover all phases of the analysis, several utilities were needed. Some were used to prepare the environment, others to review the binary, and others to observe the process behavior when the failure occurred.
It was used to download repositories, keep certain resources organized, and facilitate the management of the material used during the investigation.
It was used as a support tool to verify connectivity, identify the exposed service, and confirm that the target was responding correctly on the expected port.
It was installed to have libraries, headers, and tools useful for low-level debugging and analysis tasks within the Windows system.
It was used for quick edits, script reviews, and simple manipulation of strings or test data.
It served as a comfortable environment for writing scripts, testing automations, and working with code in a more organized manner.
It was particularly useful when reviewing longer scripts or debugging logic related to payload construction.
Two versions were considered:
It was required to run Ghidra, as this tool is developed in Java.
It was used to observe the program state during execution, check registers, review memory, and analyze the exact point where the failure occurs.
It was used in the static analysis phase to review the binary and locate functions that appeared suspicious from a security standpoint.
It was used as a support tool to decompile and better understand the internal logic of the vulnerable program.
This plugin facilitated tasks such as pattern creation, offset calculation, and identification of problematic characters in the payload.
The main component of the lab was FreeFloat FTP Server v1.0, which acts as the target system within the proof of concept. Its interest lies in the fact that it incorporates a classic stack overflow vulnerability, making it a very suitable case for formative analysis.
Although pre-prepared virtual machines exist for this type of exercise, in this case it was decided to document the environment and justify the tools used. This allows a better understanding of why each application is part of the lab and what role it plays during the analysis.
The first step was to verify that the FTP service was accessible and working correctly. Once connectivity was confirmed, the binary was reviewed using static analysis tools to locate potential weak points related to string handling.
During this review, unsafe functions such as strcpy and strcat appeared, reinforcing the suspicion that the service could be vulnerable to overly long inputs. Several FTP protocol commands capable of receiving user-controlled data were also examined, selecting one of them as the main candidate for testing.
With this foundation, the process was loaded into a debugger to observe its behavior during execution.
The next phase consisted of sending increasingly longer strings to check if the program stopped responding correctly. This procedure allowed verification that, beyond a certain size, the service failed and eventually caused an alteration in memory.
This behavior confirmed that it was not a simple superficial validation error, but a real corruption affecting the process flow.
After triggering the failure, it was necessary to calculate exactly how many bytes were needed to reach the return address. For this, a non-repeating sequence was used, so that the value reflected in EIP at the crash moment could be linked to an exact position within the sent input.
Thanks to this procedure, the specific offset needed to overwrite the control register was obtained.
With the offset already known, a new test was prepared in which the return address was replaced by an easily recognizable value. The goal was to check whether the program allowed EIP to be modified in a controlled manner.
The test was successful, as the debugger showed that the register contained exactly the introduced value. This demonstrated that it was possible to alter the execution flow and redirect it to a chosen address.
Once this point was reached, it was analyzed which bytes could interfere with the payload. In this type of vulnerability, certain characters typically cause truncations, unexpected changes, or premature string termination.
Through successive memory comparisons, several bad characters were identified, including:
\x00\x0a\x0dDetecting them was important to build a final payload that is stable and compatible with the vulnerable program's behavior.
The next step was to find a suitable address that would allow redirecting execution to the memory area where the payload would be placed. This analysis had to consider the operating system and active protections, as some addresses are not stable across executions.
Within the lab, a valid reference was located that allowed linking the flow overwrite with the attacker-controlled input.
With flow control already validated, a shellcode was built that was compatible with the previously discovered constraints. Additionally, a preceding zone of neutral instructions was added to facilitate the CPU safely reaching the start of the payload even if there was a slight deviation from the expected position.
This step was important to increase the reliability of execution.
In the last phase, the complete payload was launched against the vulnerable service while a listener was kept active on the attacking machine. The result was the establishment of a remote connection to the target system, confirming that the vulnerability not only allows causing a program crash but also obtaining controlled execution.
This demonstrates the real impact of the fault and justifies its relevance from both an offensive and defensive security perspective.
The study of CVE-2025-5548 clearly shows how an old application, without modern protection mechanisms, can be vulnerable to classic exploitation techniques based on memory corruption.
Throughout the lab, several fundamental stages have been covered: environment preparation, initial fault observation, overflow validation, execution register control, payload debugging, and final result verification.
Beyond the technical proof, this case helps to understand why the use of unsafe functions and the absence of protection measures remain a significant risk in legacy software. Therefore, this type of exercise is especially useful for consolidating knowledge of reversing, vulnerability analysis, and exploitation in controlled environments.