simon-git: putty (master): putty.git

[Commits to Tartarus hosted VCS]

TL;DR:
  54cc0c5 Tweak bounds checks in pageant_add_keyfile.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer:      putty.git
Date:           2017-01-29 22:50:50

commit 54cc0c5b296ee7c27b48a3c8e7aead6e74f2abf1
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=54cc0c5b296ee7c27b48a3c8e7aead6e74f2abf1;hp=4ff22863d895cb7ebfced4cf923a012a614adaa8
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Jan 23 20:08:18 2017 +0000

    Tweak bounds checks in pageant_add_keyfile.
    
    When we're going through the response from an SSH agent we asked for a
    list of keys, and processing the string lengths in the SSH-2 sequence
    of (public blob, comment) pairs, we were adding 4 to each string
    length, and although we checked if the result came out to a negative
    value (if interpreted as a signed integer) or a positive one going
    beyond the end of the response buffer, we didn't check if it wrapped
    round to a positive value less than 4. As a result, if an agent
    returned malformed data sent a length field of 0xFFFFFFFC, the pointer
    would advance no distance at all through the buffer, and the next
    iteration of the loop would check the same length field again.
    
    (However, this would only consume CPU pointlessly for a limited time,
    because the outer loop up to 'nkeys' would still terminate sooner or
    later. Also, I don't think this can sensibly be classed as a serious
    security hazard - it's arguably a borderline DoS, but it requires a
    hostile SSH _agent_ if data of that type is to be sent on purpose, and
    an untrusted SSH agent is not part of the normal security model!)

 pageant.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)