Drupal Warns of New Remote-Code Bug, the Second in Four Weeks (arstechnica.com) 50
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.
A new twist on term 'open source' (Score:5, Funny)
How outrageous (Score:5, Funny)
Drupal and php are so well secured and up to date that this can happen is simply inconceivable
Re: (Score:3, Funny)
Drupal and php are so well secured and up to date that this can happen is simply inconceivable
You keep using that word... I do not think it means what you think it means.
Where are the sandboxes? (Score:5, Insightful)
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?
I guess your imagination is limited (Score:3)
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 give
Re: (Score:2)
What's the point of that when the real sensitive data is in the website? The PHP code still has to access the database. Who cares about anything else? Either way, it's pretty standard practice these days to run sites in a separate VM or otherwise sandboxed environment.
Re: (Score:2)
You mean like containers that Linux and Amazon use and very recently Windows and Azure Linux/Windows serverless [arstechnica.com]?
Problem is it doesn't solve SQL access bugs even if you can generate another container the data is still compromised
Kids today use node.js and frameworks from Azure and Amazon that are secured and unfortunately locked to these platforms.
Coders should not be security experts. The frameworks should which PHP has shown are not written by such
Re: Where are the sandboxes? (Score:2)
Why do people use php?
Re: (Score:2)
Why do people use php?
Same reason they use python - you don't need to be aware of much to get results. In reality, there is very little difference between python and php other than (around) a 200:1 ratio of code in the field and that php is almost exclusively found in world-facing code and python isn't.
Re: (Score:2)
fyi: saveie6.com yields 404
Re: (Score:2)
Failure has 1000 mothers (Score:1, Insightful)
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 s
Re: (Score:3)
The problem is that with every major release they completely revamp the API. Nobody who develops for them can keep up with the changes and there's no automated way that works to upgrade source from release to release. If you choose to use a module because there isn't something you need in core, then you're stuck till the module gets converted to the newest release which may never happen. Eventually, your mind just screams.
The path to secure code isn't rewriting everything from the ground up with each rele
A+ on stealing my potential clients (Score:1)
F- on retaining them.
The problem is obvious (Score:1)
the open-source CMS built on the PHP programming language
Re: (Score:2)
Worse still are the idiots that masquerade as Drupal consultants, insane rates and what they churn out is absolute shit.
Not wanting to defend Drupal Developers BUT, when you start with a turd, no matter how you mould and shape it what you will end up with will still be at its heart a turd.
Re: (Score:2)
it does seem PHP panders to low-talent and lazy developers who make all manner of insecure platforms and modules. A developer who decides to go into PHP is much like a person who joins the band to play the triangle.
Wrong. (Score:1)
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.
On
Re: (Score:2)
Nonsense, a company running those multiple systems will have the PHP ones broken into early and often. Web application firewalls will have the most rules devoted to php flaws and exploits. It is the insecure malware ridden choice, and the low wage developers are the ones who work on it. in short, it panders to low watt bulbs and is an attack and malware magnet.
PHPNuke throwbacks (Score:2)
Perhaps "good old days" is not the best way to describe it, actually.
Not really a NEW bug (Score:2)
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 part
Re: (Score:2)
Yes, the patch is a bit "heavy handed" just doing coarse query string filtering... but on the other hand that may have helped delay attacks a bit, by not pinpointing the specific mechanism of exploitation.