lists.openwall.net   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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 25 Apr 2014 20:09:06 +0200
From: Rene Gielen <rgielen@...che.org>
To: fulldisclosure@...lists.org
Subject: Re: [FD] [ANN] Struts 2 up to 2.3.16.1: Zero-Day Exploit Mitigation
 (security | critical)

Thanks for pointing this out. The mitigation advice is obsolete once the
security patch release currently under review is published. Your point
should be addressed there. We would have delivered the release along
with the announcement if this issues would not have been disclosed already.

Thanks,
René

Am 25.04.14 19:30, schrieb Tim:
> 
> Also, I'm a tad confused by the regex you have as a stop-gap.  For the
> readers' convenience:
> 
> (.*\.|^|.*|\[('|"))(c|C)lass(\.|('|")]|\[).*,^dojo\..*,^struts\..*,^session\..*,^request\..*,^application\..*,^servlet(Request|Response)\..*,^parameters\..*,^action:.*,^method:.*
> 
> 
> If your regex evaluation is case-sensitive, then clearly you need to
> check for "class" and "Class", since OGNL converts "foo" to "getFoo",
> and would likely also convert "Foo" to "getFoo".  But if the blacklist
> is case sensitive, then don't you also need to check for
> "^Request...", "^Session...", "^Struts...", and so on?  Or is it
> actually case insensitive and you're just being unnecessarily careful
> with "class"?
> 
> Also: Thought about unicode lately?
> 
> tim
> 
> 
> PS- yes, I'm too lazy to actually look at the Struts code right now.
> 
> 
> 
> On Fri, Apr 25, 2014 at 09:52:23AM -0700, Tim wrote:
>>
>>
>> So I have to say, I feel like the Struts team is kind of... failing.
>> Here are my gripes:
>>
>> A) I questioned the last bug fix in the thread here [1], where we
>>    were all reassured that it was just "ClassLoader manipulation", not 
>>    RCE.  Clearly that's not true.
>>
>> B) The fix for the last CVE was that crappy "^class\." filter, which
>>    I pointed out was insufficient.  The Struts team quickly fixed
>>    that, but never bothered to update the "workaround" section in the 
>>    last advisory to the less-terrible ".*\.class\..*" regex (or whatever
>>    it was).  So if developers just implemented the work around from
>>    the advisory, they were obviously not protected.  (In hindsight,
>>    they never were protected even with the better regex, but was just
>>    irresponsible not to make the second regex more public.)
>>
>> C) The Struts team is playing whack-a-mole.  Instead of fixing the
>>    root issue, they are just adding one blacklist regex after another,
>>    hoping no one figures out yet another way around it.
>>
>>
>> I urge you to take OGNL and *throw it out*.  Replace it with something
>> that allows only a white list of properties to be set, based on what
>> the application defines as relevant.  Until then, I'm recommending to
>> my clients that they avoid Struts like the plague.
>>
>> tim
>>
>> 1. http://seclists.org/fulldisclosure/2014/Mar/53
>>
>>
>>
>> On Thu, Apr 24, 2014 at 05:37:13PM +0200, Rene Gielen wrote:
>>> In Struts 2.3.16.1, an issue with ClassLoader manipulation via request
>>> parameters was supposed to be resolved. Unfortunately, the correction
>>> wasn't sufficient.
>>>
>>> A security fix release fully addressing this issue is in preparation and
>>> will be released as soon as possible.
>>>
>>> Once the release is available, all Struts 2 users are strongly
>>> recommended to update their installations.
>>>
>>> * Until the release is available, all Struts 2 users are strongly
>>> recommended to apply the mitigation described in [1] *
>>>
>>> Please follow the Apache Struts announcement channels [2][3][4][5] to
>>> stay updated regarding the upcoming security release. Most likely the
>>> release will be available within the next 72 hours. Please prepare for
>>> upgrading all Struts 2 based production systems to the new release
>>> version once available.
>>>
>>> - The Apache Struts Team.
>>>
>>> [1] http://struts.apache.org/announce.html#a20140424
>>> [2] http://struts.apache.org/mail.html
>>> [3] http://struts.apache.org/announce.html
>>> [4] https://plus.google.com/+ApacheStruts/posts
>>> [5] https://twitter.com/TheApacheStruts
>>>
>>> -- 
>>> René Gielen
>>> http://twitter.com/rgielen
>>>
>>> _______________________________________________
>>> Sent through the Full Disclosure mailing list
>>> http://nmap.org/mailman/listinfo/fulldisclosure
>>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>>
>> _______________________________________________
>> Sent through the Full Disclosure mailing list
>> http://nmap.org/mailman/listinfo/fulldisclosure
>> Web Archives & RSS: http://seclists.org/fulldisclosure/
> 

-- 
René Gielen
http://twitter.com/rgielen

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ