Revision f5c7f5dfbaf0d2f7d946d0fe86f08e6bcb36ed0d authored by Matt Caswell on 30 June 2016, 12:17:08 UTC, committed by Matt Caswell on 22 August 2016, 09:53:55 UTC
DTLS can handle out of order record delivery. Additionally since handshake messages can be bigger than will fit into a single packet, the messages can be fragmented across multiple records (as with normal TLS). That means that the messages can arrive mixed up, and we have to reassemble them. We keep a queue of buffered messages that are "from the future", i.e. messages we're not ready to deal with yet but have arrived early. The messages held there may not be full yet - they could be one or more fragments that are still in the process of being reassembled. The code assumes that we will eventually complete the reassembly and when that occurs the complete message is removed from the queue at the point that we need to use it. However, DTLS is also tolerant of packet loss. To get around that DTLS messages can be retransmitted. If we receive a full (non-fragmented) message from the peer after previously having received a fragment of that message, then we ignore the message in the queue and just use the non-fragmented version. At that point the queued message will never get removed. Additionally the peer could send "future" messages that we never get to in order to complete the handshake. Each message has a sequence number (starting from 0). We will accept a message fragment for the current message sequence number, or for any sequence up to 10 into the future. However if the Finished message has a sequence number of 2, anything greater than that in the queue is just left there. So, in those two ways we can end up with "orphaned" data in the queue that will never get removed - except when the connection is closed. At that point all the queues are flushed. An attacker could seek to exploit this by filling up the queues with lots of large messages that are never going to be used in order to attempt a DoS by memory exhaustion. I will assume that we are only concerned with servers here. It does not seem reasonable to be concerned about a memory exhaustion attack on a client. They are unlikely to process enough connections for this to be an issue. A "long" handshake with many messages might be 5 messages long (in the incoming direction), e.g. ClientHello, Certificate, ClientKeyExchange, CertificateVerify, Finished. So this would be message sequence numbers 0 to 4. Additionally we can buffer up to 10 messages in the future. Therefore the maximum number of messages that an attacker could send that could get orphaned would typically be 15. The maximum size that a DTLS message is allowed to be is defined by max_cert_list, which by default is 100k. Therefore the maximum amount of "orphaned" memory per connection is 1500k. Message sequence numbers get reset after the Finished message, so renegotiation will not extend the maximum number of messages that can be orphaned per connection. As noted above, the queues do get cleared when the connection is closed. Therefore in order to mount an effective attack, an attacker would have to open many simultaneous connections. Issue reported by Quan Luo. CVE-2016-2179 Reviewed-by: Richard Levitte <levitte@openssl.org>
1 parent 5dfd038
shlib_wrap.sh
#!/bin/sh
[ $# -ne 0 ] || set -x # debug mode without arguments:-)
THERE="`echo $0 | sed -e 's|[^/]*$||' 2>/dev/null`.."
[ -d "${THERE}" ] || exec "$@" # should never happen...
# Alternative to this is to parse ${THERE}/Makefile...
LIBCRYPTOSO="${THERE}/libcrypto.so"
if [ -f "$LIBCRYPTOSO" ]; then
while [ -h "$LIBCRYPTOSO" ]; do
LIBCRYPTOSO="${THERE}/`ls -l "$LIBCRYPTOSO" | sed -e 's|.*\-> ||'`"
done
SOSUFFIX=`echo ${LIBCRYPTOSO} | sed -e 's|.*\.so||' 2>/dev/null`
LIBSSLSO="${THERE}/libssl.so${SOSUFFIX}"
fi
SYSNAME=`(uname -s) 2>/dev/null`;
case "$SYSNAME" in
SunOS|IRIX*)
# SunOS and IRIX run-time linkers evaluate alternative
# variables depending on target ABI...
rld_var=LD_LIBRARY_PATH
case "`(/usr/bin/file "$LIBCRYPTOSO") 2>/dev/null`" in
*ELF\ 64*SPARC*|*ELF\ 64*AMD64*)
[ -n "$LD_LIBRARY_PATH_64" ] && rld_var=LD_LIBRARY_PATH_64
LD_PRELOAD_64="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_64
preload_var=LD_PRELOAD_64
;;
*ELF\ 32*SPARC*|*ELF\ 32*80386*)
# We only need to change LD_PRELOAD_32 and LD_LIBRARY_PATH_32
# on a multi-arch system. Otherwise, trust the fallbacks.
if [ -f /lib/64/ld.so.1 ]; then
[ -n "$LD_LIBRARY_PATH_32" ] && rld_var=LD_LIBRARY_PATH_32
LD_PRELOAD_32="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_32
preload_var=LD_PRELOAD_32
fi
;;
# Why are newly built .so's preloaded anyway? Because run-time
# .so lookup path embedded into application takes precedence
# over LD_LIBRARY_PATH and as result application ends up linking
# to previously installed .so's. On IRIX instead of preloading
# newly built .so's we trick run-time linker to fail to find
# the installed .so by setting _RLD_ROOT variable.
*ELF\ 32*MIPS*)
#_RLD_LIST="$LIBCRYPTOSO:$LIBSSLSO:DEFAULT"; export _RLD_LIST
_RLD_ROOT=/no/such/dir; export _RLD_ROOT
eval $rld_var=\"/usr/lib'${'$rld_var':+:$'$rld_var'}'\"
preload_var=_RLD_LIST
;;
*ELF\ N32*MIPS*)
[ -n "$LD_LIBRARYN32_PATH" ] && rld_var=LD_LIBRARYN32_PATH
#_RLDN32_LIST="$LIBCRYPTOSO:$LIBSSLSO:DEFAULT"; export _RLDN32_LIST
_RLDN32_ROOT=/no/such/dir; export _RLDN32_ROOT
eval $rld_var=\"/usr/lib32'${'$rld_var':+:$'$rld_var'}'\"
preload_var=_RLDN32_LIST
;;
*ELF\ 64*MIPS*)
[ -n "$LD_LIBRARY64_PATH" ] && rld_var=LD_LIBRARY64_PATH
#_RLD64_LIST="$LIBCRYPTOSO:$LIBSSLSO:DEFAULT"; export _RLD64_LIST
_RLD64_ROOT=/no/such/dir; export _RLD64_ROOT
eval $rld_var=\"/usr/lib64'${'$rld_var':+:$'$rld_var'}'\"
preload_var=_RLD64_LIST
;;
esac
eval $rld_var=\"${THERE}'${'$rld_var':+:$'$rld_var'}'\"; export $rld_var
unset rld_var
;;
*) LD_LIBRARY_PATH="${THERE}:$LD_LIBRARY_PATH" # Linux, ELF HP-UX
DYLD_LIBRARY_PATH="${THERE}:$DYLD_LIBRARY_PATH" # MacOS X
SHLIB_PATH="${THERE}:$SHLIB_PATH" # legacy HP-UX
LIBPATH="${THERE}:$LIBPATH" # AIX, OS/2
export LD_LIBRARY_PATH DYLD_LIBRARY_PATH SHLIB_PATH LIBPATH
# Even though $PATH is adjusted [for Windows sake], it doesn't
# necessarily does the trick. Trouble is that with introduction
# of SafeDllSearchMode in XP/2003 it's more appropriate to copy
# .DLLs in vicinity of executable, which is done elsewhere...
if [ "$OSTYPE" != msdosdjgpp ]; then
PATH="${THERE}:$PATH"; export PATH
fi
;;
esac
if [ -f "$LIBCRYPTOSO" -a -z "$preload_var" ]; then
# Following three lines are major excuse for isolating them into
# this wrapper script. Original reason for setting LD_PRELOAD
# was to make it possible to pass 'make test' when user linked
# with -rpath pointing to previous version installation. Wrapping
# it into a script makes it possible to do so on multi-ABI
# platforms.
case "$SYSNAME" in
*BSD|QNX) LD_PRELOAD="$LIBCRYPTOSO:$LIBSSLSO" ;; # *BSD, QNX
*) LD_PRELOAD="$LIBCRYPTOSO $LIBSSLSO" ;; # SunOS, Linux, ELF HP-UX
esac
_RLD_LIST="$LIBCRYPTOSO:$LIBSSLSO:DEFAULT" # Tru64, o32 IRIX
DYLD_INSERT_LIBRARIES="$LIBCRYPTOSO:$LIBSSLSO" # MacOS X
export LD_PRELOAD _RLD_LIST DYLD_INSERT_LIBRARIES
fi
cmd="$1"; [ -x "$cmd" ] || cmd="$cmd${EXE_EXT}"
shift
if [ $# -eq 0 ]; then
exec "$cmd" # old sh, such as Tru64 4.x, fails to expand empty "$@"
else
exec "$cmd" "$@"
fi

Computing file changes ...