Sorry to be late to the party... busy period :) czw., 19 gru 2024 o 11:00 Jarek Potiuk <ja...@potiuk.com> napisał(a): > > While this might be a popular feature, It's pretty well handled by the Struts > team IMHO and I hardly can think what else we can do about it. > > I only found one really small thing that could be corrected - In the CVE > announcement (and other bulletins) here > https://cwiki.apache.org/confluence/display/WW/S2-066, the 2.5 is not marked > as EOL (but it is EOL in fact already and well announced). That one small > thing might be misleading a bit for someone who looks at the security > bulletin so might be worth updating the bulletins > > Łukasz - maybe you can update those bulletins ?
Once S2-066 was published, Struts 2.5 wasn't EOLed yet, in S2-067 I forgot to add a link to EOL of Struts 2.5 - I corrected the mistake once pointed out. I wouldn't update past bulletins as without re-announcing them there would be no impact on users. We also maintain a releases page documenting which vulnerabilities impact which versions, maybe I should add an EOL column for better visibility. https://struts.apache.org/releases.html > It's a critical one, yes, and easy to exploit from what I can say (it has 9.5 > critical rating on the scale of 10). And seems that any application that used > file upload before struts 6.4 must be converted to the new mechanism. So this > one is not as easy as "upgrade to new version" - it's "upgrade to new version > and modify your application to use the new mechanism" - which I guess is why > people are stirred by it. > > But - coming from outside, the links, explanation, and all the documentation > about it provided by struts team is pretty clear about it, severity is well > assigned, there is a very clear migration path - and I do not think the > update is "complex". It's costly, yes if you are using a Struts version that > is EOL for 7 months, but this is precisely something that our users have to > learn - that when we properly announce EOL, they have to bear all the costs > connected. > > One thing that could be - potentially - problematic is that there is no fix > or workaround available for struts prior to 6.4.0 - which is relatively new > release (24 April 2024) - and - as far as I understand, anyone who used the > interceptor before - which I think was necessary/useful to gather meta-data > about the uploaded file - has to migrate to 6.4.0 at least. But this is not a > major release, feature only so should be fine. Struts follow Semantic > Versioning so upgrading to 6.4.0 should be "easy" (which directly follows CRA > guidelines on which versions should be patched as far as I understand them). There was no easy solution to implement as a drop-in upgrade, that's why I didn't want to create a quick fix release 6.4.1 with just this one fix - it would be a clear indicator how to explore the vulnerability (which is obvious now as we have received a lot of false positive reports once S2-067 was published). Instead, I decided to mark the existing file upload mechanism as deprecated and replaced it with the new one and mixed it in as a part of another minor release, just to give enough time for users to migrate before announcing the vulnerability. You can say it was a tricky game but sometimes you must take the risk :) I learned not to give too much information about vulnerabilities, as it helps hackers more than users. Users must trust us that we do the best we can do to keep them safe. > The Struts team did everything right IMHO. There was an announcement made in > October 2023 that Struts 2.5 will reach EOL and that everyone should migrate > to Struts 6. https://struts.apache.org/struts25-eol-announcement, it's > publicly announced here https://struts.apache.org/ in a very prominent place > the EOL database https://endoflife.date/apache-struts shows correctly that > 2.5 reached EOL already accordingly. I don't think there is any "noise". Also > when you announce a critical vulnerability, it should never be considered as > a "noise". This is what announcements are for, and this one is almost as > critical as it can get. Just one small remark, Struts 6 is basically Struts 2.6 - below is explanation why. Also this means upgrading to Struts 6 isn't painful yet you should upgrade as soon as possible and keep upgrading to the latest version once available (upgrading from 2.5.0 to 6.7.0 is jumping over 30 releases at once - then it's painful). https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199528107#VersionNotes6.0.0-Versionchange > I think - to be perfectly blunt - IMHO neither we, nor Struts should release > any extra statements that could be interpreted as "we have not already done > enough". We (Struts team particularly) did everything right, made all the > necessary announcements, had very clear explanations and followed all the > best practices as far as I can see. If someone still clearly EOL version of > struts 7 months after release, they have to learn to do better, not us. > Making extra statements from us will be somewhat stating "The standard > processes and best practices are not enough" and it might be a precedent that > in the future those who are not following the announcements and advisories > will expect us to do "more". I think that would be a dangerous precedent. > > If anything, maybe Dirk - you should forward this analysis (if my short > investigation findings are confirmed as correct by Łukasz and Struts team) to > your customers and tell them "you are not wary enough - learn from that". I would love to hear more info from users on how adoption of the latest version is going, what's missing, what should be fixed - yet from my experience such reports will appear 1-2 months after the release date. I tried to roll small releases often assuming they can be adopted faster - see the number of Struts 2.5.x versions (and remember Struts 2.5.x means Struts 2 ver. 5.x) - that didn't help, users had been complaining even more. Right now I'm trying to keep 3-4 minor releases a year schedule, which looks optimal for that kind of a project - aged & complex. Merry Christmas Lukasz --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
