Use of inherently dangerous function (unsafe package)

• Rule ID: go_gosec_unsafe_unsafe
• Languages: go
• Source: unsafe.yml

Description

The Go programming language features the unsafe package which grants low-level memory management capabilities, inclusive of direct memory access and pointer manipulation. Though the unsafe package can be quite potent, its usage sidesteps the Go compiler's type safety checks. This can lead to an array of security vulnerabilities and unpredictable system behavior.

Remediations

✅ Avoid unsafe Unless Absolutely Necessary

The overarching guidance here is to steer clear of the unsafe package unless there's an absolute necessity for its functions. When opting for low-level memory operations, ensure that their implications are well-understood and that their deployment is preceded by rigorous testing.

✅ Be Wary of Buffer Overflows

Direct manipulation of memory can lead to buffer overflows, potentially enabling unauthorized code execution. Ensure buffer boundaries are always respected.

✅ Avoid Use After Free

Accessing memory that has already been freed can result in unintended code execution or unpredictable behaviors. Ensure that once memory has been freed, it isn't accessed further.

✅ Prevent Information/Memory Leaks

Unintended memory retention or unintended disclosure of information in memory can occur when using unsafe functions. This can compromise other security defenses or lead to system failures due to exhausted memory. Regularly review and audit your code to check for such leaks.

Resources

• Buffer Overflows - OWASP
• Using Freed Memory - OWASP
• Memory Leaks - OWASP

Associated CWE

• CWE-242: Use of Inherently Dangerous Function

Configuration

To skip this rule during a scan, use the following flag

bearer scan /path/to/your-project/ --skip-rule=go_gosec_unsafe_unsafe

To run only this rule during a scan, use the following flag

bearer scan /path/to/your-project/ --only-rule=go_gosec_unsafe_unsafe