OpenAFS Master Repository branch, master, updated. openafs-devel-1_5_76-4727-g5f70b79

[Gerrit Code Review]

The following commit has been merged in the master branch:
commit 5f70b79817f98b5f482414a4ec849bd4bd15a5d6
Author: Jeffrey Altman <jaltman@your-file-system.com>
Date:   Thu Oct 8 22:22:12 2015 -0400

    rx: OPENAFS-SA-2015-007 "Tattletale"
    
    CVE-2015-7762:
    
    The CMU/Transarc/IBM definition of rx_AckDataSize(nAcks) was mistakenly
    computed from sizeof(struct rx_ackPacket) and inadvertently added three
    octets to the computed ack data size due to C language alignment rules.
    When constructing ack packets these three octets are not assigned a
    value before writing them to the network.
    
    Beginning with AFS 3.3, IBM extended the ACK packet with the "maxMTU" ack
    trailer value which was appended to the packet according to the
    rx_AckDataSize() computation.  As a result the three unassigned octets
    were unintentionally cemented into the ACK packet format.
    
    In OpenAFS commit 4916d4b4221213bb6950e76dbe464a09d7a51cc3 Nickolai
    Zeldovich <kolya@mit.edu> noticed that the size produced by the
    rx_AckDataSize(nAcks) macro was dependent upon the compiler and processor
    architecture.  The rx_AckDataSize() macro was altered to explicitly
    expose the three octets that are included in the computation.
    Unfortunately, the failure to initialize the three octets went unnoticed.
    
    The Rx implementation maintains a pool of packet buffers that are reused
    during the lifetime of the process.  When an ACK packet is constructed
    three octets from a previously received or transmitted packets will be
    leaked onto the network.  These octets can include data from a
    received packet that was encrypted on the wire and then decrypted.
    
    If the received encrypted packet is a duplicate or if it is outside the
    valid window, the decrypted packet will be used immediately to construct
    an ACK packet.
    
    CVE-2015-7763:
    
    In OpenAFS commit c7f9307c35c0c89f7ec8ada315c81ebc47517f86 the ACK packet
    was further extended in an attempt to detect the path MTU between two
    peers.  When the ACK reason is RX_ACK_PING a variable number of octets is
    appended to the ACK following the ACK trailers.
    
    The implementation failed to initialize all of the padding region.
    A variable amount of data from previous packets can be leaked onto the
    network.  The padding region can include data from a received packet
    that was encrypted on the wire and then decrypted.
    
    OpenAFS 1.5.75 through 1.5.78 and all 1.6.x releases (including release
    candidates) are vulnerable.
    
    Credits:
    
      Thanks to John Stumpo for identifying both vulnerabilities.
    
      Thanks to Simon Wilkinson for patch development.
    
      Thanks to Ben Kaduk for managing the security release cycle.
    
    Change-Id: I29e47610e497c0ea94033450f434da11c367027c

 src/rx/rx.c |   34 ++++++++++++++++++++++------------
 1 files changed, 22 insertions(+), 12 deletions(-)

-- 
OpenAFS Master Repository