Critical Vulnerabilities In Delphi Code Leads To Memory Corruption
- С сайта: Vulnerability(cybersecuritynews.com)
- Вернуться к списку новостей
С сайта: Vulnerability(cybersecuritynews.com)
Researchers have uncovered serious memory corruption vulnerabilities in Delphi programming language, challenging the widespread belief that Delphi provides inherent memory safety protections.
These findings highlight significant security risks that could potentially lead to application crashes, data leaks, or even remote code execution in affected software.
The vulnerabilities specifically relate to how Delphi handles memory management, particularly with arrays, strings, and object allocations.
Delphi, a dialect of Object Pascal developed initially by Borland and now maintained by Embarcadero Technologies, has been widely used in enterprise software development for decades.
The language was previously listed by the NSA in a 2023 paper on Software Memory Safety as one of the “memory safe” languages, though with caveats regarding certain unsafe functions.
Analysts at Include Security identified that despite its reputation for safety, Delphi code can be just as vulnerable to memory corruption issues as C/C++ when certain coding patterns are followed.
Their research demonstrates how seemingly innocent programming mistakes in Delphi can lead to exploitable security vulnerabilities, even with some safety mechanisms enabled.
The research team constructed multiple proof-of-concept examples to demonstrate the vulnerabilities, focusing on both stack and heap-based corruption scenarios.
Their findings show that while debug builds might catch some issues through range checking, release builds with default compiler settings can be dangerously vulnerable.
Memory Corruption
One example presented by the researchers showed a simple stack-based buffer overflow, where an attempt to write beyond the bounds of a fixed-length array could corrupt the return address on the stack when range checking was disabled:-
procedure Overflow1; var ar: Array[0..9] of Byte; // Fixed-length array on the stack i: Integer; begin for i := 0 to 999 do begin ar[i] := $41; // Try to overflow the array end; end; // If overflow happens, returns to $41414141
.webp)
When compiled in release mode with default settings, this code overflows the stack buffer and corrupts the return address (Source – Include Security)
The researchers also demonstrated how certain system functions like Move, FillChar, BlockRead, and BlockWrite can bypass array bounds checking even when enabled.
In another example, they showed how heap-based vulnerabilities such as use-after-free can occur when mishandling object lifetimes:-
obj1 := TMyFirstClass.Create; // Create obj1 obj1.Free; // Free obj1 obj2 := TMySecondClass.Create; // Create obj2 (occupies the same memory) obj1.ar[4] := $41; // Write to obj1 after it's been freed, modifying obj2
The research serves as an important reminder that developers should not assume any language provides complete memory safety without proper practices and compiler settings.
#Cyber_Security_News #Vulnerability #cyber_security_news #vulnerability
Оригинальная версия на сайте:
Critical Vulnerabilities In Delphi Code Leads To Memory Corruption
Author: Tushar Subhra DuttaResearchers have uncovered serious memory corruption vulnerabilities in Delphi programming language, challenging the widespread belief that Delphi provides inherent memory safety protections.
These findings highlight significant security risks that could potentially lead to application crashes, data leaks, or even remote code execution in affected software.
The vulnerabilities specifically relate to how Delphi handles memory management, particularly with arrays, strings, and object allocations.
Delphi, a dialect of Object Pascal developed initially by Borland and now maintained by Embarcadero Technologies, has been widely used in enterprise software development for decades.
The language was previously listed by the NSA in a 2023 paper on Software Memory Safety as one of the “memory safe” languages, though with caveats regarding certain unsafe functions.
Analysts at Include Security identified that despite its reputation for safety, Delphi code can be just as vulnerable to memory corruption issues as C/C++ when certain coding patterns are followed.
Their research demonstrates how seemingly innocent programming mistakes in Delphi can lead to exploitable security vulnerabilities, even with some safety mechanisms enabled.
The research team constructed multiple proof-of-concept examples to demonstrate the vulnerabilities, focusing on both stack and heap-based corruption scenarios.
Their findings show that while debug builds might catch some issues through range checking, release builds with default compiler settings can be dangerously vulnerable.
Memory Corruption
One example presented by the researchers showed a simple stack-based buffer overflow, where an attempt to write beyond the bounds of a fixed-length array could corrupt the return address on the stack when range checking was disabled:-
procedure Overflow1; var ar: Array[0..9] of Byte; // Fixed-length array on the stack i: Integer; begin for i := 0 to 999 do begin ar[i] := $41; // Try to overflow the array end; end; // If overflow happens, returns to $41414141
When compiled in release mode with default settings, this code overflows the stack buffer and corrupts the return address (Source – Include Security)The researchers also demonstrated how certain system functions like Move, FillChar, BlockRead, and BlockWrite can bypass array bounds checking even when enabled.
In another example, they showed how heap-based vulnerabilities such as use-after-free can occur when mishandling object lifetimes:-
obj1 := TMyFirstClass.Create; // Create obj1 obj1.Free; // Free obj1 obj2 := TMySecondClass.Create; // Create obj2 (occupies the same memory) obj1.ar[4] := $41; // Write to obj1 after it's been freed, modifying obj2
The research serves as an important reminder that developers should not assume any language provides complete memory safety without proper practices and compiler settings.
#Cyber_Security_News #Vulnerability #cyber_security_news #vulnerability
Оригинальная версия на сайте:
