With the development of the Internet, embedded devices are being distributed in an environment full of source code-level security vulnerabilities that can be exploited by attackers. Therefore, embedded software developers should be aware of different types of security vulnerabilities-especially code injection.
The term "code injection" means that regular data input to a program can be made into "contained code", and the program can be tricked to execute the code. The code injection flaw means that hackers can hijack an existing process and execute any code they like with the same permissions as the original process.
In many embedded systems, processes need to run with the highest authority, so a successful code injection attack can completely control the machine and steal data, causing the device to malfunction, making it a member of its botnet or making it permanently unusable.
The key aspects of code injection vulnerabilities are:
The program reads data from the input channel
The program treats data as code and compiles it
In most cases, it is unusual for a program to deliberately execute data as if it were executing code, but it is common to use data to construct intentionally executed objects.
Embedded column
1
Format string vulnerability
Most C programmers are familiar with the printf function. In general, these format strings are followed by a list of other parameters, and the format strings are interpreted as a set of instructions for rendering the remaining parameters as strings. Most users know how to write the most commonly used format specifiers: such as strings, decimals and floating-point numbers-%s, %d, %f-but they don't know that there are other format string instructions that can be abused.
The following is one way the printf function is often abused. Some programmers are used to compiling strings as follows:
printf（str）;
Although this will have the desired effect most of the time, it is wrong because the first parameter of printf will be compiled into a format string. So, if str contains any format specifiers, they will be compiled like this. For example, if str contains'%d', it will interpret the next value in the printf parameter list as an integer and convert it to a string. In this case, there are no more parameters, but the machine does not know this when it is executed; all it knows is that some parameters of the function have been pushed to the stack.
Because there is no mechanism at C runtime to tell the machine that there are no more parameters, printf will simply select the next item on the stack, compile it to an integer, and print it out. It is easy to see that this can be used to print any amount of information from the stack. For example, if str contains'%d%d%d%d', the value of the next four words on the stack will be printed.
Although this is a code injection security vulnerability, it can be forgiven because the only possible harm it can cause is that it can be used to obtain data in the stack. But if the sensitive data (such as passwords or certificate keys) is located there, the situation will get worse; and since the attacker can write any memory address there, the situation may get worse.
What makes this bad situation possible is the format specifier'%n'. Usually, the corresponding parameter is a pointer to an integer. When the format string is compiled in order to create the result string, as soon as'%n' is encountered, the number of bytes written so far is placed in the storage unit indicated by the pointer. For example, after the following printf completes, the value in i will be 4:
printf（“1234％n”，＆i）;
If the actual parameters of the function are less than the format specifiers, then printf will compile any data on the stack as parameters. Therefore, if an attacker can control the format string, they can write essentially any value to the stack location. Because the stack is where local variables are located, their values can be changed. If some of these variables are pointers, then the platform can even reach other non-stack addresses.
The goal that is truly valuable to the attacker is to let the attacker control the execution part of the program. If a local variable is a function pointer, the attacker can write code through subsequent calls of the pointer to achieve his goal. When the function returns, the attacker can also overwrite the address where the instruction is to be delivered.
Embedded column
2
Avoid code injection
The best way to avoid code injection is through design. If you can use a language that will never show vulnerabilities, then this is the best because your code is immune to all attacks when it is built. Or you can design your code to prohibit interfaces that may cause these problems. Unfortunately, these options are not always feasible in embedded systems. Even though C is a dangerous language and full of loopholes, it is still the language of choice for many organizations. In view of this, developers should understand other ways to avoid code injection.
Two golden rules should be followed to prevent code injection vulnerabilities:
1. If you can avoid it, try not to compile the data like code;
2. If you cannot avoid it, please make sure to verify that the data is good before using it.
To avoid vulnerabilities in format strings, the first of these rules is the most appropriate; you can write code as follows:
printf（“％s”，str）;
In this way, the content of str is only regarded as data. This is the least mind-boggling method, as long as you can find all the places where you should make this modification. But this can be tricky for large programs, especially for third-party code libraries.
Embedded column
3
Testing vulnerabilities
Testing for these types of vulnerabilities can be difficult; even tests that can achieve very high code coverage cannot trigger these problems. When testing for security vulnerabilities, testers must adopt an attacker's mentality. Techniques such as fuzzing may be useful, but the technique is usually too random to be highly reliable.
Static analysis can effectively find code injection vulnerabilities. Note that the early-generated static analysis tools (such as lint and its descendant derivatives) are not good at finding such vulnerabilities, because in order to find the vulnerabilities accurately, it is necessary to complete the path sensitive analysis of the entire program.
Recently, advanced static analysis tools are more effective. Static analysis tool vendors have accumulated rich experience in which interfaces are dangerous, the knowledge base for finding the target, and how to effectively carry out these tasks.
The key technology used here is pollution analysis or dangerous information flow analysis. These tools first identify the source of potential risk data and track the information to understand how the information flows into the location being used through the code without verification. At the same time, this is also the best tool to visualize the entire process.
Embedded column
4
in conclusion
Code injection vulnerabilities are dangerous security issues because they may allow an attacker to interrupt the program and sometimes even take complete control of the program. Developers who care about how to ensure that their embedded code can be used safely in a potentially malicious Internet environment should inject such code into vulnerabilities and eliminate them as early as possible in the development cycle and strict code inspections. The advanced static analysis tools mentioned above are recommended.
source:
http://www.newelectronics.co.uk/electronics-technology/code-injection-a-common-vulnerability/150031/
1. The GD32 Arm MCU Internet of Things developer online course is coming, soon join the group and wait for the class to start!
2. Expert opinion: Embedded and IoT industry trends in 2021
3. Why is everyone optimistic about RISC-V?
4. Three program architectures to be used in embedded development~
5. Ten major technology trends of Ali Dharma Academy in 2021~
6. FPGA is difficult to understand? Actually compare with GPU to understand
Disclaimer: This article is reproduced online, and the copyright belongs to the original author. If you are involved in copyright issues, please contact us, we will confirm the copyright based on the copyright certification materials you provide and pay the author's remuneration or delete the content.