OpenAFS Master Repository branch, openafs-stable-1_6_15, created. openafs-stable-1_6_14_1-3-g3994c23

[Gerrit Code Review]

The branch, openafs-stable-1_6_15 has been created
        at  3994c23187d42164a1f3d3b5ddedd59525417864 (commit)

- Shortlog ------------------------------------------------------------
commit 3994c23187d42164a1f3d3b5ddedd59525417864
Author: Jeffrey Altman <jaltman@your-file-system.com>
Date:   Wed Oct 28 09:06:44 2015 -0400

    VERSION: 1.6.15
    
    Update configure version strings for 1.6.15.
    
    Change-Id: I1b730216b982b7c327730b1d0cf4061666f0fa8d

commit d12f72f1afcdee1076287a7fc41f8abcaae4ddc4
Author: Jeffrey Altman <jaltman@your-file-system.com>
Date:   Wed Oct 28 08:49:20 2015 -0400

    NEWS: Update for 1.6.15
    
    Security vulnerability release.  Document OPENAFS-SA-2015-007.
    
    Change-Id: Id36480024fbdac7d3478bec7f3026b2c05bc37f0

commit 9191cdfc9b2f00d320e775031bb3be1173302e5b
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

-----------------------------------------------------------------------

-- 
OpenAFS Master Repository