Linux code quenching Tool

This section describes open-source tools and code tracing technologies used to improve the security and reliability of Linux applications.
I. Source Code check tools
During software development, we can use source code check tools to identify common programming errors and security vulnerabilities. These tools are not complex to use. The following describes how to use the splint and flawfinder source code check tools.
Splint is a static source code check tool that comprehensively analyzes the source code. For source code without comments, you can use the-weak option:
Splint-weak *. C-I./INC
./Inc is the subdirectory where the header file is located. In addition, splint supports the Standard Check Mode (option-standard). To perform a moderate-intensity check, use option-checks. If option-strict is used, perform the strictest check.
Flawfinder is also a static analysis tool used to find source code errors. The tool provides error messages so that developers can locate the error more quickly. See the following example:
$ Flawfinder test. c
Test. C: 11: [2] (buffer) Char:
Statically-sized arrays can be overflowed. perform bounds
Checking, use functions that limit length, or ensure that
The size is larger than the maximum possible length.
$
In this example, flawfinder provides a prompt indicating the potential danger of malicious use of arrays of static sizes.
In addition to the splint and flawfinder tools described above, there are also available tools such as rats (a security audit tool) and its4 (Static Vulnerability scanning tool. However
Note that although these tools can share part of the work, they cannot completely replace humans. Because tools may also miss security vulnerabilities when detecting vulnerabilities.

Ii. Code Tracking Technology
We know that the strace tool is usually used to track system calls. In fact, it can also be used as an indirect source code audit tool. Tracking the execution of applications from the perspective of system calls can help us understand the underlying operations of Linux applications. With these low-level operations, we can better understand our source code.
In the following example, there are multiple violations of the code quenching principles we discussed earlier. Now we show how to use strace for debugging.
# Include <unistd. h>
# Include <fcntl. h>
# Define max_buckets 128
Int main ()
{
Int FD;
Char Buf [max_buf + 1];
FD = open ("myfile.txt", o_rdonly );
Read (FD, Buf, max_buf );
Printf ("read % s \ n", Buf );
Close (FD );
}
We noticed that the first line of the code above is: FD = open ("myfile.txt", o_rdonly
);
Open a file named myfile.txt, but the file is not checked beforehand. In this case, executing this program will lead to unpredictable results:
$ Gcc-o bad. c
$./Bad
Read @? 8z @
$
Look, you didn't expect the result. So let's use strace to see what happened. Note that the following output has been deleted, but important information is retained:
$ Strace./bad
Execve ("./bad", ["./bad"], [/* 20 vars */]) = 0
Uname ({sys = "Linux", node = "Camus",...}) = 0
...
Open ("myfile.txt", o_rdonly) =-1 enoent (no such file or
Directory)
Read (-1, 0xbfffef20, 128) =-1 ebadf (bad file descriptor)
Fstat64 (1, {st_mode = s_ifchr | 0620, st_rdev = makedev (136, 0),...}) = 0
Mmap2 (null, 4096, prot_read | prot_write, map_private | map_anonymous,
-1, 0) = 0x40017000
Write (1, "read \ 300 \ 357 \ 377 \ 2778z \ 1 @ \ n", 14 read ??? 8z @
) = 14
Close (-1) =-1 ebadf (bad file descriptor)
Munmap (0x40017000,409 6) = 0
Exit_group (-1) =?
$
After the program is executed, we can see that the system call used to start the program is execve (); soon open () was called again, and the system call corresponds to the 11th line in the code. And we can see that the system calls
The return value on the Right of open () is-1, and the error "enoent (no such file or
Directory) ", that is, this file or directory does not exist. In other words, this tells us that we need to create a file first. In addition, the system calls read () and ends with a failure. Its error is invalid.
Because the open call fails.
The strace tool is not only used to understand the behavior of programs with source code, but also effective for programs without source code. Because, by observing system calls, we can understand program behavior at the binary level.

Iii. Summary
The ancients cloud, to do good deeds, must first sharpen their tools. With the help of the Code quenching knowledge introduced above, a debugging tool is used to improve the security and reliability of Linux applications. We believe that readers can develop secure, reliable, and high-quality software faster and better.