14 Comments

  1. Kevin

    Hey Jeff,

    Thanks for the write-up and helping us get the word out to Ninja Forms users about the update; we appreciate it!

    Incase you missed it in the post, here’s a link to our blog post: https://ninjaforms.com/important-security-update-always-hurt-ones-love/

    Report

  2. Ron

    The following vulnerable code was, according to Kyle Johnson of the WP Ninjas team ‘not a live feature of Ninja Forms, but was more of a proof of concept for a future free feature.

    I call complete BS on this. Nothing about that sentence makes any sense in the real world. They screwed up bad – plain and simple.

    Report

    • Trevor

      To be fair James Golovich’s report says this:

      For quite some time the WP Ninjas team has been busy doing a complete rewrite of the codebase to provide more flexibility in the future. Starting with version 2.9.36, a preview of the 3.0 code base has been included in the main plugin download and typically requires an administrator to manually enable that code for testing.

      All of the following vulnerabilities are in the 3.0 code base and any version before 2.9.36 are NOT affected in any way.

      http://www.pritect.net/blog/ninja-forms-2-9-42-critical-security-vulnerabilities

      Report

      • mark k.

        users were expecting a release quality code and get beta quality code…… Every day you discover another way in which wordpress plugin development practices are horrible. Is there any one in addition to pippin and rarst that produces code that you can blindly trust for not doing stupid things? (talking about code quality, not about bugs or bad product design here).

        I am lucky in that I just had the plugin installed but haven’t had the time to actually do anything with it yet, so deleting it and never looking again at that direction will not be a problem.

        Seriously, for a week you left me exposed to security issues? If one guy knows about it then the whole internet knows about it, WTF were you thinking?, And many sites do not have the setting for automatic updates so pushing it by force from wordpress.org is not an alternative to a proper announcement.

        Report

        • Trevor

          I’m not a fan of this idea either, let people install the beta/preview separately instead of bundling it.

          Report

        • Pippin Williamson

          Is there any one in addition to pippin and rarst that produces code that you can blindly trust for not doing stupid things?

          Thank you for the compliment but this is just silly and blatantly wrong. Every single developer–PERIOD–introduces security vulnerabilities at some point. The only developer that’s never had one is the developer that has never released any code. Period, end of story.

          I was responsible for introducing one of the most severe vulnerabilities I’m aware of a few years ago. It was so bad, in fact, it allowed anyone to log into any site running one of my plugins as a full administrator by simply clicking a button–a button that was shown to all users on the frontend of the site.

          Let’s stay off of the high horses and be appreciative that the WP Ninjas acted immediately to resolve the issue once it was revealed to them and that they immediately worked to get every single site patched in a matter of minutes after releasing the fix.

          Report

        • mark k.

          @Pippin, I actually said nothing about having the security issue, I was refering to the idea of shipping code that the developer himself knows it is not a release grade code marked as a release grade. That would have been a surprise if such design decision did not result in some exploitable code or just major major bugs that would have totally surprised people that are expecting a release grade product.

          Now the specific issue was solved, but was the design issue solved? Unlikely. So what bugs will be introduced in their next release from the code that “should not be active at all”, but made active by mistake?

          It is one thing to have one beer too much while coding, and another thing to plan to use the wordpress.org users as beta testers without their knowledge.

          And about your bug, that is exactly my point, when I install EDD the question I have in mind is “say pippin had access to my admin, would I have been able to trust him not to do something stupid?” because installing anyone’s code is in a way giving him admin level access to your wordpress, whether it is exploitable or not.

          Side note: It is nice to see you and others come to the defense of people that had a bad day, but if those people are not publicly whipped (yaost, jetpack come to mind as examples right now) what incentive will they have to improve? It sounds like any shenanigans is ok from plugin and theme authors as long as it doesn’t involve ads, or they say sorry. The chances of anything improving code wise in the ecosystem when failures are so easily fogiven is slim.

          Report

        • Pippin Williamson

          It wasn’t beta testing on all users without their knowing. It was an opt-in beta that was made available to users if they wished to use it.

          Very different thing.

          Also never, ever, ever will I condone the public “whipping” of someone because they made a mistake and put some code in a plugin that shouldn’t have been there or contained vulnerabilities.

          Report

        • Trevor

          As I understand it the code is exploitable whether they had the 3.0 preview running or not, so the “bad code” was installed and exploitable regardless of opting in to test it or not. That’s the issue Mark is referring to.

          If a site has not manually enabled the 3.0 code for testing, it is trivial for an attacker to bypass this and execute the 3.0 code. For all of the following vulnerabilities a site admin does NOT need to have enabled the 3.0 codebase.

          http://www.pritect.net/blog/ninja-forms-2-9-42-critical-security-vulnerabilities

          Report

        • mark k.

          It was untested (or very poorly tested) code pushed to half a million installs, without any notice. Without that untested code, the exploit of being able to activate 3.0 without having admin permissions would have been just a forgettable curiosity, with it, it is an actual problem.

          We are talking here about half a million sites here that are in risk, not 5k, and from what I can read in the stats, a week after the updated release and the forced update only 25% were upgraded to latest release. And all those people were put in risk because someone had a great idea how to shortcut proper development cycles.

          Also never, ever, ever will I condone the public “whipping” of someone because they made a mistake and put some code in a plugin that shouldn’t have been there or contained vulnerabilities.

          At the outbreak of one of the latest plugin related security issue someone on slashdot summed it nicely “wordpress is not secure out of the box and you need a security plugin to make it secure, but if you want a secure wordpress site you better not use any plugin”. It doesn’t matter at all if it is true or not cause this is what the tech world thinks about wordpress, and that forgiveness that you show makes people in the wordpress ecosystem think that it is ok to write insecure bad code, therefor justifying the above view of wordpress security.

          Report

    • Kevin

      Hey Ron,

      I completely agree with your sentiment. We did screw up. The feature that Kyle is referring to was an early prototype of a file upload field that we started developing but eventually shelved. The code shouldn’t have been in production because the feature was abandoned. It fell through the dev/testing cracks. Kyle isn’t trying to shirk any responsibly. He was just explaining that we didn’t catch the problem because of a breakdown in our development process. We’re working on improving this process so things like this don’t happen in the future.

      Report

      • Trevor

        So will you continue to release preview code alongside production code, or has this caused you to switch up on that?

        Report

        • Kevin

          We will continue to release version 3.0 alongside the 2.9.x codebase. So far, this slow roll out has been invaluable in our development of 3.0. The security mistake has definitely helped us identify weaknesses in our processes and shown us where we can improve testing and auditing of the dual codebase.

          Report

  3. Ed

    The wording of the post is a bit misleading with this statement: “Wordfence is reporting that Ninja Forms versions 2.9.36 to 2.9.42 contain multiple security vulnerabilities.” It makes it sound like Wordfence discovered the vulnerability instead of James Golovich. Of course if you continue reading you can clearly see that James Golovich deserves all the credit. ;)

    Report

Comments are closed.

%d bloggers like this: