libSM: Changes to 'master'

[GitLab Mirror]

 configure.ac     |    2 
 src/SMlibint.h   |   74 ------------
 src/sm_process.c |  318 +++++++++++++++++++++++++++++++++++++++----------------
 3 files changed, 230 insertions(+), 164 deletions(-)

New commits:
commit a52c79544fcd6b5e2242b9122dfaa34be07aebb2
Author: Matthieu Herrb <matthieu at herrb.eu>
Date:   Sun Sep 30 11:03:41 2018 +0200

    libSM 1.2.3
    
    Signed-off-by: Matthieu Herrb <matthieu at herrb.eu>

commit d86106f2369ecf81155decaa360f9162c0c3cd53
Author: Tobias Stoeckmann <tobias at stoeckmann.org>
Date:   Wed Aug 15 21:21:09 2018 +0200

    Fixed out ouf boundary accesses.
    
    Out of boundary accesses can occur while processing messages. This
    affects clients and the session server.
    
    Generally, the code tries to prevent out of boundary accesses. It
    initially "skips" over the memory areas by parsing supplied lengths.
    Then, it checks if it skipped over the memory boundary. If not, then
    data is actually read and memory allocated, etc.
    
    The problem is that while initially skipping over the memory,
    subsequent lengths are already parsed, i.e. accessed. This results in
    out of boundary reads on hostile messages.
    
    Lengths could also overflow on 32 bit systems, leading to out of
    boundary writes if not enough bytes have been allocated.
    
    Authentication is handled by libICE, which is not affected, because the
    macros for skipping already take care about memory boundaries.
    
    Therefore, this flaw can only be used by authenticated clients or by
    hostile servers (which could simply accept every MIT cookie). Most
    session managers only use Unix sockets, so in many cases it takes a
    local authenticated user.
    
    In order to fix this, I decided to move the macros from SMlibint.h to
    its only callers in sm_process.c, turning them into functions for much
    easier error handling and readability.
    
    Instead of skipping over the memory, validation happens during actual
    read and memory allocation operations, as it's rather unlikely to
    encounter hostile code anyway, i.e. my code has more error cleanup
    handling in it.
    
    Signed-off-by: Tobias Stoeckmann <tobias at stoeckmann.org>
    Reviewed-by: Matthieu Herrb <matthieu at herrb.eu>