Why are malware viruses so wide spread?
This is the perennial question, that will not die. Here's one major reason why.
Microsoft security engineer Matt Miller from Microsoft Security Response Center gave a presentation at security conference stated it very succinctly in his slides, that over the last 12 years, around 70 percent of all Microsoft patches were fixes for memory safety bugs (see slide 10).
The reason for this high percentage is because Windows has been written mostly in C and C++, two "memory-unsafe" programming languages that allow developers fine-grained control of the memory addresses where their code can be executed.
Memory-unsafe bugs happen when software, accidentally or intentionally, accesses system memory in a way that exceeds its allocated size and memory addresses, accessing other parts of the system to gain elevated privileges or impregnate custom malware code into that adjacent memory space.
Memory-unsafe bugs have similar terms such as buffer overflow, race condition, page fault, null pointer, stack exhaustion, heap exhaustion/corruption, use after free, or double free --all describe memory safety vulnerabilities.
There is a tension for whom the responsibility resides with, the language/compiler or the operating system.
The C philosophy is always trust the programmer. And also not checking bounds allows a C program to run faster. The problem is that C/C++ doesn't actually do any boundary checking with regards to arrays. It depends on the OS to ensure that you are accessing valid memory.
There is only one solution and that is to re-write the entire Windows Operating system in a memory-safe language like Rust. That is starting to be addressed.
Here's a brief review of one unsafe memory bug, image courtesy of stack overflow.
Source Slides : https://github.com/Microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf
Stack Overflow Attack Source Slides
https://www.slideshare.net/gumption/buffer-overflow-attacks-7024353
This is the perennial question, that will not die. Here's one major reason why.
Microsoft security engineer Matt Miller from Microsoft Security Response Center gave a presentation at security conference stated it very succinctly in his slides, that over the last 12 years, around 70 percent of all Microsoft patches were fixes for memory safety bugs (see slide 10).
The reason for this high percentage is because Windows has been written mostly in C and C++, two "memory-unsafe" programming languages that allow developers fine-grained control of the memory addresses where their code can be executed.
Memory-unsafe bugs happen when software, accidentally or intentionally, accesses system memory in a way that exceeds its allocated size and memory addresses, accessing other parts of the system to gain elevated privileges or impregnate custom malware code into that adjacent memory space.
Memory-unsafe bugs have similar terms such as buffer overflow, race condition, page fault, null pointer, stack exhaustion, heap exhaustion/corruption, use after free, or double free --all describe memory safety vulnerabilities.
There is a tension for whom the responsibility resides with, the language/compiler or the operating system.
The C philosophy is always trust the programmer. And also not checking bounds allows a C program to run faster. The problem is that C/C++ doesn't actually do any boundary checking with regards to arrays. It depends on the OS to ensure that you are accessing valid memory.
There is only one solution and that is to re-write the entire Windows Operating system in a memory-safe language like Rust. That is starting to be addressed.
Here's a brief review of one unsafe memory bug, image courtesy of stack overflow.
Source Slides : https://github.com/Microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf
Stack Overflow Attack Source Slides
https://www.slideshare.net/gumption/buffer-overflow-attacks-7024353
No comments:
Post a Comment