In continuation of yesterday’s post about bbPress, I decided to look for a more impactful race condition vulnerability. What’s more impactful on an online business than ecommerce?
WooCommerce is up for the thread-safety test in this post and probably a couple of other to follow.
In a highly-concurrent high-load environment bbPress will not count the topics and replies correctly. This happens due to several race conditions in the code. While not a critical vulnerability, it’s annoying. I wonder how the dotorg forums keep the numbers accurate? Maybe they don’t and nobody cares 🙂 but it’s something I’ve been very passionate about – data accuracy and race conditions.
As a contractor, I’m often approached by startup founders (or founders-to-be). They’re looking to reach some kind of partnership deal, where I would do backend development work without charging any money. As a wantrepreneur, I’m sometimes approached to fund some sort of startup. When, or rather, if the startup becomes profitable, I would get a cut of the profits.
I’ve learned some important lessons in the past 10 years. These help me deal with new partnership proposals without getting carried away, and steer some of friends and colleagues away from lucrative business proposals.
This is a simple instruction on how to make W3Total Cache (version 0.13.1) work with nginx (version 0.14) and subdirectory installs.
…or “Are you insane? You haven’t written anything programming-related in over a year and you come back with this nonsense?”
WordPress is not thread-safe.
I’ve spoken about this, and even started work on a plugin called WP_Lock that will aim to introduce some thread-safety into core to address the occasional TOCTOU bug under high load (and concurrency). For example ticket #44568 is an easy-to-reproduce complaint about concurrent REST API access 😉
If you thought writing thread-safe code in WordPress plugins is hard, unit testing the code for concurrency issues is even harder. One of the ways I found works best is by utilizing the PCNTL module in PHP to fork and test critical sections.
My first WordPress hackathon! do_action Moscow 2018 was organized this past past weekend by Теплица социальных техонологий, a Russian non-profit organization operating around the country.
Around 20 non-profit organizations took part in the hackathon over two days using WordPress to advance their causes. I was assigned to a team called Второе дыхание, a non-profit based in Moscow that gathers and recycles unwanted clothes, toys, etc.
Their idea was to create a chat bot for WordPress to help alleviate e-mail and Facebook chat support resource hogging.
If you haven’t looked at part 1 and 2 here, I suggest you do before reading on. This is a direct continuation of part 1.
So the original $wpdb->prepare vulnerability, which, I remind you is based on a potential typo in third-party code, is followed up with a new potential vulnerability based on double preparing a query. So again, bad third-party code.
So here’s one for you. If a developer does $wpdb->prepare( "SELECT * FROM wp_users where ID = %d OR %d". $_GET['param1'], $_GET['param2'] ); (note the . instead of the ,) do I also get a $500 bounty? How far will this go? Will the method be removed completely because #security? To what extent should WordPress and PHP be blamed for potential developer mistakes?
Shouldn’t these be addressed in the actual third-party code and not in core? I’m at a complete and utter loss now. What’s next?
Shout outs to Slavco for bringing all these issues up both with the codebase and the community, and how things are or should be handled.
A sad story in two parts, where I’m rash, harsh and untactful. An explanation, a rant, a call for support, a call for action. You do not have to agree with me, I may be just an asshole and haven’t realized it yet 😉
Over at GravityView, I have the pleasure of working on Gravity Forms-related things and sometimes we have a performance issue on our hands. This time it was an issue with a form that has about 15 visible conditional fields, about 300 (yes, three, zero, zero, three hundred :)) hidden calculation fields and a product total at the end.
This form was very laggy in the browser. Any interaction took around 3 seconds to propagate through, blocking the rendering thread completely.
