What Is Malicious Code? Overview + Malicious Code Examples
For that reason, it is essential that you are able to prevent malicious code with secure coding standards and SAST tools — such as a static code analysis tool — and learn from malicious code examples. Here we explain what is malicious code, how can you prevent malicious code, provide malicious code examples, and how you can avoid downloading malicious code.
Read along or jump ahead to the section that interests you the most:
What Is Malicious Code?
Malicious code (or malcode) is any code that has been intentionally designed to cause harm or undesired effects in a software system.
Unfortunately, malicious code cannot be efficiently managed by conventional antivirus software. As a result, many cyberattacksare caused by malcode.
The cybersecurity vulnerabilities created by malicious code could enable cybercriminals to:
- Access private data.
- Change the behavior of a system.
- Prevent the system from operating.
📕 Related Resource: Review the SAST tutorial for additional resources.
Back to top
How Does Malicious Code Happen and How Can You Avoid Downloading Malicious Code?
Malicious code could be intentionally written into a system. For example, a disgruntled developer might write malicious code on purpose.
Or malicious could be injected after development. For example, malware, spyware, or ransomware gets into the system after it’s deployed and causes harm. This is a very real concern, particularly for teams developing safety-critical systems.
It’s best to prevent malicious code before it can compromise your program.
Security best practices should be adopted early in the development process. This is the best way to keep your software safe from malcode vulnerabilities.Back to top
Preventing Malicious Code + Malicious Code Examples
You can protect your software from malicious code. And that’s by making sure it doesn’t contain security vulnerabilities.
Here's the two best practices to prevent malicious code:
1. Use Secure Coding Standards
2. Enforce Secure Coding Rules with a Static Code Analyzer
Use Secure Coding Standards to Prevent Malicious Code
CERT, for instance, targets code with undefined behavior that could lead to a security risk.
Malicious Code Examples of Buffer Overflow
Buffer overflow is a well-known security vulnerability. It occurs when a program writes data outside the boundary of its allocated memory.
This compromises the security of the software because it may be possible to inject malcode into runtime memory.
Even commonly used library functions — such as gets() or fscanf() — can lead to buffer overflow when not used carefully.
Malicious Code Example: Why Buffer Overflow Leaves Code Vulnerable
Buffer overflow leaves your code vulnerable.
Here’s a malcode example.
If the program is receiving data — without a check in place to ensure that the input buffer can’t overflow — then it will be possible to design an input, or “payload’, that contains malicious code. This input can overflow the input buffer.
As a result, it overwrites the function’s return address with the address of the malcode. When the function returns, the program executes from the start of the malcode.
How to Prevent Buffer Overflow
“Do not form or use out-of-bounds pointers or array subscripts.”
By applying this rule, you’ll avoid writing to out-of-range pointers or array subscripts. And this prevents the execution of arbitrary code. In addition, MISRA C also has a rule for this — and CWE notes a similar weakness.
📕Related Resource: Learn more about Buffer Overflow.
Malicious Code Examples of Uncontrolled Format String
Uncontrolled format string is another security vulnerability.
It exists when a call is made to a formatted I/O function with a format string containing unsanitized data from an untrusted, external source. This is often referred to as “tainted” data.
Why Uncontrolled Format String Leaves Code Vulnerable
An uncontrolled format string leaves your code vulnerable.
It can allow an attacker to potentially enable the execution of malicious code by:
- Crashing the program.
- Viewing memory content.
- Writing to an arbitrary memory location.
📕 Related Resource: Check out these malicious code examples from CERT.
Preventing Uncontrolled Format String
Be careful when using functions that take a format string as an argument. Example functions include fprintf(), sprintf(), and snprintf().
“Exclude user input from format strings.”
Make sure that untrusted input is not used as part of a format string.
Malicious Code Examples of Signed Integer Overflow
Signed integer overflow is another common security exploit. Overflow occurs when the result of an arithmetic operation is too large to be stored in the underlying representation of the integer.
In C and C++ programming, integer overflow can lead to buffer overflow if it goes undetected.
Malicious Code Examples: Why Signed Integer Overflow Leaves Your Code Vulnerable
Integer overflow results in undefined behavior, so it’s important to ensure that operations on integers do not result in overflow.
In the worst-case scenario, integer overflow can lead to buffer overflows — and the execution of malcode by an attacker.
Malicious Code Examples: Preventing Signed Integer Overflow
“Ensure that operations on signed integers do not result in overflow.”
Integer overflows can be prevented. You can do this by implementing suitable range checks on incoming function parameters.Back to top
Enforce Secure Coding Rules and Prevent Malicious Code with a Static Analysis Tool
The best way to enforce secure coding rules is to use a static analyzer.
A static code analyzer checks code against a set of coding rules, such as those in CERT C/C++, automatically. The best static analyzers — like — include additional rules to ensure best practice coding.
For instance, Klocwork makes it easy to check code against the CERT coding rules mentioned above. And it delivers thousands of diagnostics to improve your code before testing begins — and before security vulnerabilities can compromise your software.
By ensuring these rules are followed, you’ll avoid serious coding errors — and potential malcode vulnerabilities.Back to top