[PATCH] Remove hardcoded static string length

[Jeffrey E Altman]

On 5/25/2023 11:37 AM, Kenny Ho wrote:
> On Thu, May 25, 2023 at 11:04 AM David Laight<David.Laight at aculab.com>  wrote:
>>> "The standard formulation seems to be: <project> <version> built
>>> <yyyy>-<mm>-<dd>"
>> Which I don't recall the string actually matching?
>> Also the people who like reproducible builds don't like __DATE__.
> That's correct, it was not matching even when it was introduced.  I am
> simply taking that as people caring about the content and not simply
> making rxrpc_version_string == UTS_RELEASE.  The current format is:
>
> "linux-" UTS_RELEASE " AF_RXRPC"
>
> Kenny

The RX_PACKET_TYPE_VERSION query is issued by the "rxdebug <host> <port> 
-version" command which prints the received string to stdout.   It has 
also been used some implementations to record the version of the peer.   
Although it is required that a response to the RX_PACKET_TYPE_VERSION 
query be issued, there is no requirement that the returned string 
contain anything beyond a single NUL octet.

Although it is convenient to be able to remotely identify the version of 
an Rx implementation, there are good reasons why this information should 
not be exposed to an anonymous requester:

 1. Linux AF_RXRPC is part of the kernel.  As such, returning
    UTS_RELEASE identifies to potential attackers the explicit kernel
    version, architecture and perhaps distro.  As this query can be
    issued anonymously, this provides an information disclosure that can
    be used to target known vulnerabilities in the kernel.
 2. The RX_PACKET_TYPE_VERSION reply is larger than the query by the
    number of octets in the version data.  As the query is received via
    udp with no reachability test, it means that the
    RX_PACKET_TYPE_VERSION query/response can be used to perform an 3.3x
    amplification attack: 28 octets in and potentially 93 octets out.

With my security hat on I would suggest that either AF_RXRPC return a 
single NUL octet or the c-string "AF_RXRPC" and nothing more.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20230527/41585db7/attachment-0001.p7s>