Skip to main content
  • Home
  • login
  • Browse the archive

    swh mirror partner logo
swh logo
SoftwareHeritage
Software
Heritage
Mirror
Features
  • Search

  • Downloads

  • Save code now

  • Add forge now

  • Help

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
Fix DTLS buffered message DoS attack
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
  • Files
  • Changes
  • c0c9b13
  • /
  • util
  • /
  • shlib_wrap.sh
Raw File
Cook and download a directory from the Software Heritage Vault

You have requested the cooking of the directory with identifier None into a standard tar.gz archive.

Are you sure you want to continue ?

Download a directory from the Software Heritage Vault

You have requested the download of the directory with identifier None as a standard tar.gz archive.

Are you sure you want to continue ?

Cook and download a revision from the Software Heritage Vault

You have requested the cooking of the history heading to revision with identifier swh:1:rev:f5c7f5dfbaf0d2f7d946d0fe86f08e6bcb36ed0d into a bare git archive.

Are you sure you want to continue ?

Download a revision from the Software Heritage Vault

You have requested the download of the history heading to revision with identifier swh:1:rev:f5c7f5dfbaf0d2f7d946d0fe86f08e6bcb36ed0d as a bare git archive.

Are you sure you want to continue ?

Invalid Email !

The provided email is not well-formed.

Download link has expired

The requested archive is no longer available for download from the Software Heritage Vault.

Do you want to cook it again ?

Permalinks

To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Hash IDentifiers (SWHIDs) must be used.
Select below a type of object currently browsed in order to display its associated SWHID and permalink.

  • revision
  • content
revision badge
swh:1:rev:f5c7f5dfbaf0d2f7d946d0fe86f08e6bcb36ed0d
content badge Iframe embedding
swh:1:cnt:ce463f17e8229183cde9719118dcb190e8d173ae
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
The diff you're trying to view is too large. Only the first 1000 changed files have been loaded.
Showing with 0 additions and 0 deletions (0 / 0 diffs computed)
swh spinner

Computing file changes ...

ENEA — Copyright (C), ENEA. License: GNU AGPLv3+.
Legal notes  ::  JavaScript license information ::  Web API

back to top