Bit of a logic bug/abuse resulting in the ability to write files with semi-controlled content in any directory regardless of privileges. Under normal circumstances when a suid binary crashes, it will be considered non-dumpable, more generally speaking, when a process has a difference between its real and effective group or user ids it will not be dumped.

This little bit of logic can be abused when you consider how some suid binaries work, such as sudo which is a suid binary, and will start off as root and not be dumpable, it will adopt a specified user/group (usually root/uid=0,gid=0) and then execute another program. So what ends up happening is that while sudo will not be dumpable, after it changes its uid/gid then executes a new (non-suid) binary that new binary will be dumpable, and the dump will be written with what ever privileges the process has (root). This attack can work with other suid binaries also.

Once you’ve gained this write-anywhere primitive to exploit it Aleph Security take advantage of a few things:

• First, they must be able to cause the final program to crash, the post covers a couple methods to do this, neither rely on any special privileges.
• Then they need to gain some control over the data being written by the core dump. This is accomplished through environment variables, specifically they found the AUTHORITY environment will be inherited and passed into the target binary by sudo.
• logrotate has a permissive configuration parser that will ignore any binary data in the file
• logrotate can run arbitrary commands through the firstaction script in the configuration

1. Sets the XAUTHORITY environment variable to a configuration including the code you want to execute as the firstaction.
2. Changed the current working directory to /etc/logrotate.d
   • Dumps are written to the current directory unless specified otherwise in system config
3. Sets RLIMIT_CPU to 0
4. Sets RLIMIT_CORE to infinity
   • This is so a core dump is written at all
5. Executes sudo with their target binary as the target

This sudo example does depend on being in /etc/sudoers and being able to execute atleast one binary as root. This is definitely a bit of an ask for the exploitable scenario but not impossible. It is not entirely unheard of for systems to be configured where certain users have access to only a particular binary with sudo, but it does require some extra configuration beyond the default.