From:	 "Steve Zins" <steve@iLabVIEW.com>
To:	 <bugtraq@securityfocus.com>
Subject: LabVIEW Web Server DoS Vulnerability
Date:	 Mon, 22 Apr 2002 22:51:39 -0700

     ... _ . ..._ . _. _.. __.. .. _. ...

Title:      LabVIEW Web Server DoS Vulnerability
Date:       2002-04-22
Vendor:     National Instruments
Software:   LabVIEW Web Server
Versions:   5.1.1 - 6.1
Tested env: Windows 98, 2000; Linux.
Impact:     Malformed HTTP command crashes the LabVIEW Web Server, its
            LabVIEW application host, and other LabVIEW processes (VIs).
Status:     Vendor contacted 17 Apr 2002, test case submitted 18 Apr 2002.
            Vendor put notice on its web site 19 Apr 2002.
Patch:      None.
Workaround: Disable web server logging.
Author:     Steven Zins, steve @ iLabVIEW . com

     ... _ . ..._ . _. _.. __.. .. _. ...


DESCRIPTION:
============
The LabVIEW application is an integrated development system for
creating LabVIEW programs, which are called Virtual Instruments
or VIs. The LabVIEW application can run, or host, VIs in its
own environment. The LabVIEW application can also host its own
Internet servers, including an HTTP or Web server. LabVIEW also
has extensive libraries to interface with real-world test and
measurement equipment, as well as mechanical motion control and
process control equipment.

When the malformed HTTP request described below is received by
the LabVIEW Web Server, the entire LabVIEW application crashes,
including the Web Server, and any other LabVIEW programs, or
VIs, that are running in the application environment. This
amounts to a Denial of Service attack, not only on the web
server, itself, but on any processes hosted in the LabVIEW
application. LabVIEW VIs performing real-world processes could
be interrupted by this type of attack.

National Instruments has confirmed this exploit and has
published a response in their KnowledgeBase, referenced below.
This states that the crash will occur only when web server
logging is enabled.

While this is demonstrably a Denial of Service vulnerability,
it might also be exploitable with a buffer overflow attack.

I strongly recommend that (1) LabVIEW Web Servers be run only
with logging disabled and that (2) any LabVIEW application that
is running a LabVIEW Web server does not also run processes that
could cause real-world damage if interrupted.


EXPLOIT:
========
The LabVIEW Web Server crashes when it processes the following
malformed HTTP request:

      GET\s/\sHTTP/1.0\n\n

This request is malformed because RFC 1945 for HTTP 1.0
specifies that header lines should be separated by CRLF (\r\n),
not just LF (\n) as shown here.  The header should be ended by
two adjacent CRLF sequences.  But a server should not crash
when it processes this sequence.

The server crashes only when the Web Server logging is disabled.


REFERENCES:
===========
National Instruments - http://www.ni.com/
LabVIEW - http://sine.ni.com/apps/we/nioc.vp?cid=1381&lang=US
National Instruments KnowledgeBase notification -
http://digital.ni.com/public.nsf/websearch/4C3F86E655E5389886256BA00064B22F?
OpenDocument


Disclaimer:
===========
Steven Zins is not responsible for the misuse of the information
provided in this advisory. The opinions expressed are my own
and not of any company. In no event shall the author be liable
for any damages whatsoever arising out of or in connection with
the use or spread of this advisory. Any use of the information
is at the user's own risk.


Feedback:
=========
Please send suggestions and comments to:
Steven Zins, steve @ iLabVIEW . com

      ... _ . ..._ . _. _.. __.. .. _. ...