T09 · Insecure Skill Coding Practices
- Location
src/file_protection.py:24- Finding
Sensitive-file protection can be bypassed through symbolic links
- Content
View full analysis
str: file_path_abs = os.path.abspath(os.path.expanduser(file_path)) for level, patterns in self.protection_levels.items(): for pattern in patterns: pattern_abs = os.path.abspath(os.path.expanduser(pattern.replace('*', ''))) if file_path_abs.startswith(pattern_abs): return level return 'allowed' ``` ### Technical Analysis The protection decision is based on the lexical absolute path produced by `os.path.abspath()`. This function normalizes path components but does not resolve symbolic links to their actual filesystem targets. Consequently, an apparently allowed path can be a symbolic link to a critical file. For example, a path beneath `~/projects/` can resolve to `~/.ssh/id_rsa` while the method continues to classify it using the allowed-looking lexical path. The implementation also uses raw string-prefix comparison rather than component-aware path containment. This can cause incorrect classifications where two unrelated directory names share the same prefix. Because `check_file_operation()` returns `{'allowed': True}` for paths that do not lexically match a critical or restricted prefix, callers relying on this result can be induced to operate on a protected target. ### Attack Path 1. An attacker creates a symbolic link such as `~/projects/document` that points to `~/.ssh/id_rsa`. 2. The attacker requests a read, modification, or deletion operation using `~/projects/document`. 3. `_get_protection_level()` applies `abspath()` but does not resolve the symbolic link. 4. The lexical path does not match `~/.ssh/` and is classified as allowed. 5. A caller trusts the returned authorization result and performs the operation. 6. The operating system follows the symbolic link and accesses the ...[truncated 716 chars]- Remediation
View remediation
