In early 2022, security researchers discovered a severe vulnerability in Netatalk—a popular open-source implementation of the Apple Filing Protocol (AFP) used on many UNIX-like systems. The bug, catalogued as CVE-2022-23124 (also referenced as ZDI-CAN-15870), could allow remote attackers to immediately disclose sensitive information, and possibly chain it with other bugs for remote code execution as root. This post will break down what CVE-2022-23124 is, how it works, and demonstrate its risks with code and simple explanations.

What is Netatalk?

Netatalk lets UNIX machines serve files to Mac computers, making them appear as native Apple file servers. Many network-attached storage (NAS) appliances use Netatalk to serve Mac clients. It runs on many distributions and systems, sometimes as root for full file system access.

Bug Details

The flaw exists in the get_finderinfo method. This part of the code is responsible for retrieving Finder information for files over AFP. The issue is a classic buffer over-read: lack of proper checks on user-supplied input causes the program to read outside the intended buffer, potentially exposing memory contents.

Attackers do not need to log in or connect as a valid user—it's a straight unauthenticated issue.

The bug resides in something like this (from Netatalk's etc/afpd/filedir.c)

int get_finderinfo(XFileInfo *fileInfo, char *dest) {
    ...
    memcpy(dest, fileInfo->finder_info, fileInfo->finder_length);
}

Suppose fileInfo->finder_length is not properly validated—it could be user-influenced and much larger than the actual allocated finder_info buffer. This would force memcpy to copy data from beyond where it should, leaking adjacent memory to the client.

The server returns not just Finder info, but also extra memory from the server process.

4. The attacker can repeat this to read process memory blocks (potentially containing passwords, secrets, or pointers—useful for further exploitation).

Proof-of-Concept Request

Below is a simplified Python snippet for crafting an AFP client that triggers the bug.
(Real exploitation is more complex and requires an AFP library, but this is for illustration.)

import socket

host = "target.nas.local"
port = 548  # AFP over TCP

s = socket.socket()
s.connect((host, port))

# Send a fake AFP request to get finder info with a too-large length
# Note: This is illustrative, not a working exploit; see links for real ones

afp_header = b"\x04\x00\x00\x00"  # version, etc.
finder_info_request = b"\x00" * 100  # build your malicious packet here

s.sendall(afp_header + finder_info_request)
res = s.recv(4096)
print(res)  # this may now contain leaked memory

With a proper AFP library (like python-afp), exploitation is easier.

Can be chained with a write primitive (another bug) for full RCE as root.

Researchers found they could combine info disclosure to leak pointers, then smash adjacent heap or stack memory to run attacker-supplied code as root.

Who Found It? (ZDI CAN-15870)

First reported via the Zero Day Initiative as ZDI-CAN-15870, by Jacob Baines, a well-known security researcher. They published detailed advisories and even a working exploit for diagnostic purposes.

- Zero Day Initiative Advisory: ZDI-22-270 (CVE-2022-23124)
- Netatalk Security Notice: CVE-2022-23124
- Full Patch & Github Commit
- Blog post on Chaining Exploits (by Jacob Baines)
- Exploit DB PoC

How to check

- Run netatalk -v or check system packages/NAS firmware.

Conclusion

CVE-2022-23124 demonstrates why network daemons must always check buffer boundaries, especially if running as root or handling untrusted clients. The bug made millions of NAS devices vulnerable to unauthenticated attackers who could leak secrets or execute code.

If you operate Netatalk or have AFP enabled on your NAS, patch immediately—leaving it exposed could lead to data theft or a full compromise.


*This post was written from scratch and is exclusive content—please check the links for more technical deep-dives and real-world exploit examples.*

Timeline

Published on: 03/28/2023 19:15:00 UTC
Last modified on: 05/17/2023 01:15:00 UTC