At the Black Hat Europe 2017 conference, a number of security flaws were discovered in popular programming languages. Interpreters of these languages contain serious security flaws, which then expose the resulting code to different types of attacks. The new analysis is based on Fernando Arnaboldi, who works as the security consultant at IOActive.
In testing, a fuzzing method was used, where invalid, unexpected, or simply random data were input to the program. This allows the induction of commonly untested conditions that do not correspond to normal usage, but may be misused for targeted attack.
Fuzzing lets you detect crashes, poor memory work, or unexpected program behavior. This is not a novelty, these techniques have been used for a very long time, like Google. Recently, a number of bugs have been discovered in Linux USB drivers.
For this purpose, Arnaboldi wrote his own XDiFF fuzzer (eXtended Differential Fuzzing Framework), which he released on GitHub. It is written to generate rights for the five languages mentioned. For each of them, he chose a set of basic functions to which he then puts various types of inputs (payloads).
In order to detect vulnerabilities in the code, you need to choose the correct inputs. So the author chose less than three dozens of primitive values (numbers, characters, etc.) that added a well-known payload. He was chosen to allow the test application to try to access external resources - something unexpected.
Differential fuzzers are less common than conventional ones. Their functionality is enhanced by the fact that they usually test one code on multiple implementations of the same language and look for different behaviors. For example, the outputs and error messages with expected status are compared.
Specifically, it monitors whether the program discovers the contents of local files, triggers a foreign code, or calls unusual operating system features. This challenging work brought its fruit, each of the tested programming languages has some problem:
Arnaboldi warns that a potential attacker can exploit these mistakes even in a program that is otherwise written very safely. Because the programs are in the interpreter, the programmer can hardly be affected. Unknowingly, when writing his or her code, he uses dangerous functions that are abusive even if the rest of the program is written exactly according to the rules of secure programming.
According to the discoverer of security issues, it is likely to be a bug in the code or an attempt to simplify development. Errors unambiguously endanger the resulting programs, but should be corrected in interpreters. Such a patch will then resolve issues across all programs using the language.
EUR 12 / Month
EUR 136 / Month