mailing list archives
Re: Trustwave's SpiderLabs Security Advisory TWSL2010-001
From: David Byrne <DByrne () trustwave com>
Date: Fri, 12 Feb 2010 20:50:13 -0600
I respectfully defend our statement as very realistic. The .Net exploit provided in the advisory is all that is
required to work; no code-behind is required because the vulnerability related to "innerhtml" lies in the .Net code.
The specific flaw is actually in System.Web.UI.HTMLControls.HtmlContainerControl class, which is the super class of the
HTMLForm control (among others). The bug is easy to spot in the LoadViewState method as revealed in .Net Reflector:
protected override void LoadViewState(object savedState)
if (savedState != null)
string text = (string) this.ViewState["innerhtml"];
if (text != null)
For those not familiar with C#, the .Net class takes the "innerhtml" value from the view state and adds it as a
LiteralControl (basically literal HTML) in its "Controls" collection. When the HtmlContainerControl object is rendered,
it will take that LiteralControl and place HTML directly into the response body.
The other .Net-defined subclasses of HtmlContainerControl are listed below:
There are other .Net controls that take properties from the view state that may also be vulnerable. Enumerating them is
not very helpful because the solution will always be the same: secure the view state.
Regarding the articles you linked to, I am familiar with Scott Mitchell's. It is a great document, but the
vulnerabilities he references have to do with custom use of the view state, not specific flaws inherent in the .Net
view state. As we mentioned in the advisory, technically this is a known issue in .Net, although a proof of concept
attack against the framework has (to our knowledge) not been documented before.
I've also read Michal Zalewski's advisory. It stands out as (I think) the first specific attacks documented against
.Net's view state. However, they are of a different nature than the attack documented in our advisory.
Sacha Faust's post on encoding controls is a useful reference, but isn't directly relevant to view state attacks. The
list is of properties that will automatically HTML encode when the programmer sets the value. This isn't necessarily
the same as when the value is set in the view state.
Senior Security Consultant
Trustwave - SpiderLabs, Application Security
Email: dbyrne () trustwave com
From: full-disclosure-bounces () lists grok org uk [mailto:full-disclosure-bounces () lists grok org uk] On Behalf Of
Sent: Thursday, February 11, 2010 3:43 PM
To: Trustwave Advisories; webappsec () lists securityfocus com; websecurity () webappsec org; full-disclosure () lists
grok org uk; bugtraq () securityfocus com
Subject: [Full-disclosure] (resend) RE: [WEB SECURITY] Trustwave's SpiderLabs Security Advisory TWSL2010-001
The key part of the advisory for me wasn't VIEWSTATE as much as it was the controls, but this statement you made seemed
pretty outrageous (with regard to ASP.NET):
'These vulnerabilities show that unsigned client-side viewstates will ALWAYS result in a vulnerability in the
I would disagree - it depends how the software developer implemented use of the VIEWSTATE's content. In ASP.NET, the
interesting part here was that you appeared to be controlling an innerhtml property of a Form control through the
VIEWSTATE. What your example didn't show, I'm assuming, is some code behind that pulled out the <IndexedString> and
set the value in the form's innerHtml property/attribute. That's just dangerous coding, akin to trusting client-side
input and no different than acting on client input that came from any method, form input, JSON, etc. Your repro was a
bit confusing/misleading without that part. Otherwise, were you saying that some controls inherently populate their
properties/attributes from VIEWSTATE content automagically?
There have been past discussions on VIEWSTATE's security:
Scott Mitchell documented tampering VIEWSTATE in a 2004 article:
Michal Zalewski reported some exploit scenarios with replay and DoS through VIEWSTATE.
You made a reference to how other controls are also vulnerable to this attack. I think that data would be more useful
in the advisory.
Yes there do exist ASP.NET controls which don't properly encode, and I would refer readers to Sacha Faust's FxCop rule
which finds those dangerous controls:
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/