Slashdot Mirror
Drupal Warns of New Remote-Code Bug, the Second in Four Weeks (arstechnica.com)
For the second time in a month, websites that use the Drupal content management system are confronted with a stark choice: install a critical update or risk having your servers infected with ransomware or other nasties. From a report: Maintainers of the open-source CMS built on the PHP programming language released an update patching critical remote-code vulnerability on Wednesday. The bug, formally indexed as CVE-2018-7602, exists within multiple subsystems of Drupal 7.x and 8.x. Drupal maintainers didn't provide details on how the vulnerability can be exploited other than to say attacks work remotely. The maintainers rated the vulnerability "critical" and urged websites to patch it as soon as possible.
Apparently, the source is open more ways than one.
Only with the power of caring and group-think can we overcome these nasty, racist/sexist/bigoted microaggression bugs. Someone fetch a Holy (non-denominational) Scroll of Code of Conduct!
Drupal - fix your shit. Full stop. These bugs? They're WAY more embarrassing (as viewed by the people who matter) than you spending your time kink-shaming your VOLUNTEER developers
Drupal and php are so well secured and up to date that this can happen is simply inconceivable
http://saveie6.com/
F- on retaining them.
Why don't developers just write code that doesn't have security holes in it?
Presumably because they can't. It's time we started programing computer resource sandboxes into every application by default.
Linux and Mac, and Windows all have things for this. Macs have a dtrace based sandbox that can be per application or per process.
sandboxes can specify what a process and all child processes can do at the computer resource level. Can they get on the network? Can they access the file system? what files can they access? do they have write permission? how much memory can they use? how much cpu? and so on.
If we always launched processes with these clamped down a lot of security holes would not be exploitable. Why is it these are largely unused?
Some drink at the fountain of knowledge. Others just gargle.
Drupal and PHP to be avoided at all costs, if you care about security.
Oh, stop.
The problem is not with the Code of Conduct. The problem is with an aging codeset pretending to be up to the challenges of 2018.
The people who developed Drupal and made it a thing worth using left the building a long time ago. The people who maintain it now are trying to shoehorn Symphony into their API / hook system while also implementing RESTful web services, upgrading legacy modules, modernize the test framework, working out issues with the templating system, coming up with a decent migration system that doesn't rely on the command line, removing workflow dependencies on Composer, implement a React-based admin interface, etc.
Doing too much all at once doesn't leave them with the time to do much right.
This is all happening while the number of actual committers has dropped by over 70% in the past five years. Wordpress outnumbers Drupal installs 30 to 1. Organizations who traditionally used Drupal as a lightweight content management system are finding it takes heavily customized work to upgrade their websites. ECM customers are finding Drupal lacks governance features that are absolutely necessary to operate multiple digital properties, making it a cheap alternative to a real platform.
Losing your developer base while alienating the people who championed your system in order to pursue the enterprise is terrible for the entire ecosystem.
Just look at the videos from the most recent Drupalcon. The sessions are all over the place, there's one about using Drupal to build video games. Anyone who chooses to use Drupal as a video game platform should be fired, considering the number of other reliable platforms that are available. But it's right there, the community is pushing bad advice on people for how to run their digital enterprise.
Pretending your platform is suitable for use in domains that are well-served by better solutions is a bad idea. Highlighting this sham as an example of the possibilities at your major marketing events is off-the-charts dishonest.
Sure, with all this upheaval, it's natural for a group of volunteer coders to point fingers and blame other people. They're only human.
Every problem with Drupal can be traced back to a failure to prioritize, an incompetent Core development team trying to pass themselves off as experts based on the achievements of others, and sham marketing. The Code of Conduct is just an expression of these other problems. TBH, it's funny watching them flail.
the open-source CMS built on the PHP programming language
I had my first encounter with Drupal and a book "Beginning Drupal" by WROX press. It was supposed to cover Drupal 7. Please, no one ever waste your money on this. I discovered a lot about "Quick and dirty" publishing, and about Drupal. The phrases "the picture you see may have changed since date of publication", and "the API may have changed since time of publication" should help you with your decision. I found those phrases *A LOT* in that book. I got every example to work though. It just took a huge effort on my part, having written a lot of software in a lot of other languages. That there are other ongoing problems with Drupal, that there seem to be fires flaring up that the maintainers are having a difficult time putting out, that the ever-changing API and its ability to break a shocking amount from version to version comes as no surprise. Before settling on a CMS, I tried a few. Those that were either poorly documented, or were undertaking large and destructive changes to the API, I decided to leave alone. Drupal was one I left alone.
Drupal is actually worse than Wordpress. Garbage
PHP is my go-to language of choice long before Python, Ruby, Go, NodeJS, Rust, Perl, D, C++, etc. It's a superior platform in the hands of someone who knows what they are doing. No language out there *natively* comes close to touching the power, flexibility, and performance of PHP arrays, which are the ultimate data structure with near-O(1) insert, update, delete, and find operations that keeps the order of elements: The hash table + linked list solution to data management is, quite frankly, brilliant.
Only a fool would disregard PHP as only for "low-talent and lazy" developers. Systems developers would be wise to adopt PHP into their workflows. PHP is also extremely useful as a command-line scripting tool. All of my cron jobs are PHP scripts. Half of my installers are command-line PHP scripts (e.g. SSH automation).
To try to answer your ridicule patiently imagine the following. A program running in a sandbox without data base access handles the requests and then sends messages to other processes in each of the other sandboxes for the various sub tasks.
*The customer database verification
* Backend accounts/card processing interface to process and record sales
etc..
the verification is only permitted to set a semiphore (true false) to comunicate the varification back to the master process.
And so on. Every process is given limited resource access and very limited communication access to another process. As much as possible the communications are handled through single duplex deadrops (like a semaphore).
this would massively cut down the ways to exploit a defect in one subsystem.
it's analgous to validating your inputs but much better because the program litterally lacks the resources to perform most invalid actions even if the input validation fails.
Some drink at the fountain of knowledge. Others just gargle.
Those still using it deserve whatever consequences their folly entails.
I'm getting awfully nostalgic for the security addled PHPNuke right now. Reminds me of the good old days when even basic user data sanitatizaton seemed to be considered an excessive novelty.
Perhaps "good old days" is not the best way to describe it, actually.
There are no stupid questions, just stupid people.
The original bug was a way to compose query string parameters (the part of the URL after the ?) that permitted injecting executable code in a form. The new bug is a variation where the malicious query string is part of a redirect URL passed through the query string, so it doesn't get filtered with the previous patch, because it has escaped characters. So it's not really a new bug, but rather plugging an oversight on the original patch.
On the positive side: Drupal has security audits of its core and 3rd party components, you get emails with any security updates and the patches are available through a centralized mechanism... so it's ahead of Wordpress and other platforms with no centralized module library. Release of the patches was announced ahead of time so we could prepare for them. I
On the negative side: Drupal has fundamental architectural problems of (almost) not having boundaries between data and code. It's form API (which had the original bug) is very practical and implements a lot of great security features, but it's an unfathomable mess... VERY hard to track what it does and very hard to properly use (for 3rd party module developers), since its internal workings are not properly documented. Also, Drupal has a very very extensible architecture allowing for all sort of pluggable behavior, which also means it's very very hard to track the flow of data... this was a bug present at least since Drupal 6 (released in 2008) because it was not easy to see how data could move from the query string into the PHP structures used to define forms without proper filtering. The new-ish Drupal 8 has a more mature OO architecture, probably cleaner, but even harder to follow without actually running the code with a debugger.
As a Slashdot discussion grows longer, the probability of an analogy involving cars approaches one.