207 - Git Config Injection and a Sophos Pre-Auth RCE
A logic bug when dealing with the parsing of the git/.config
file, which could be triggered via git submodules. The relevant function for the vuln here is git_config_copy_or_rename_section_in_file()
, which would remove or rename configuration sections in-place in the config file. It would take config lines via fgets()
into a 1KB buffer, though if the input exceeded 1024 bytes, it would call fgets()
again and create a new line entry in the config file even if one wasn’t present before. This can allow an attacker to inject arbitrary sections in the git config, including one to run a shell command to get code execution.
Impact is somewhat limited because triggering this issue requires the victim to deinitialize, remove, or rename a submodule with a large URL, which not only requires user interaction but is also unlikely.
CVE-2023-27322 - Local Privilege Escalation Through Parallels Service
First a little bit of background about bash and privileged mode. Normally the Bash shell will drop privileges when it is started under a setuid/setgid situation. It will set the effective user/group identifiers to that of the real identifiers. Privileged mode will retain the (presumably) more privileged effective identifiers, but lock itself down a little to limit the degree of control the original user has over Bash’s execution. It won’t process the $ENV
or $BASH_ENV
files, shell functions won’t be inherited from the environments.
The interesting thing here is how privileges change across child processes. We start with the original Parallels Service, which is a setuid and setgid binary. It will execute an embeded script within a non-interactive Bash shell. To do so it makes a call to setuid(geteuid())
setting the real uid to the effective uid (root), then it calls fork()
and execv
to spawn a bash shell. Importantly here execv
wraps execve
passing in the current (attacker controlled) environment to the newly spawned process. This newly spawned process, despite the earlier setuid
binary will be detected as a setgid
execution, prompted Bash to automatically drop its privileges and ignore processing the environment variables. At this stage bash is properly dropping its privileged and not allowing the original user to influence execution.
However, the script continues, it spawns its own child process a watchdog
script. Whats interesting this time is that because Bash “dropped” the privileges, when this nested script executes, its process will be called with the effective and real user/group identifiers matching, so Bash won’t know to restrict itself. This nested call, will trust the environment values and so an attacker could provide malicious shell functions that would be inherited not by the first embedded script but by the further nested watchdog script.
The post also covers a couple more bugs, one with prl_update-helper
invoking the inittool
script, this one is a bit more direct. It is (presumably) not a setgid binary, and before invoking the script it uses a setuid(geteuid())
call, so it runs as root and does not restrict itself. Similarly inittool2
executable is invoked from the inittool
script. inittool2
will fork a child process to execute an embedded script which can be abused.
Straight forward XSS, Synk would rended HTML inside of the Markdown in a package’s readme file as is. So a simple payload like <img src=x onerror="alert(document.domain)">
would be sufficent for XSS. Whats fun about this post is the attack strategy, manipulating their package health score to appear more legitimate, potentially fooling people into installing a malicious package because it appears healthy.