| 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
| ||
|
Date: Sun, 27 Apr 2014 19:16:44 +0200 From: Rene Gielen <gielen@...neering.net> To: fulldisclosure@...lists.org Subject: Re: [FD] [ANN] Struts 2 up to 2.3.16.1: Zero-Day Exploit Mitigation (security | critical) We have reports of RCE in specific environments. For that reason RCE is our maximum impact rating. Am 26.04.14 12:54, schrieb Alexander Georgiev: > Is the new vuln just a DoS or RCE one? It seems to be "only" a DoS. > > > Am 25. April 2014 23:28:54 schrieb Tim <tim-security@...tinelchicken.org>: > >> >> Hi Rene, >> >> Thanks for your responses. Keep in mind my criticisms are not >> directed soley at you. They are directed at the entire Struts team, >> it's practices and culture. >> >> I've been on the front lines with applications who were pwned by >> Struts bugs and thousands of users' personal information exposed. >> Millions of $$ burnt on the cleanup efforts. So there may be a few >> emotions attached to my emails. Just the way it is. >> >> >> > > 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. >> > > >> > At this point in time, it was true. The RCE is not exactly a Struts >> > issue alone, the Struts issue just opens the door to an unprotected >> > field in a certain servlet container environment. >> >> You expect every servlet container environment to protect against >> Struts? I find this response to be very pass-the-buckish. >> >> My point here is that your team failed to adequately characterize the >> problem's risks. This leads to more developers ignoring the patch and >> subsequently getting pwned. Even if you only thought an RCE *might* >> be possible you should state that. It is the responsible thing to do. >> >> >> > > 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.) >> > > >> > Better suggestions are always welcome. We have a mail address to reach >> > us for any concerns regarding security: security@...uts.apache.org >> >> Well, what I'm saying is that I did give suggestions. I believe that >> email address was CCed. Your team took them to heart, which is great. >> But then your team failed to publish them adequately. >> >> >> >> > > 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. >> > We try to protect users who are not using a properly configured >> security >> > manager, as it is always recommended when working with application >> > servers. >> Wow. Now you sound like an Oracle representative. I'm not >> exaggerating either, because they've used that line a few times with >> me. We all know how well Oracle handles security. >> >> Using a security manager for web applications is certainly a good >> idea. No arguing against that. Do developers do it? NO. It simply >> isn't common and usually when I suggest it to a client, they give me a >> blank stare, clueless as to what I'm talking about. >> >> >> >> > Sometimes we seem to fail, indeed. As others, we don't seem to >> > be perfect. BTW, we are not only blacklisting - the blacklist is >> applied >> > for special cases that make it through the whitelist. >> >> Sure, and if this were only one iteration of failing on the same >> problem, I wouldn't have said a word. It's just that the failure is >> happening over and over again. I felt public criticism, if not >> outright shaming, is warranted. >> >> >> > > 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. >> > > >> > To what alternative? UEL? The attack vector is just using a simple >> > getter semantic which basically works with any EL. Throwing out EL >> > capabilities is no option for most users. Anyway, if somebody likes to >> > help with more than just fingerpointing, he/she is heartly welcome! >> >> Something that doesn't allow you to directly call methods, and only >> allows you to access properties on objects explicitly defined by the >> app developer. Keep the syntax similar if you like, but chuck the >> reflection. Data is data. Code is code. Keep them separate. >> >> tim >> >> _______________________________________________ >> 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 IT-Neering.net Saarstrasse 100, 52062 Aachen, Germany Tel: +49-(0)241-4010770 Fax: +49-(0)241-4010771 Cel: +49-(0)163-2844164 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