Libraries and system utilities form the foundations on which larger projects are built. So it's critical to make sure they, in particular, are secure. That's why we recently introduced five new rules for C++ and C to detect broken authentication and access control in *nix systems. The new rules fall into three categories: account validity, granting permissions, and changing directories. Account validity For account validity, we've added a Security Vulnerability rule: - Account validity should be verified when authenticating users with PAM. It turns out that it's entirely possible for a user with an invalid account - one that is locked or expired - to authenticate successfully. As a utility writer, you need to verify successful authentication account validity. Otherwise, you could be letting in people who wish the organization harm, such as a former employee whose account has been disabled. S5832 both and Granting permissions For setting permissions, we've added two new Security Hotspots rules. As a reminder, are a separate class of security-related issues. When we raise a Security Hotspot on your code, we're saying there's definitely something wrong that you need to fix. What we're saying is that there's the for something to be wrong depending on the context of the code, and human review is needed. The Security Hotspot rules we've added for permission setting are: Security Hotspots not potential - Setting loose POSIX file permissions is security-sensitive S2612 - Setting capabilities is security-sensitive S5849 With both of these rules, the idea is to double-check that the permissions you've granted can't be tightened up. S2612 raises a Security Hotspot when you grant permissions to `others`. That one should be pretty obvious to most people, but the one about capabilities is a little more obscure. Linux "capabilities" allow you to assign narrow slices of `root`'s permissions to files (executables) and processes. One of the dangers is that people may be less cautious about assigning a capability than full `root` privileges. Assigning narrow slices is better than granting full `root` access, but most capabilities can to escalate privileges to full `root` level, so they should be used with the same care as full `root`. be exploited Changing directories For changing directories, we've added two more Security Hotspots: - Changing directories improperly when using "chroot" is security-sensitive S5802 - Changing working directories without verifying the success is security-sensitive S5982 Both of these rules revolve around thinking you've limited a process to a directory without actually accomplishing that. Theoretically, `chroot` changes the root directory of a process, thus "jailing" it away from the rest of the filesystem. But according to the description of S5802, 'many chroot function implementations don't modify the current working directory, thus the process still has access to unauthorized resources outside of the "jail"' if you don't change your current working directory (`chdir`) to the new root directory. also So okay, let's say you `chdir` to the jail directory before you `chroot`. You're good, right? Not necessarily. `chdir` won't work if you don't have access to the directory. And that's what S5982 is about - making sure your `chdir` worked before you go any further. These new rules are available today in and on . Together, they'll help you write more secure *nix utilities and libraries, laying a strong foundation for the applications that will be built on top of them. SonarQube SonarCloud Previously published at https://blog.sonarsource.com/lay-a-strong-foundation-with-secure-c-and-cpp-utilities

Too Long; Didn't Read

Making security fun one episode at a time

Lay a strong foundation by writing secure C and C++ utilities

Too Long; Didn't Read

SonarSource

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Lay a strong foundation by writing secure C and C++ utilities

Too Long; Didn't Read

SonarSource

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES