fix out-of-bounds write for long -default names in _cupsGetDests

[aizu-m]

AddressSanitizer, running the _cupsGetDests() attribute loop over one printer attribute named 1030×A followed by -default:

heap-buffer-overflow WRITE of size 1
  #0 _cupsGetDests cups/dest.c:1471
6 bytes after a 1024-byte region

optname is a 1024-byte buffer. cupsCopyString() truncates the name into it safely, then the next line terminates it at optname[ptr - attr->name], where ptr = strstr(attr->name, "-default") was taken from the full name. The IPP reader only caps an attribute name at IPP_BUF_SIZE (32767) bytes, so a hostile Get-Printer-Attributes response can carry a name of a few thousand characters ending in -default; the stray NUL then lands well past optname, on the stack frame.

The offset comes from the untruncated source while the write target is the truncated copy. Locating -default in optname itself keeps the write in bounds. Normal names are terminated at the same place, so output is unchanged.

Reached by any client that enumerates printers from an untrusted server, i.e. cupsGetDests/cupsGetNamedDest/cupsEnumDests via CUPS_SERVER or a driverless printer answering discovery.

[michaelrsweet]

Seems like the correct fix here is to ensure that the IPP message parser correctly limits IPP attribute names to a maximum of 255 bytes/octets.

[michaelrsweet]

[master f14d1fd] Limit IPP attribute names to IPP_MAX_KEYWORD (Issue #1694)

[2.4.x d3f2cdc] Limit IPP attribute names to IPP_MAX_KEYWORD (Issue #1694)