Preface: The heap is an area of dynamically-allocated memory that is managed automatically by the operating system or the memory manager library. Memory on the heap is allocated, deallocated, and resized regularly during program execution, and this can lead to a problem called fragmentation.
For instance, when you download a c++ compiler for your platform, you, in fact, download the c++ frontend with the linux-amd64 backend. This coding architecture is extremely helpful, because it allows to port the compiler for another architecture without rewriting the whole parsing/optimizing thing.
When applications need memory, they have to request it from the operating system. This request from the kernel will naturally require a system call. You cannot allocate memory yourself in user mode. The malloc() family of functions is responsible for memory allocation in the C language. The question to ask here is whether malloc(), as a glibc function, makes a direct system call. There is no system call called malloc in the Linux kernel. However, there are two system calls for applications memory demands, which are brk and mmap.
By far the most widely used C library on Linux is the GNU C library, often referred to as glibc. The pathname /lib/libc[.]so[.]6 (or something similar) is normally a symbolic link that points to the location of the glibc library, and executing this pathname will cause glibc to display various information about the version installed on your system.
Vulnerability details: Sudo 1.8.0 through 1.9.12, with the crypt() password backend, contains a plugins/sudoers/auth/passwd[.]c array-out-of-bounds error that can result in a heap-based buffer over-read. This can be triggered by arbitrary local users with access to sudo by entering a password of seven characters or fewer. The impact could vary depending on the compiler and processor architecture.
What is the difference between su and sudo?
- su allows to run commands with a substitute user and group ID.
- sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy. The invoking user’s real (not effective) user-ID is used to determine the user name with which to query the security policy.
Remedy: Please refer to the link for details – https://github.com/sudo-project/sudo/commit/bd209b9f16fcd1270c13db27ae3329c677d48050