lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 6 Mar 2014 11:03:26 -0800
From: Tim <>
To: Lukasz Lenart <>
Cc: "" <>,,
 Struts Developers List <>,
 Struts Users Mailing List <>
Subject: Re: [ANN] Struts GA release available -
 security fix

> No, rather no. You gain access to ClassLoader.

Ok...  Many past bugs in different contexts have involved ClassLoader
and have lead to *very bad things*.  I want to be sure you aren't
playing coy about how serious the issue is.  But as I brush up on how
struts/OGNL works, I can see how an attacker might be somewhat limited

However, unless I'm missing something, it seems like your recommended
regex may not be adequate to prevent ClassLoader access.  I'm
referring to this suggested mitigation:

Simple add '^class\.*' to the list of excludeParams as below

<interceptor-ref name="params">


This blocks parameters that start with "class", but what about ones
that contain class internally?  Based on [1], I would think an
attacker could send a parameter like this:


Which would result in, effectively:


So long as a developer defines an action within their application that
that has *any* get method that returns an Object ("getAnObject" in
this example), then they'd still be able to get at the ClassLoader
with your exclusion regex, right?  Or am I missing something about
other mitigations you guys have put into place in prior versions?



Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists