CatSearch Search-Spec Validation Is Not Fully Spec-Conformant

[rdmark]

Summary

Validation in catsearch.c does not fully conform to the AFP FPCatSearch / FPCatSearchExt specification.

The validator currently models only the subset of ReqBitmap fields that the
existing parser consumes. As a result, some spec-searchable fields are accepted
without their required search-spec payload, and Specification2 name fields are
accepted even when non-null.

Relevant Specification Requirements

The AFP reference says both FPCatSearch and FPCatSearchExt requests contain:

int32_t ReqBitmap
Specification1
Specification2
unsigned char Length

The specification further states:

• Specification1 and Specification2 are packed in the same order as the bits
  in ReqBitmap.
• Variable-length parameters are stored at the end of each specification record.
  Their offsets are measured from the start of the specification parameters,
  excluding the length and filler bytes.
• Specification1 holds the name target string.
• Specification2 must always have a null name field.
• In date and length fields, Specification1 holds the lower bound and
  Specification2 holds the upper bound.
• In attributes and Finder Info fields, Specification1 holds the target value
  and Specification2 holds the mask.
• The low-order word of ReqBitmap is the same as the low-order word of the
  file and directory bitmaps used by FPGetFileDirParms, except Short Name
  cannot be searched.

Observed Behavior

The new helper catsearch_spec_layout() in etc/afpd/catsearch.c accounts for:

• attributes
• parent directory ID
• creation/modification/backup dates
• Finder Info
• directory offspring count, only when searching directories only
• long name
• PDINFO / UTF-8 name

It does not account for all low-word ReqBitmap fields that are search-spec
fields under the AFP layout, especially file length bits such as data fork and
resource fork length. For example, a file-only search with a file result bitmap
and ReqBitmap bit 9 or 10 set can pass validation with an empty
Specification1 / Specification2, even though the spec describes length
fields as bounds packed into the search specs.

The validator also checks only that name offsets and referenced name data are
within bounds. It does not enforce the spec rule that the name field in
Specification2 must be null.

Why This Is Non-Conformant

The validator now presents itself as a structural validator for CatSearch search
specifications. However, it accepts records that are structurally invalid under
the AFP specification:

1. A ReqBitmap can request a length criterion without the corresponding lower
   and upper bound fields being present in Specification1 and Specification2.
2. A Specification2 name field can be non-null, even though the spec says it
   must always be null.

This means the server can accept malformed or semantically invalid CatSearch
requests instead of returning AFPERR_PARAM or AFPERR_BITMAP.

Expected Behavior

Search-spec validation should match the AFP packing rules:

• For every supported searchable ReqBitmap bit, require the fixed-size field
  or variable-length offset field that the spec requires.
• Reject unsupported or invalid search bits consistently, rather than silently
  ignoring their payload requirements.
• Treat file length fields as range fields when accepted.
• Validate Specification2 name criteria as null.
• Apply the same structural checks to both FPCatSearch and
  FPCatSearchExt, while preserving their different length-prefix formats.

Suggested Tests

Add negative tests for:

• FPCatSearchExt with file-only ReqBitmap data fork length set but empty
  Specification1 / Specification2; expected AFPERR_PARAM or
  AFPERR_BITMAP.
• FPCatSearchExt with resource fork length set but missing the required
  bounds.
• FPCatSearchExt with FILPBIT_LNAME set and a non-null
  Specification2 name.
• The same malformed cases through classic FPCatSearch, since the parser and
  validation path are shared.
• Bad LNAME and PDINFO offsets that point inside the fixed field area or
  beyond the specification record.

Impact

Primarily protocol correctness issues, with possible follow-on risks where
unsupported search criteria are accepted and then ignored.

[NJRoadfan]

Later macOS versions appear to not use FPCatSearchExt() at all if the volume doesn't have Spotlight capability (confirmed with Catalina). They resort to a directory tree crawl using FPEnumerateExt() instead. Just an FYI when testing.

Looking at the Wireshark dissector for AFP, there is apparently a bug in at least one MacOS X client (10.2, possibly 10.3, 10.4 seems correct) that sends a UTF8 offset in Specification 2 that is off by 2 bytes. I think Netatalk handles this already See: wireshark/wireshark@d4c805a

Finally, we resort to slow searches of the directory tree if the volume is not using the DBD backend:

netatalk/etc/afpd/catsearch.c

Line 1395 in 0c0c51c

/* we've got a name and it's a dbd volume, so search CNID database */

[rdmark]

Finally, we resort to slow searches of the directory tree if the volume is not using the DBD backend:

nice catch, this cleans up the obsolete validation:

#3072